Subject: [DNSOP] DNSOP Presentation "The Camel"

From: tjw ietf <[email-masked]>
Date: Tue, 20 Mar 2018 07:29:50 +0000

All

At the end of Tuesday's session we're having Bert Hubert from Power DNS
give a talk on what he views "The Camel".   He sent us a short abstract:

"In past years, DNS has been enhanced with DNSSEC, QName Minimization, EDNS
Client Subnet and in-band key provisioning through magic record types.  It
is now also seeing work on 'DNS Stateful Operations', XPF, ANAME (ALIAS),
resolver/client encryption, resolver/authoritative encryption & KSK
signalling/rollovers.
Each of these features interacts with all the others. Every addition
therefore causes a further combinatorial explosion in complexity.
Up to now, the increase in DNS complexity (mostly driven by DNSSEC) has been
made possible by the huge pool of programming talent, mostly in the open
source world.
This presentation sets out, with examples, how innoccuous features
contribute
to the combinatorial rise of complexity, and how we might ponder thinking
twice before loading up this camel further."

https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-00

Now, before everyone jumps into the deep end here, we suggest one read RFC
8324, published February of this year https://tools.ietf.org/html/rfc8324 by
John Klensin.   John discusses very similar subject matter. Bert's talk has
a more "operational" focus, which is what caught this chair's eye (since
many in the WG worry about operational issues).  I believe the authors
would agree they are complementary in nature.

(If I am incorrect, the authors are free to castigate me)

thanks
Tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Mar 2018 15:12:01 +0000

On Tue, Mar 20, 2018 at 07:29:50AM +0000,
 tjw ietf <[email-masked]> wrote 
 a message of 94 lines which said:

> give a talk on what he views "The Camel".

Unlike the popular saying
<https://en.wikipedia.org/wiki/Design_by_committee#Aphorisms>, camels
are extraordinary animals, well adapted to their harsh environment
<https://en.wikipedia.org/wiki/Camel#Ecological_and_behavioral_adaptations>
and usable for many things, even war
<https://en.wikipedia.org/wiki/Camel_cavalry>. If the DNS is a camel,
this is great!

> "In past years, DNS has been enhanced with DNSSEC, QName
> Minimization, [...]

I dispute the idea that QNAME minimization is an addition. It is not a
change in the protocol, and it was even possible from the beginning
(Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
QNAME maximimization, it is just an accidental evolution).

---

From: Joao Damas <[email-masked]>
Date: Tue, 20 Mar 2018 16:04:31 +0000

Camels are indeed great animals and they can be loaded until eventually one more insignificant straw breaks their back. I guess that is were Bert thinks the DNS is at now and I don’t completely disagree

Joao

> On 20 Mar 2018, at 15:12, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: P Vix <[email-masked]>
Date: Tue, 20 Mar 2018 16:10:36 +0000

When Ed have up defending the qtuple, complexity moved in.

On March 20, 2018 4:04:31 PM UTC, Joao Damas <[email-masked]> wrote:
>Camels are indeed great animals and they can be loaded until eventually
>one more insignificant straw breaks their back. I guess that is were
>Bert thinks the DNS is at now and I don’t completely disagree
>
>Joao
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Mar 2018 14:23:03 -0700

Joao Damas wrote:
> Camels are indeed great animals and they can be loaded until
> eventually one more insignificant straw breaks their back. I guess
> that is were Bert thinks the DNS is at now and I don’t completely
> disagree

i was pretty horrified even before ECS. dnssec sentinels feels like 
friday the 13th part 37. there were danger signs saying "don't go here, 
there's no road, nothing to see, and no way back" and we ignored them.

see also:

https://queue.acm.org/detail.cfm?id=1242499

-- 
P Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 20 Mar 2018 17:45:39 -0400

Paul Vixie wrote:
> i was pretty horrified even before ECS. dnssec sentinels feels like friday
> the 13th part 37. there were danger signs saying "don't go here, there's no
> road, nothing to see, and no way back" and we ignored them.

Speaking of being horrified, compare the growth rate on the graph on
slide 2 in this presentation:

https://indico.dns-oarc.net/event/28/session/11/contribution/55/material/slides/1.pdf

With the growth rate on the graph in this article for the same time
period:

https://www.recode.net/2017/4/27/15413870/comcast-broadband-internet-pay-tv-subscribers-q1-2017

A hybrid resolution model that allows leaf queries for parts of the DNS
to be resolved direct-to-authority at endpoints would be very helpful
for some use cases (especially, CDNs) and could stall the insatiable
growth in resolution capacity needed at centralized resolvers. Not to
mention, such a model would provide a solid deprecation path for ECS.

I also note most but not all of the stuff Bert is talking about in his
slide deck are on the inter-server side of the protocol (resolver to
authority). But there are also other DNS camels that have been slowly
gestating in the browser world, e.g.:

https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok

https://bugzilla.mozilla.org/show_bug.cgi?id=1434852

-- 
Robert Edmonds

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Mar 2018 09:44:07 +1100

QNAME minimisation failures happen for 2 reasons.

1. Bad implementations of DNS that don’t return ENTs in a zone.

2. Failure to add delegating NS records to the parent zone resulting
   in no ENT being emitted when both the child and parent server are
   served by the same server.

If we had kept going with bit-string labels querying for the longest
sequence of labels on the RHS without a bit-string label would have
been been the way to get to the servers that supported bit-string labels.

DNS COOKIES has problems because there are bad implementations of EDNS
out there.  Whatever we did when introducing them ran up against broken
implementations (includes bad firewalls) (DNS COOKIES alone or EDNS(1) and
DNS COOKIES).

1. Servers that DO NOT respond to queries with EDNS options present.
2. Servers that return BADVERS, NOTIMP to EDNS queries (STD13 says return
   FORMERR to unknown queries).  RFC 6891 turned this to NOERROR on unknown
   EDNS option.
3. Servers that echo back the option, who is insane enough to send bits that
   you don’t understand them meaning of! (this one is not fatal for DNS COOKIE).
4. Servers that don’t return BADVERS to EDNS(1) + EDNS Options but return FORMERR.
5. Servers that don’t answer EDNS(1) + EDNS Options.
6. Load balance front ends that punted to poorly configured backends when they
   saw a EDNS option.  This leads to NXDOMAIN and other bad data being returned.
7. Other random rcodes.

All of this was testable for by developers when they introduce EDNS to
their servers. EDNS has 3 extension mechanism. That is not a lot of test
case to write and think about does the response you see make sense?

EDNS(1) query                                   (behaviour fully described in RFC 2671)
EDNS unknown option query                       (behaviour fully described in RFC 6891)
EDNS unknown flag query                         (behaviour fully described in RFC 2671)
EDNS(1) query + EDNS unknown option             (behaviour fully described in RFC 6891)
EDNS(1) query + EDNS unknown flag               (behaviour fully described in RFC 2671)
EDNS unknown option + EDNS unknown flag         (behaviour fully described in RFC 6891)
EDNS(1) query + EDNS option + EDNS unknown flag (behaviour fully described in RFC 6891)

One shouldn’t have to say to DNS developers “test you servers against
possible extension methods before you ship it!"  That should be part
and parcel of adding EDNS support.

I can find servers that fail one or more of every one of these tests.

> On 21 Mar 2018, at 2:12 am, Stephane Bortzmeyer <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]