"DNS protocol is too complex, and software implementations need to be better"

The DNS Camel

Even 5 years ago, Bert Hubert, co-founder and then lead architect of PowerDNS was warning the IETF 101 conference about the rampant growth in the complexity of the DNS protocol. We can't go on extending the DNS without creating insurmountable problems, he argued.

The problem flagged up by Hubert has since become known as 'The DNS Camel' (referencing 'the straw that broke the camel's back' to imply that incremental additions are unsustainable). He claimed even then that there were 185 RFCs relating to DNS implementation, running to a total of 2,781 pages. In the meantime, the number of RFCs and pages has increased still further.

Rampant growth

The consequences of the rampant growth of DNS functions and accompanying RFCs are increasing complexity (e.g. due to functions interfering with one another), a growing shortage of people who fully understand the protocol, and decline in the quality and security of implementations. Hubert accordingly appealed to the community to be cautious about extending the DNS protocol further, to consolidate the standards, and to coordinate future initiatives.

RFC 9364

The publication of RFC 9364 earlier this year was a small step forward. The primary purpose of RFC 9364 is to catalogue all previous DNSSEC-related RFCs and clarify their interrelationships. The RFC has also been published as Best Current Practice (BCP) 237, meaning that the implementation of DNSSEC is now formally recognised as norm.

Central to the document is a very accessible summary of the RFCs that define, extend and update DNSSEC. RFC 9364 does not amend any previously published RFC, or give detailed consideration to the content of any earlier RFC. The document serves primarily as a central DNSSEC reference portal.

Logical step

"Referring to the various standards that make up DNSSEC has been getting more difficult over time," explains Paul Hoffman, Distinguished Technologist at ICANN and author of RFC 9364. "Initially, you could just say 'RFCs 4033, 4034, and 4035', but even that was clumsy. Those RFCs acquired significant updates as DNSSEC was deployed more widely, so just listing the 3 original RFCs was not really accurate. Making one short document that had the most up-to-date information saying what DNSSEC was seemed logical."

So too was publication of the RFC as a BCP. "Nearly everyone in the DNS community agrees that DNSSEC is the obvious best practice for the authentication of DNS data. Calling this one document a BCP was an easy decision."

Software developers

The developers of open-source DNS software have previously taken the initiative to organise 2 DNS Flag Days [1] (in 2019 and 2020). Run in collaboration with the major operators, the events were important steps towards the convergence and consolidation of the various DNS server packages. "The Flag Days weren't a response to the DNS Camel problem, but to incorrect or incomplete implementations of existing standards," clarifies Benno Overeinder, Managing Director at NLnet Labs. "The open-source developers had previously been providing workarounds to accommodate incorrectly configured name server software. Although the motivation was different, the aim was the same: to reduce the complexity of DNS software."

Although Overeinder agrees with Hubert that new functionality increases the complexity of implementations, he doesn't believe that the increasing complexity has so far had adverse consequences for the quality of the DNS software produced by NLnet Labs. Nevertheless, developments surrounding the DNS standardisation process do require close monitoring, because greater complexity increases the risk of errors that could affect the security and stability of the software.

Prompt error correction

"The open-source DNS software developers were already working more closely together before Hubert's DNS Camel presentation," adds developer and researcher Willem Toorop. "Maybe collaboration began with the IETF Hackathons, but they certainly worked together via CZ.NIC's Slack channel, whose role has since been assumed by the DNS-OARC's Mattermost server."

"It's too early to assess the impact of RFC 9364," says Overeinder. "For developers, it's a 'canonical' document identifying the RFCs that have to be implemented in order to realise DNSSEC support. The hope is, of course, that the quality of existing implementations will increase. The open-source implementations already meet all the standards, but it's harder to be sure about proprietary software. However, incorrect behaviour is usually picked up quickly, and discussed on open forums such as the DNS-OARC mailing list. That generates enough pressure to ensure that clear flaws are soon rectified."

Contrasting views

Hoffman emphasises that he is one of the minority that has difficulty with the concept of the DNS Camel. "The camel analogy illustrates that DNS people are too inward-looking. Other important internet standards, such as TCP, also have numerous extensions and updates, but that isn't labelled as undesirable. The DNS is central to an evolving internet: we should not be negative about the fact that the DNS needs to evolve as well. Look at what has changed in the years since the camel analogy was floated: nearly nothing. The DNS is still a growing protocol."

Hoffman also takes the view that the DNS Flag Days cause as many problems as they solve. "The first few Flag Days had much stronger justification than the ones being proposed now. Flag Days deliver visible improvements, but also invisible or barely visible friction at the edges. We can't measure that and, even if we could, saying whether it is important is purely a value judgement."

"Personally, I would say that there should probably be no more Flag Days, because the most important improvements have already been realised. But the problems that the software developers are trying to deal with by organising Flag Days are real, operational issues that cause ossification of the protocol. However, I defer to the DNS operators, who are the people most affected by the harms that the Flag Days reduce."

Another Flag Day

"As things stand, there are no firm plans for another DNS Flag Day," says Toorop. "If there is one, it'll probably be about ending workarounds for authoritative servers that generate incorrect NSEC records. That creates problems with QNAME minimisation (RFC 7816) and aggressive cache use (RFC 8198). However, those technologies are currently used by too few resolvers for those problems to be a big issue. It would, incidentally, be good if operators enabled those options, since that would improve performance, privacy and protection against certain types of attack (e.g. Pseudo Random Subdomain attacks).

"The DNS protocol is indeed still being actively developed and improved," says SIDN Labs researcher Marco Davids. "Both setting up a modern DNS system and keeping it running have become increasingly complex undertakings." Davids also agrees with Hubert that DNS extensions that are conceived in isolation and subsequently prove to be mutually incompatible nowadays make life a lot more difficult for software developers. "That's reflected in the support for new features on name servers and resolvers. For example, a relatively new option, such as DNS over HTTPS (DoH), is supported by the big tech companies' resolvers – Quad9, Cloudflare and Google Public DNS – while smaller environments such as those run by ISPs can't really keep up."

Davids welcomes the bundling of multiple RFCs under an umbrella document, such as RFC 9364. "It makes everything more accessible for software developers and implementers. I also think that a DNS Flag Day, when software developers work together to roll out a particular improvement at the same time, is definitely a useful way of tackling particular problems."