3,197
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + + + + + + + + + + + +
no edit summary
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"<ref name="wikipedia">[https://en.wikipedia.org/wiki/Straw_that_broke_the_camel%27s_back Wikipedia.org - Straw that Broke the Camel's Back]</ref>, [[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."<ref name="hubert">[https://blog.apnic.net/2018/03/29/the-dns-camel/ APNIC Blog - The DNS Camel], Bert Hubert, March 29, 2018</ref> The agenda shortened the title to "The DNS Camel."<ref name="hubert" />
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"<ref name="wikipedia">[https://en.wikipedia.org/wiki/Straw_that_broke_the_camel%27s_back Wikipedia.org - Straw that Broke the Camel's Back]</ref>, [[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."<ref name="hubert">[https://blog.apnic.net/2018/03/29/the-dns-camel/ APNIC Blog - The DNS Camel], Bert Hubert, March 29, 2018</ref> The agenda shortened the title to "The DNS Camel."<ref name="hubert" /> Hubert's presentation was based in part on his development of a tool that tracked [[RFC]]s that discussed the protocols and standards of the DNS.<ref name="hubert" />
==Origins and Usage==
==Origins and Usage==
Hubert notes that, as early as 2000, [[Randy Bush]] was using the analogy of a "camel"<ref>[https://www.ietf.org/proceedings/49/slides/PLENARY-3/sld043.htm IETF 49 Archive - "How we Made this Camel" slide from The DNS Today: Are we Overloading the Saddlebags on an Old Horse?], December 13, 2000</ref> (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?"<ref name="bush">[https://www.ietf.org/proceedings/49/slides/PLENARY-3/index.html IETF 49 Archive - Plenary Session - The DNS Today: Are we Overloading the Saddlebags on an Old Horse?], presented by Randy Bush, December 13, 2000</ref><ref name="hubert" /> Bush posited that multiple factors, including user expectations, application development demands, design by committee, and others were pushing DNS operators to continuing 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.<ref name="wikipedia" />
Hubert notes that, as early as 2000, [[Randy Bush]] was using the analogy of a "camel"<ref>[https://www.ietf.org/proceedings/49/slides/PLENARY-3/sld043.htm IETF 49 Archive - "How we Made this Camel" slide from The DNS Today: Are we Overloading the Saddlebags on an Old Horse?], December 13, 2000</ref> (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?"<ref name="bush">[https://www.ietf.org/proceedings/49/slides/PLENARY-3/index.html IETF 49 Archive - Plenary Session - The DNS Today: Are we Overloading the Saddlebags on an Old Horse?], presented by Randy Bush, December 13, 2000</ref><ref name="hubert" /> Bush posited that multiple factors, including user expectations, application development demands, design by committee, and others were pushing DNS operators to continuing 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.<ref name="wikipedia" />
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 [[RFC]]s related to the DNS,<ref>[https://powerdns.org/dns-camel/ PowerDNS.org - DNS Camel]</ref> which was also posted to GitHub in March 2018<ref>[https://github.com/ahupowerdns/protocol-camel/graphs/contributors Github - protocol-camel Contributor Graph]</ref>
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 [[RFC]]s related to the DNS,<ref>[https://powerdns.org/dns-camel/ PowerDNS.org - DNS Camel]</ref> which was also posted to GitHub in March 2018<ref>[https://github.com/ahupowerdns/protocol-camel/graphs/contributors Github - protocol-camel Contributor Graph]</ref>
* Hubert noted a lot of continued discussion about the "DNS Camel" at IETF 101.<ref name="hubert" />
* A since-expired Internet Draft from November 2018, dealing with simplifying EDNS implementation, employed the tag "camel-diet" in its document ID.<ref>[https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/ IETF Data Tracker - Internet Draft: Minimal EDNS compliance requirements], last updated November 30, 2018</ref>
==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]] and related technological headaches and gaps.<ref name="bush /> In 2018, Hubert saw a comparable situation arising in 2018:
<blockquote>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...<br />
...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).<br />
Also, with the rise in complexity and the decrease in the number of capable contributors, the inevitable result is a drop in quality...<br />
...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.<ref name="hubert" /></blockquote>
Bush and Hubert both identify one of the key issues as an unwillingness to say "no" to feature requests.<ref name="bush" /><ref name="hubert" />
==References==
==References==
{{reflist}}
{{reflist}}
__NOTOC__
__NOTOC__