February 1, 2019 was DNS Flag Day. You’re forgiven if you didn’t know that: The date passed without much fanfare or, as far as I know, any parades. But the date was important nonetheless: Many developers of DNS software and operators of DNS infrastructure banded together to make a change to the way that DNS works on the Internet. The result of that change was positive: Name resolution is faster on average for Internet users. But there was a cost, too: We lost the ability to resolve domain names hosted on older DNS servers that were broken with respect to EDNS0, a set of extensions to DNS written way back in 1999. (But let’s face it: If you can’t get it right in 20 years, you’re unlikely to ever fix it.)
In fact, DNS Flag Day was so successful that they’re planning another one! DNS Flag Day 2020 will be on October 1, 2020. This time, they’re tackling something called fragmentation. Basically, when DNS messages are big, the Internet Protocol or IP layer must fragment them to carry them over networks that can’t handle packets that large. But this can cause problems. Fragmentation isn’t always reliable and can cause transmission failures. Even when fragmentation works, it may introduce security risks.
DNS Flag Day 2020 is being driven by a community of DNS software and service providers, and supported by an organization called DNS-OARC, which researches and coordinates DNS operations on the Internet. Starting on DNS Flag Day 2020, DNS developers and operators will begin to reduce the size of UDP-based DNS messages their software sends over the Internet to minimize the chance of fragmentation. In some cases, this will cause those DNS servers to send truncated responses over UDP, which will induce the DNS servers that receive those truncated responses to retry their queries over TCP.
For most of us, this won’t cause any problems at all: Every RFC-compliant DNS server can process queries received over both UDP and TCP. And we all have our firewalls configured to allow TCP-based queries to and from our DNS servers, right? Right?
For the small number of DNS servers that don’t support TCP and the few operators who don’t allow TCP-based queries or responses, however, this may cause problems. That’s why it’s important that there be a coordinated flag day: so the first developer or operator to induce this behavior doesn’t get singled out as causing resolution problems.
Infoblox supports DNS Flag Day 2020 (as we did the first DNS Flag Day). With the release of NIOS 8.5.1 on April 30, 2020, we’ll be changing the defaults on our DNS servers to send DNS messages that won’t cause fragmentation on most networks.[1] And in doing so, we hope we’re doing our small part of making DNS on the Internet more reliable and more secure.
NIOS 8.5.1 information:
Product page: https://www.infoblox.com/products/nios8/
New Datasheet: https://www.infoblox.com/resources/datasheets/dns-flag-day-2020
Solution Note: https://www.infoblox.com/resources/solution-notes/nios-8
Service Provider page: https://www.infoblox.com/solutions/service-providers/
DNS Caching page: https://www.infoblox.com/solutions/service-providers/secure-dns-caching/
[1] You’ll likely still be able to configure the default maximum size of a UDP-based DNS message, but we hope you’ll see the wisdom in leaving it at a value that doesn’t cause fragmentation.
