DNS Camel

The DNS Camel refers to the complexity and density of protocols and operations within and throughout the Domain Name System. Referencing the "straw that broke the camel's back", Bert Hubert's 2018 presentation to the IETF's DNSOP Working Group at the 101st IETF Meeting was tentatively titled "The DNS Camel, or, how many features can we add to this protocol before it breaks." The agenda shortened the title to "The DNS Camel." Hubert's presentation was based in part on his development of a tool that tracked RFCs that discussed the protocols and standards of the DNS.

Origins and Usage

Hubert notes that, as early as 2000, Randy Bush was using the analogy of a "camel" (as well as the precursor pack animal of the "last straw" metaphor, the horse), in a presentation to IETF at its 49th meeting entitled "The DNS Today: Are we Overloading the Saddlebags on an Old Horse?" Bush posited that multiple factors, including user expectations, application development demands, design by committee, and others were pushing DNS operators to continue adding loads onto the DNS architecture. Bush's presentation was bolstered by his uses of the "last straw" metaphor, which emphasized that the addition of a small burden could cause a surprising, global, and catastrophic effect.

Common usage of the phrase "DNS Camel," however, appears to largely date to Hubert's presentation, as well as his development of the "DNS Camel" tracker for RFCs related to the DNS, which was also posted to GitHub in March 2018

• Hubert noted a lot of continued discussion about the "DNS Camel" at IETF 101.
• A since-expired Internet Draft from November 2018, dealing with simplifying EDNS implementation, employed the tag "camel-diet" in its document ID.

Issues

Both Bush and Hubert were presenting at a time when the complexity of the DNS was rapidly expanding. Bush's presentation dealt substantially with the development of DNSSEC, IPv6, internationalization, and related technological headaches and gaps. Hubert saw a comparable situation arising in 2018:

Based on a wonderful chart compiled by ISC, I found that the DNS is now described by at least 185 RFCs. Some shell-scripting and HTML scraping later, I found that this adds up to 2,781 printed pages, comfortably more than two copies of ‘The C++ Programming Language (4th edition)’. This book is not known for its brevity...

...My claim is that this rise is not innocent. As DNS becomes more complex, the number of people that ‘get it’ also goes down. Notably, the advent of DNSSEC caused a number of implementations to drop out (MaraDNS, MyDNS, for example). Also, with the rise in complexity and the decrease in the number of capable contributors, the inevitable result is a drop in quality...

...And in fact, with the advent of DNSSEC, this is what we found. For several years, security and stability bugs in popular nameserver implementations were absolutely dominated by DNSSEC and cryptography-related issues.

Bush and Hubert both identify one of the key issues as an unwillingness to say "no" to feature requests. Hubert also sees the "resume boosting" aspect of RFC authorship to be a problem:

Authoring an Internet-Draft and getting it published as an RFC is an achievement, a CV-worthy accomplishment. People work hard on it. In fact, within many employers, getting such documents issued is actually an agreed performance target. “Well done”. So the growth in DNS standards text is far from an accident – it is baked into our constellation of active standardizers, willing implementors, and lack of operational guidance to hold us back.

In a subsequent blog post for IETF, Hubert provided an updated list of proposed next steps to help unburden the camel:

• Stop writing new RFCs
• Modernize or rewrite existing RFCs
• Obsolete old protocols or standards
• Make DNS operation more accessible