Revisiting DNS and UDP Truncation

The choice of UDP as the default transport for the DNS was not a completely unqualified success. On the positive side, the stateless query/response model of UDP has been a good fit to the stateless query/response model of DNS transactions between a client and a server. The use of a UDP transport enabled the implementation of highly efficient DNS server engines that managed high peak query rates. On the other hand, these same minimal overheads imply that DNS over UDP cannot perform prompt detection of packet loss and cannot efficiently defend itself against various approaches to tampering with the DNS, such as source address spoofing, payload alteration and third-party packet injection. Perhaps most importantly, the way UDP handles large payloads is a problem.

The DNS avoids IP fragmentation by restricting the maximum payload size carried over UDP. RFC 1035 contains the directive: “Messages carried by UDP are restricted to 512 octets (not counting the IP or UDP headers). Longer messages are truncated, and the TC bit is set in the header.”

The intent of setting the TC bit in the DNS response was to indicate that the receiver should discard this UDP response and perform the same DNS query over a TCP transport. This is not exactly a highly efficient measure. The DNS query now takes an additional 2 round-trip time intervals (one for the DNS truncated response and a further exchange for the TCP handshake), and the server also needs to maintain a TCP state, which limits the server’s query processing capability. This option to requery using TCP is preferably avoided, but limiting DNS responses to at most 512 octets is not always feasible.

This limit of 512 octets becomes problematical in a number of scenarios. For example, a DNSSEC-signed query for the DNSSEC public keys of the root zone produces a response of 1,169 octets. It’s not just DNSSEC that is the issue here. We use the DNS for various form of authentication, and it’s a common practice to load authentication codes into the DNS as TXT records. Multiple TXT records will all be packed into a response, which can lead to quite large responses. For example, a query for the TXT record for bbc.co.uk elicits an DNS response of 1,666 octets in size.

The workaround for this issue of a very conservative selection of the maximum UDP payload for the DNS was the use of a so-called pseudo–Resource Record, the OPT record. This is the general extension mechanism for DNS, or EDNS. The specification for EDNS(0), RFC 6891, includes the option to use a DNS message size in the query to allow the querier to inform the responder of its capability to handle DNS over UDP responses greater than 512 octets, thereby avoiding some level of requerying over TCP when the response is larger than this default size. RFC 6891 also contains the following advice: “Due to transaction overhead, it is not recommended to advertise an architectural limit as a maximum UDP payload size. … A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.”

The IPv6 specification requires IPv6 networks and hosts to be capable of handling an IPv6 packet of up to 1,280 octets in size without fragmentation. The IPv4 specification has an unfragmented packet size of 68 octets, and IPv4 hosts are required to be capable of reassembling IP packets of up to 576 octets in length. In practice, the original Ethernet packet sizes (64 to 1,500 octets) have been largely adopted by the Internet, and in most cases (where no encapsulation tunnels exist) packets of up to 1,500 octets will pass through the public Internet without triggering packet fragmentation. What this implies is that in proposing a UDP buffer size of 4,096 octets, then IP fragmentation of large DNS responses will be triggered, and all the issues raised relating to the use of UDP fragments may surface as a consequence.

If a primary objective is to avoid IP packet fragmentation, then a UDP buffer size of 4,096 octets is just too large. The advice in DNS Flag Day 2020 proposed the use of an EDNS(0) buffer size of 1,232 octets as a minimum safe size, based on the 1,280 octet unfragmented IPv6 packets, and making allowance for the IPv6 and UDP packet headers. However, this is a very conservative choice, and the downside is potentially unnecessary requeries in TCP.

A current work in progress in the IETF, draft-dnsop-avoid-fragmentation proposes that the EDNS buffer size should reflect not only the requestor’s maximum packet reassembly buffer size, but also the inbound network interface MTU, and where known, the network path MTU value. This working draft currently recommends a maximum buffer size of 1,400 octets.

Measuring EDNS Buffer Sizes

Which brings us to our first measurement question. To what extent do recursive resolvers follow this advice? What are the UDP buffer sizes used in queries from recursive resolvers to name servers?

We have looked at the UDP Buffer size in queries in June 2024, as shown in Table 1 and a cumulative distribution of this data is plotted in Figure 1. This is a query-weighted data set, using data from some 356,939,321 query sample points, collected over nine days from the 25th June 2024 to the 3rd July 2024.

Table 1 shows the top 10 buffer sizes used in queries.

Table 1 – Top 10 UDP Buffer Sizes

Figure 1 – Distribution of UDP Buffer Size values in DNS Queries

Just under 20% of these queries use a UDP buffer size greater than 1,472, which would appear to allow a responder to generate a fragmented UDP response, unless of course it applies its own more stringent size restraints to the UDP response.

Measuring Truncated Responses

The next question is: “How effective is truncation in today’s DNS?”

Do DNS recursive resolvers always ignore the answer and additional sections of a DNS response if the truncated bit is set? And what proportion of resolvers are capable of performing a DNS query over UDP in response to a truncated UDP response?

    example.com zone
      child NS ns1.oob.example.net.

    oob.example.net zone
      ns1  IN   A   192.0.2.1

    child.example.com zone
    .    IN    A   203.0.113.1

In this case we have modified the behaviour of the DNS server for the second zone (oob.example.net), such that all UDP responses to queries for name server names in this zone are truncated. We also use a categorization of these names such one half of experiment’s unique name set causes the nameserver to generate a truncated response (TC=1) with an empty answer section and the other half of the query names generate a perfectly normal complete DNS response with an intact and complete answer section, but with the TC bit set indicating (incorrectly in this case) that the UDP response has been truncated.

If the DNS resolver is using the contents of a truncated UDP response, then it will be able to obtain the IP address of the nameserver and make the third query without needing to requery using TCP. A standards-compliant resolver will ignore the answer section of the UDP response that had the truncated bit set and requery using TCP and use the TCP response to make the third query.

The behaviours are determined by performing a full recording of all packets that arrive at and leave our servers, and then analysing these packets to determine the DNS resolution query and response sequences for each individual experiment.

In a test conducted over June 2024 we found results as shown in Table 2.

Table 2 – Incidence of Use of Answer Section in Truncated Responses

Across some 394 million sample points, some 197 million tests were provided with a complete answer section as well as having the truncated bit set. Of these some 96,401 tests did not requery using TCP, but performed the third target query, evidently using the contents of the answer section in the truncated response. The ten network with the highest proportional use of truncated answers is shown in Table 3.

Table 3 – Incidence of Use of Answer Section in Truncated Responses – Top 10

These results suggest that globally this aspect of DNS conformance to standards-specified behaviour is not a severe problem, and the incidence of the use of the answer section contained in truncated responses is just 0.05% of all samples. However, as shown in Table 3, the incidence of this DNS resolver behaviour in specific networks is not so small, and this table lists the 10 networks with the highest incidence of the use of truncated responses where more than 100 samples were gathered over the month of June 2024.

Measuring TCP Requery

The second part of a resolver’s actions when receiving a DNS response over UDP that has the truncated bit set is to requery using TCP. The related measurement question is: What proportion of resolvers are incapable of performing a DNS query over TCP?

The overall results are shown in Table 4.

Table 4 – TCP Use Profile