DNS Flag Day 2020

This is a repost of a blog we originally posted in August 2019 about DNS Flag Day 2020. Our lead support engineer, Cathy Almond, recently gave a short presentation at the Virtual UKNOF conference about DNS Flag Day 2020; her remarks are here.

The DNS Flag Day is an initiative of DNS vendors (both open-source and proprietary) and DNS operators. Its aim is to make the Domain Name System (DNS) protocol more reliable, secure, and resilient while gradually removing workarounds for broken DNS behavior. Sometimes it takes a coordinated group effort to remove support for a broken behavior; if only one DNS server package implemented new rules on its own, users could simply use different software that still permitted the unsupported behavior.

The first-ever DNS Flag Day was held on February 1, 2019. It targeted removing a workaround to accommodate DNS authoritative servers that incorrectly handled the Extensions to DNS (EDNS) protocol. DNS software vendors, working together, pledged to release versions of their DNS server implementation with these workarounds removed. As a result of the DNS Flag Day 2019, we’ve seen DNS vendors and operators all around the globe finally standardize their DNS server implementations correctly.

For DNS Flag Day 2020, the idea is the same: make the Internet a better place through a coordinated effort across participating DNS implementers, vendors, and operators. This time, however, the target might seem not directly related to DNS: IP fragmentation. The truth is that DNS is one of the few prominent users of IP fragmentation. When DNS messages are transferred between the DNS server and a DNS client over UDP, they can exceed the Maximum Transfer Unit (MTU) on any part of the path between the two endpoints. The MTU might vary between any two interconnects; while the standard MTU of Ethernet is 1500, the unit size is effectively reduced by encapsulation into different protocols (the most basic example would be VPN). When the MTU is exceeded, the IP packet gets fragmented (split into more parts) and reassembled.

This IP fragmentation is considered fragile and harmful by many; there’s an IETF Draft that describes IP fragmentation and how it makes Internet communication less reliable. The situation got even more complicated with the introduction of IPv6, where the packet must be fragmented by the sender; there’s a specialized ICMP message for that, which (not so surprisingly) might get blocked by incorrectly configured firewalls. Our APNIC colleague, Geoff Huston, did measurements on IPv6 fragmentation and he also considers the IPv6 fragmentation unfixable.

Even if we could fix all the broken networking equipment, and all the broken configurations, IP fragmentation makes certain attacks on DNS possible. As the DNS Query ID and UDP port are carried in the first IP fragment, a clever attacker might spoof the second fragment and poison the DNS cache by swapping the subsequent good IP fragments with their own. If you are interested in the topic, I would recommend you read this presentation by Fujiwara-san: Measures against cache poisoning attacks using IP fragmentation in DNS.

DNS Flag Day 2020 is an effort to fix the IP fragmentation in DNS by making small, albeit important, changes. First, the default maximum EDNS Buffer Size will be changed to a value that would prevent IP fragmentation. The recommended value is going to be slightly smaller than the minimum IPv6 fragment size, around 1220-1232 bytes. The second change stems from the first one; when the DNS response won’t fit into a UDP packet, the default behavior of DNS is to fall back to TCP. That means that either you MUST make sure all your DNS responses fit into a ~1220-byte maximum packet size, or both the DNS client and the DNS server MUST be able to communicate via TCP.

What does it mean in detail?

Authoritative DNS Servers

Authoritative DNS servers must be able to respond to DNS queries using the TCP protocol. Beware: even if the DNS server itself might correctly support the TCP protocol, which has been an integral part of DNS from day one, there might be a zealously configured firewall sitting in front of the DNS server blocking the TCP communication over port 53. Next, the maximum accepted EDNS buffer size will be set to ~1220 bytes; the authoritative DNS server MUST honor the requested EDNS buffer size and never send a DNS response larger than the requested size.

BIND 9 is already compliant with the TCP and honoring the EDNS buffer size requirements, and you can already configure your BIND 9 server to never send DNS responses larger than ~1220 bytes, by adding max-udp-size 1220; to the options {}; section of named.conf:

    options {
	    max-udp-size 1220;
	};

Recursive DNS Servers

Recursive DNS servers must honor all the same requirements as authoritative DNS servers, with the extra requirement that they must never advertise an EDNS buffer size larger than ~1220 bytes. They must also be ready to fall back to requery using TCP, if a truncated DNS response is received.

Again, BIND 9 is already compliant with the hard requirements; you can test changing the maximum advertised EDNS buffer size by setting edns-udp-size 1220; in the options {}; section of named.conf:

    options {
	    edns-udp-size 1220;
	}

Other Changes in BIND 9

Currently, BIND 9 tries very hard to guess the maximum allowed EDNS buffer size that will be accepted by the DNS server on the other side. We will not, for the time being, remove the code that makes this possible, and we will not limit the maximum EDNS buffer size that a BIND 9 user can configure. We may add a warning when the user configures the EDNS buffer size beyond the limit proposed by the EDNS Flag Day 2020.

The only end-user visible change will be the change of the default configuration for the edns-udp-size and max-udp-size configuration options.