Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I would like to see DNS servers require each client to establish one TCP connection to be allowed to use UDP thereafter.

If this were the default on DNS servers, then DNS amplification attacks would be nearly impossible. They rely on spoofing a DNS request from the victim, and amplify because the response may be many times larger than the request. If TCP were required to be used before UDP responses can be received, then the victim would have to be first tricked into making a DNS request over TCP to each public DNS server.

The DNS Cookies standard (RFC 7873) doesn't do much to stop this, since it is impractical to fail queries from non-cookie clients.

DNS over TCP is supposed to be supported, so implementing this will push firewall admins in the right direction (allow both TCP/UDP outbound on 53).





That's an interesting argument, given the whole impetus behind pushing for DoT vs. DoH was to allow network administrators the discretion to block encrypted DNS (by blocking DoT).

quadrupling first query time wouldn't be acceptable. And now server have to keep some state per client so more requirements

If the DNS server is actually local like it's supposed to be, it should have just a few ms ping. Quadrupling that just once is no big deal. The user won't even notice, since every OS does lots of background DNS activity before the user even opens an app or browser.

Saying that 2xRTT is a deal-breaker is like saying TCP in general is a deal breaker.

State per client is pretty simple. Use a bloom filter to decide if a client IP is ok for UDP, and slowly set bits to zero at random to force gradual eviction. With a secret nonce per server, the attacker can't engineer collisions except by controlling lots of IPs. For IPv6, just treat blocks above a certain size (e.g. a /48) as equivalent.

And again, this should be the default. Someone that is seriously trying to run an open resolver should have their own fork of the source code and adjust this as they need. The small-time operators that accidentally make their resolvers open won't notice a bloom filter or a slow initial lookup.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: