The DNS Flag Day is an initiative of Domain Name System (DNS) vendors (both open-source and proprietary) and DNS operators.
It aims to make the DNS protocol more reliable, secure, and resilient while gradually removing workarounds for broken DNS behaviour. Sometimes it takes a coordinated group effort to remove support for a broken behaviour; if only one DNS server package implemented new rules on its own, users could simply use different software that still permitted the unsupported behaviour.
The first-ever DNS Flag Day was held on 1 February 2019. It targeted removing a workaround to accommodate DNS authoritative servers that incorrectly handled the Extensions to DNS (EDNS) protocol.
Read: Measuring the impact of DNS Flag Day
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.
What’s the purpose of this year’s Flag Day?
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 the DNS: IP fragmentation.
The truth is that the 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 User Datagram Protocol (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 1,500, 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 gets even more complicated with the introduction of IPv6, where the packet must be fragmented by the sender; there’s a specialized Internet Control Message Protocol (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 IPv6 fragmentation unfixable.
Read: Dealing with IPv6 fragmentation in the DNS
Even if we could fix all the broken networking equipment, and all the broken configurations, IP fragmentation makes certain attacks on the 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.
DNS Flag Day 2020, happening on 1 October, is an effort to fix IP fragmentation in the 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 1,220-1,232 bytes.
The second change stems from the first one; when the DNS response won’t fit into a UDP packet, the default behaviour of the DNS is to fall back to TCP. That means that either you MUST make sure all your DNS responses fit into a ~1,220-byte maximum packet size, or both the DNS client and the DNS server MUST be able to communicate via TCP.
What does it mean for:
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 the 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 honour 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 honouring 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 honour 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.
Adapted from original post which appeared on ISC’s Blog.
Ondřej Surý is a Director of DNS Engineering at ISC where he is responsible for BIND development.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.