6 ms·
A Deep Dive into DNS Packet Sizes
- StreamBright 11y agoIt is kind of epic how DJB predicted this. "Domains with DNSSEC, because of the size of some responses, are usually ripe for this type of abuse, and many DNS providers struggle to combat DNSSEC-based DDoS attacks. Just last month, Akamai published a report on attacks using DNS lookups against their DNSSEC-signed .gov domains to DDoS other domains. They say they have seen 400 of these attacks since November." https://cr.yp.to/djbdns/forgery.html https://cr.yp.to/djbdns/forgery.html
- xorcist 11y agoThat link is about source port randomization in DNS, which Bernstein was a proponent of and most software implement today. DDoS by DNS is something else entirely. The cookies that Bernstein advocate does not help here. Only ingress filtering helps, but it has to be implemented world wide before it useful, and not many bother unless forced to. That much was well known at the time, and not something Bernstein predicted, but he has argued against adding yet another large record type to DNS. That's a good argument but at the same time not very helpful. The problem here is that there are several other queries with large replies and you just need one for an attack. Then there's all of NTP, and so on. It's one of those problems likely to get worse before it gets better.
- simoncion 11y ago> It is kind of epic how DJB predicted this. That's not how I read the linked essay. The lesson I get from that is that until relatively recently it was trivial to poison DNS responses requested by most DNS servers, and that it's still quite possible if you have a "nearby" malicious machine. The CloudFlare essay appears to be talking about DDoS attacks via traffic amplification through large DNS queries. Yes they both involve DNS, but -AIUI- nether DNSSEC nor DNSCurve will fix the problem mentioned in the CloudFlare essay. Am I misunderstanding either essay?
- StreamBright 11y agoTo be more specific he talks about it here: http://cr.yp.to/talks/2012.06.04/slides.pdf http://cr.yp.to/talks/2012.06.04/slides.pdf http://imgur.com/m6YCyG8 http://imgur.com/m6YCyG8
- simoncion 11y ago> To be more specific... ITYM: "To actually link to a talk where he talks about the topic I thought he was talking about..." ;) But yeah, thanks for the links. That's good stuff.
- StreamBright 11y agoYep, copy paste fail the first link.
- jedisct1 11y agoDNSCrypt works around the amplification problem (for public resolvers) by requiring a UDP query to be at least a big as the response, or the response will be truncated.
- hueving 11y agoIt's sort of pathetic that our answer to trying to stop DDoS amplification attacks is to cripple public UDP services. It shouldn't be acceptable for an ISP to originate spoofed packets. There is absolutely no excuse for it, yet we continue to accept it as some kind of inevitability and treat symptom after symptom of the same root cause.
- Scaevolus 11y agoCloudflare disables ANY for TCP requests as well, which might be frustrating for debugging. I don't fully understand its usages though, so maybe it's not such a big deal? Forcing large payloads to upgrade to TCP responses is probably a more compatible fix for this in general.
- AndyMcConachie 11y agoBCP38/Anti-Spoofing is a really really hard problem to fix. It may not happen in our lifetimes. There is the MANRS document/routing manifesto, which has been gaining traction. https://www.routingmanifesto.org/ https://www.routingmanifesto.org/ There are other initiatives as well. But the problem is very difficult to solve.
- madsushi 11y agoDo you mean the problem is technically hard or politically hard? From my understanding, it's not too difficult for an ISP to implement, the problem is convincing ISPs to implement it (when many don't care).
- Pharaoh2 11y agoThe problem is technically difficult to solve. The same way deploying IPv6 was.
- devicenull 11y agoIt's also worse, because if you were to deploy BCP38, you don't really get a whole lot from it. Sure, it's a good thing to do, but at the end of the day people aren't going to pick your service because you have BCP38 setup properly.
- axaxs 11y agoWhile ECDSA size is nice comparatively, the screenshot is a little misleading if strictly comparing algo sizes. It's not showing cloudflare's ksk, and cloudflare doesn't sign its own KSK (though there's no reason to really, but the other domain appears to).
- ge0rg 11y agoBy implementing ECDSA natively in assembler, he was able to speed up signing by 21x. Let's hope it is resistant to side-channel attacks[0] ;) [0] https://news.ycombinator.com/item?id=11223266 https://news.ycombinator.com/item?id=11223266
- lallysingh 11y agoI don't think side channels are an attack vector for them. These are running on machines that they own, and where they control all the software on them. I wonder if removing side-channel countermeasures was part of the optimization?
- mindslight 11y agoSome side channels travel over networks. Timing, for instance.
- jedisct1 11y agoNothing beats the -Ovlad optimization level :)
- jedisct1 11y agoResolvers obviously can't generate signatures for synthesized responses to ANY queries. So when the DO bit was set, the draft suggests returning unsigned records, because the initiator can then explicitly ask for HINFO and get a signed response. However, resolvers just return SERVFAIL if the response doesn't validate. Will Qmail retry with more specific records after a SERVFAIL response code?
- CyberDildonics 11y agoIt seems like one solution might be to simply not send more data from the DNS server than it has received from the IP it is sending to. You could still spoof an IP and bounce traffic, but then you couldn't amplify it.
- CyberDildonics 11y agoAre there any other protocols that work over UDP and amplify traffic?