19

I have been looking for an answer to that question (the one in the title) and the best thing I've found was:

In DNS Protocol design, UDP transport Block size (payload size) has been limited to 512-Bytes to optimize performance whilst generating minimal network traffic.

my question is: how exactly does this enhance performance and are there any other reasons for this limitation when using UDP ?

1
  • 5
    The question is actually based on a false premise (at the very least an outdated one). The 512 byte payload limit is no more, see my answer below. Apr 9, 2014 at 18:26

5 Answers 5

22

The 512 byte payload guarantees that DNS packets can be reassembled if fragmented in transit. Also, generally speaking there's less chance of smaller packets being randomly dropped.

The IPv4 standard specifies that every host must be able to reassemble packets of 576 bytes or less. With an IPv4 header (20 bytes, though it can be as high as 60 bytes w/ options) and an 8 byte UDP header, a DNS packet with a 512 byte payload will be smaller than 576 bytes.

As @RyanRies says: DNS can use TCP for larger payloads and for zone transfers and DNSSEC. There's a lot more latency when TCP comes into play because, unlike UDP, there's a handshake between the client and server before any data begins to flow.

8
  • 9
    A related note: the reason there will always be 13 root DNS resolver names (a.root-servers.net through m.root-servers.net) is because that is the maximum number that can fit in a DNS response to a query for the root without exceeding the 512 byte limit. Thus, even as we add more physical servers to the root DNS infrastructure, logically there will always remain thirteen root servers.
    – phoebus
    Apr 9, 2014 at 0:04
  • 2
    @RyanRies For DNSSEC EDNS0 with a larger allowed payload is actually the normal mode of operation, not TCP. Apr 9, 2014 at 18:15
  • 1
    The smallest permitted MTU is not 576 bytes, it is 68 bytes in IPv4 and 1280 bytes in IPv6.
    – kasperd
    Apr 9, 2014 at 18:44
  • 1
    @phoebus can you show me how 13 servers do not exceed 512 byte while 14 servers do? what is the calculation behind it? Jul 27, 2016 at 10:12
  • 1
    512 + 60 + 8 = 580 bytes, not 576, no?
    – Carlo Wood
    Aug 21, 2018 at 17:32
15

Modern DNS is not actually limited to 512 bytes payload for UDP anymore.

With EDNS0 in use a larger payload size can be specified, which is also commonly the case for DNSSEC-aware clients.

The support for larger payloads over UDP has been a double-edged sword, however, it is in part the reason why using nameservers for amplification attacks has become more popular as you can achieve better amplification if the attacker uses a query that gets a large response.

See rfc2671 for the nitty-gritty details of EDNS0

2
  • 2
    This is true, but there are still routers and firewalls out there that drop UDP DNS packets over 512 bytes.
    – Ryan Ries
    Apr 9, 2014 at 18:56
  • 2
    @RyanRies Yes, while that is of course behavior that is considered incorrect by todays standards it is something that still occasionally causes problems. (In theory if one has such a limit in place one would know to configure the relevant software not to advertise capability of handling / not sending larger responses.) Apr 9, 2014 at 19:06
2

DNS operations for example, queries, and zone maintenance operations by default use port 53. For performance reasons, queries use the UDP protocol with a block-size limit of 512 bytes. TCP can be optionally negotiated on a transaction-by-transaction basis for query operations, but due to the performance overhead incurred with TCP, this is essentially a theoretical capability. Historically, exceeding the 512-byte response size limit was typically avoided at all costs, and indeed the limit of 13 IPv4 root-servers was the maximum that could be returned in a single 512-byte UDP transaction.

Ron Aitchison - Pro DNS and BIND 10 - 2011

1
  • Thanks. May we know the source of the quote (to give attribution to it)? Apr 11, 2018 at 5:21
2

TCP offers several capabilities over UDP like retransmission to guarantee data is received. A large UDP datagram can be fragmented into multiple IP packets. This is done on layer 3 when it's detected that, given the datagram size, the packet will be larger than the link MTU. Because UDP can't handle retransmission, if any of the datagram fragments are lost the entire UDP datagram is lost. This is quite inefficient. For large datagrams, DNS prefers to break them down to multiple ordered TCP segments. Each of these segments is packaged into its own packet and can be retransmitted if not received by the destination. Duplicate segments can also be detected. Basically, TCP handles failure much better hence more efficient for large datagrams.

UDP based protocols like DNS cap the UDP datagram size to around 512 bytes because this size guarantees the datagram won't be fragmented and hence losing one fragment leads to losing the entire datagram. It's around 512 because, in the IPv4 specifications, hosts should be able to handle packets that are at least 576 bytes large (which is usually well below most link MTUs). Since the IPv4 header can be up to 60 bytes large (20-byte header plus up to 40 bytes of options), 516 bytes (576 - 60) is the maximum size of the IP payload to guarantee not fragmenting.

-2

Its a QOS thing.

Because UDP is stateless, error-handling of packets isn't possible.

Thus, by keeping packets to a max size, there is a greater change they will reach their destination, reducing the impact of the absence of error handling.

3
  • Larger packets don't mean that UDP fails-over to TCP. Am I misunderstanding what you're saying?
    – mfinni
    Apr 8, 2014 at 23:10
  • You're probably right. I think I read that in a proposed RFC somewhere. Apr 8, 2014 at 23:16
  • UDP does not fail over but for DNS specifically if the response is too large to fit when using UDP this will result in a truncated response (the actual response does not contain all the data and the 'truncated' flag is set to indicate this), the client can then retry using TCP instead. Apr 9, 2014 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.