DNS has grown into an enormously complex system | Hacker News Reader

DNS has grown into an enormously complex system

queue.acm.org

59 pointsb-man18 comments

If this article makes you think DNS is complex, just wait until you have to deploy DNSSEC!

Or read how it's used for internet telephony: you're supposed to support 3 indirect results -> NAPTR query returns a regex and a list of ideas for SRV queries, which give you a list of queries to resolve with A. So much fun!

Why is UDP used for DNS instead of TCP? Isn't TCP supposed to be more reliable (lossless)? Reliability would appear to be of utmost importance in DNS, no?

Actually you can use either TCP or UDP to do DNS queries.

    host -T www.google.com

UDP is faster (since you don't have to build a connection), and you can just re-request the data on failure.

TCP is used if the size of the packet goes over 512 bytes. Practically this is only used for zone transfers.

It's also faster... Assuming everything works, it's one round trip time for the query and response for UDP, as opposed to 2 for the TCP case because you have to set up the connection first.

Being connectionless means that the server can be much more efficient, because it never has to keep track of any connections or state.

And, as others have pointed out, you just retransmit if you don't get an answer. TCP isn't really lossless, it just guarantees that you know when you've lost something which is an important distinction. And with DNS, that's pretty easy -- you didn't get your answer. TCP would take a while to figure this out, with UDP you can pick your timeout.

You also have to tear the connection down with 2 more round trips. Connections not being closed by the client are a drain on the server.

Also, to establish the TCP connection you need an extra roundtrip compared to the UDP use case. Given that in the case of no answer in the cache the recursive name server may need to ask several authoritative name servers - this can add significantly to the delay, too.

FYI, EDNS0 (Extension mechanisms for DNS) is supported by most clients and allows for large UDP packets (configurable to MTU) and includes other extensions. Common uses for > 512 byte packets are records that include several entries of both A and AAAA type, as well as all DNSSEC replies. It's from RFC2671 proposed in 1999. The only snag is that some consumer firewalls still don't support > 512 bytes when proxying DNS.

http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

Establishing a TCP connection requires two round trips between the server and client, vs. one for DNS over UDP under typical conditions.

Also, TCP provides lossless transmission on lossy media by retransmitting packets, which is what DNS does anyway.

"Reliability" in this case is ensuring that the packet (singular) gets to the user. If it doesn't, the user simply re-requests it.

(For when the response would be more than one UDP packet, "reliability" would also include receiving the packets in order. In that case DNS would tell the user to do the request over TCP.)

Many nameservers do support TCP. It's not generally used due to a combination of performance issues (TCP state would get expensive for a busy nameserver) and history.

The choice between TCP and UDP isn't whether you want your system to be reliable. It's whether you want to handle reliability in the application vs in the protocol.

TCP does reliability for you. UDP lets you implement whatever form of reliability you want in the application.

For DNS, you can do a much better job implementing DNS-specific forms of reliability. For example, if you have multiple nameservers, just move on to the next one instead of trying to retransmit packets to the first one that fails.

You can DOS a DNS server if it accepts TCP connections. This is why most people don't accept TCP connections on their DNS servers.

It is a wonderful privilege to receive as many replies as I did with over the above question. The many different issues raised on all of them made me learn a whole lot more than a typical Wikipedia article or similar.

All duly upvoted, I wanted to express my gratitude collectively for all the explanations. HN is a true gem of the Internet.

UDP's semanatics are faster for small (<= 1MTU) transactions since there is no connection state and no handshaking.

Further, at the time DNS was designed, TCP was not considered 'scalable' since each TCP connection required its own file descriptor and computers at the time struggled with even 64 file descriptors per process. As DNS was not distributed at the zone level (it was replicated but each replica had the full zone contents of those zones they mirrored).

These days UDP is still faster for small packets but as others have pointed out DNS switches to TCP for bigger requests.

Why are there so few DDOS attacks on DNS servers? From my understanding, it is trivial to forge a UDP packet with a false IP address. Wouldn't it be extremely effective for even a few thousand zombie machines to spam forged DNS requests to overload a DNS server? Given that the root DNS servers are such obvious targets, why are there so few attacks on them?

Read this. It's ICANN's summary on the last DDOS on the root DNS servers.

http://www.icann.org/en/announcements/factsheet-dns-attack-0...

Reply on news.ycombinator.com