The servers in question are those running outdated software, which doesn't support the EDNS extension to the DNS protocol. However, the problem that DNS software developers want to address is broader: over the decades, their code has been extended so much that it's becoming an issue. Further code clean-up initiatives can therefore be expected in the future.
"Nearly a quarter of our code is there to facilitate workarounds and corner cases," says Benno Overeinder, CEO of NLnet Labs, responsible for the development of the Unbound resolver. "The current situation has a long history. When EDNS was introduced -- mainly to support DNSSEC -- we were obliged to add code in order to continue communicating with servers that hadn't implemented the DNS protocol correctly or fully. It was all about ensuring that the product met the user's needs. However, it meant that we were picking up the tab for things that other people should have done.
"Over the last five or six years, the DNS software development community has come around to thinking that we can't go on this way. Last year, that led to an initiative from CZ.NIC, the registry for the Czech .cz country-code TLD and developer of the Knot DNS server. Their idea was to get a joint strategy agreed. After all, interoperability is an issue for the entire DNS community, not just for developers."
Peter van Dijk, Senior Engineer at PowerDNS, explains the practicalities of realising a resolver workaround for non-compliant DNS servers: "If we don't get a response from a server because it can't handle EDNS queries properly, first we simply try again. If there's still no response, we try an alternative name server. The problem there is that all of a given domain's servers are often running the same software. So then we have to try the query with various EDNS flags disabled. And, if all else fails, we send a query that doesn't include any EDNS flags at all. That whole process easily takes ten seconds or more and involves sending numerous network packages. What's more, having all the workarounds makes the code complex and harder to maintain, which in turn has security implications."
As well as practical workarounds to keep everything going, resolver software includes 'corner cases': protocol-level interactions, interpretations and exceptions. They're needed because internet protocols often continue developing for several decades. Over time, a standard that began as an extremely elegant solution is modified repeatedly to address unforeseen issues and new developments, until it becomes a complex patchwork.
Nearly a year ago, Bert Hubert, founder of PowerDNS, wrote a blog post warning about the growing complexity of the DNS and the interactions between entities. That makes software development and maintenance more difficult, with knock-on implications for the stability of the infrastructure, the diversity of the ecosystem and the scope for innovation. He identified DNSSEC and NSEC3 as important drivers of complexity and the need for interpretation. Hubert ended his post by calling for the community to take a cautious approach to the addition of new features and standards, and to involve software developers and operators more in the design process.
Test your name server
Ahead of DNS Flag Day, registrants and operators are advised to check their domain names (or, more precisely, their name servers) for EDNS compliance. To do that, you can visit the DNS Flag Day homepage and use ISC's EDNS Compliance Tester [1, 2].
In recent weeks, SIDN Labs has been looking closely at this problem. That has led to various .nl domain name operators being alerted to issues, which they have since addressed. As a result, DNS Flag Day's impact on the .nl zone is expected to be minimal.