A Deep Dive into DNS Packet Sizes | Hacker News Reader

A Deep Dive into DNS Packet Sizes

blog.cloudflare.com

68 pointsthedg28 comments

It'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.

Cloudflare 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.

BCP38/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/

There are other initiatives as well. But the problem is very difficult to solve.

Do 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).

The problem is technically difficult to solve. The same way deploying IPv6 was.

It'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.

Pretty sure 99% consumers don't give a shit if their ISPs support end to end IPv6 too.

No, quite the opposite. Nearly every router has a very simple option to not allow packets from IPs not on the same CIDR as the interface. If ISPs turned this on on each edge interface, the problem would be solved.

It's entirely political/economic. There is no incentive for an ISP to do so because it provides no direct benefit. It's a classic issue of externalities.

In a hostile Internet, where ISPs performing egress reverse path validation is the exception, rather than the rule, public UDP- based services are doomed.

With the exception of “discard” (on port 9), of course.

I can imagine a whole class of neat protocols that would use an incorrect ip_src field to help anonymity. Imagine broadcasting a request for a specific file to an IRC channel, and receiving fountain-coded responses from still-hidden sources.

While an explicit address could be designated for this, carriers would rather have control and surveillance voyeurs would have an easier target. It's better to not push to eliminate what end-to-end freedom we still have.

It 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

That 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.

> 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?

To be more specific he talks about it here:

http://cr.yp.to/talks/2012.06.04/slides.pdf

http://imgur.com/m6YCyG8

> 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.

Yep, copy paste fail the first link.

DNSCrypt 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.

By 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

I 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?

Some side channels travel over networks. Timing, for instance.

Nothing beats the -Ovlad optimization level :)

Resolvers 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?

While 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).

It 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.

Are there any other protocols that work over UDP and amplify traffic?

NTP.

Quake style game protocols ( Call Of Duty 4, Quake 2,3, etc ) were used quite a lot for amplified DoS

Reply on news.ycombinator.com