The DNS Camel
Or
How many features can we add to this protocol before it
breaks?
Bert Hubert / [Link]@[Link]
185 RFCs
2781 pages / 166891 lines
888233 words
This is 2 times “The C++ Programming
Language” (4th ed)
Good words on this are in RFC 8324
In the field stub resolver
char resppacket[512];
unsigned int ip_address;
char *ptr=resppacket+12;
/* receive */
while(!(*ptr==0xc0 && *(ptr+1)==0x0c)) ptr++;
memcpy(&ip_address, ptr+6, 4);
Did not read 1 of those 2781 pages
DNS Cookies
CDNSKEY
DNS over TLS
QNAME
Minimization
Complexity ECS
NSEC3
A6 / Binary Labels
TSIG DNSSEC
DNAME
Time
Extended errors
dprive-*
bulk-rr
session-
signal
Multiple-
answers/qtypes
aname
Catalogue
Complexity DoH zones
serve-
stale
Time
Extended errors
dprive-*
bulk-rr
session-
signal
Multiple-
answers/qtypes
aname
Catalogue
# of people DoH zones
able to get it
serve-
stale
Time
Extended errors
dprive-*
bulk-rr
session-
signal
Multiple-
answers/qtypes
aname
Catalogue
Quality, DoH zones
security
serve-
stale
Time
Implementers
Operators
“People” DNS
Standardizers
Implementors
● We should be AWED by the quality of open source implementations
a. bind, knot, kresd, unbound, NSD, there is SO much great software out there
b. Perhaps one of the best served protocols on the internet!
● Very gifted programmers, among the smartest in the world
● So far, they (we) have been able to implement most things, eventually correctly
● For us, saying “no, this is too complicated” is very hard
a. Pride
b. “One of the other implementations will do it”
c. Always fun to work on new challenges
● We do not have well developed “product management”
a. Any individual committer can decide “cool feature, let’s do it”
Operators
● Commercial access provider operators are
a. On call 24/7
b. Being measured solely on availability, performance
c. May actually be penalized by their governments if they do the right thing
● Typically resource constrained, understaffed
● Have no “buy in” from the rest of the access provider to work on privacy
enhancing features
a. In fact…
● Weakly represented in the standards making process
a. With some notable exceptions
● Typically turn off anything that could cause problems at 3AM
ccTLD / root / authoritative operators
● ccTLD/gTLD/root operators are well represented
a. Significant authoritative hosters (“tens of millions of domains”) are not
● Notably, authoritative implementation of features is rather simpler usually
a. “Just serve the data”
b. Almost stateless
● Easy to load balance - even a server that answers 20% of questions will
provide good service to the internet
a. .BE and .NL servers have been down for hours or months without anyone noticing
● Notably, the one contribution from the operational community, that is widely
deployed, did not get standardized (RRL)
Standardizers
● Like implementers, among the smartest people in the world
a. Share enthusiasm for hard challenges
● On a mission to turn the internet into “how things SHOULD be and what the
code MUST do to achieve that”
● Try very hard to think of everything
● Typically not on call 24/7
● Undervalue operational trade-offs
● Simultaneously optimists (on what can be achieved) and pessimists (how folks
will mess it up unless everything pinned down by standard)
Unexpected interaction of features
● DNAME needs DNSSEC special casing
● EDNS Client Subnet leads to zero cache hit rates
○ And associated, non-standardized, workarounds
● Qname minimization turns out to need a ton of probing
● Outbound TLS usage leads to ton of probing
● DNS cookies lead to ton of probing
● Multiple answers/qtypes lead to ton of probing
● Most features are not orthogonal to the other features
○ Especially on the resolver side!
Net result
● Push to enhance DNS further and further from standards community
● Little push-back from implementation community
● Commercial operational community very weakly represented “and they don’t
want anything new anyhow”
● Proposed features that SHOULD make the internet better are very likely to
be accepted and implemented
○ With little open discussion on how hard this will be
● Given relatively constant base of developers, increase in feature volume will
mean decrease in quality
● Eventually, glut of features will cause statis
Proposal
● Think long and hard who wants a feature and who would benefit
● Conversely, who would bear the costs?
○ In terms of development, operational stability/quality impact, downstream complexity
● Involve development community more comprehensively
○ It is not enough for ‘bert’ or ‘wouter’ or ‘ondrej’ to feel that it could in theory be done
● Developer community develop some spine & “product management”
● Work ever harder to involve operational community
○ Not easy for them to come to IETF and similar venues
○ Not authorized to speak
○ No travel budget
● Thank you.