Subject: [DNSOP] Global DNS architecture changes, "the camel", and so on

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Aug 2018 13:22:11 -0400

Dear colleagues,

Several meetings ago, I was at the mic complaining about various
incremental changes to the DNS architecture and how we didn't seem to
be thinking holistically about the matter.  I think it was in response
to something Ray Bellis said, and Ray quite correctly challenged me to
put up or shut up.  But as too often has been the case in recent
years, I never managed to write down in a coherent form what I was
talking about, and was left to splutter incoherently.  This message is
an attempt to lay out some of the questions that are nagging me, in
the hope that someone else will find them interesting, since it seems
pretty unlikely I'm going to get to put this together more coherently.

This message is inspired in part by watching the exchange between Paul
Hoffman and Stewart Bryant over the DoH I-D progress.  What struck me
there was Stewart's model of how things work: he was wondering how a
client that had a host name was going to resolve anything, if that
host name was its "DNS provider".  I suspect that is actually the
mental model an _awful lot_ of people have: a given host on the
network has a source for resolution service, and that source provides
all the answers.  We (here) all know this is wrong, and has been
essentially forever.  But if large numbers of people continue to hold
this assumption about the basic resolution path, I am prepared to
believe that many things will continue to be built with that
assumption built in.  This means that we need to make the notion of
"resolution context" a first-class notion, so that people understand
that (e.g.) the link-local, homenet, split-brain,
stub-to-full-service-resolution, and DoH contexts are all potential
issues to build into one's assumptions.

Indeed, even as that is going on, the IESG is considering
draft-ietf-ipsecme-split-dns-12.txt.  This follows from the MIF work
some years ago that kind of but not really addressed split DNS and how
it ought to work.

We've also introduced mechanisms for signalling sessions (an idea for
which I was an early proponent, I should note), altered the kind of
queries people make by encouraging minimal queries (this has
interesting consequences for strategies where parent and child zones
are hosted on the same servers), and so on.  This is all part of the
complexity that I think Bert was talking about in his Camel talk.

But I would say that the complexity _might_ be a requirement, and I
think the problem is that we can't tell because we no longer (if we
ever did) have a common and crisp description of what problems we are
trying to solve and how the parts are supposed to fit together.
(There is another claim about the camel -- that it is a horse designed
by a committee.)

I guess, therefore, I want to ask whether long-standing assumptions
about the DNS are still true:

    • Is the stub::full-service resolver::auth server model just over?
    • Do we think resolution context needs signal?  If so, how?
    • Is the age of the stub coming to an end?
    • Do we need something like "submission port for DNS", so that
    large concentrated systems can protect themselves and still
    provide service to important resolvers?
    • Does TCP need to become the norm (particularly for the above use
    case)? 
    • How can we explain these changes to others working on network
    systems?
    • Do we have an appropriate venue to discuss these issues, on the
    presumption that they're not really operations issues?

I really don't know the answer to much of this.  I will note that some
of these are questions similar to those asked by John Klensin in a
draft he put out some time ago, but that I think he has declined to
discuss on this list.

I am aware that perhaps I'm alone in my worries.  If so, you can
continue with your regularly scheduled programming :)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 11:08:34 -0700

Andrew Sullivan wrote:
...
>      • Is the stub::full-service resolver::auth server model just over?

no.

>      • Do we think resolution context needs signal?  If so, how?

yes. DTLS or DOT or DNS Cookies should be the norm, to provide session 
context, and make spoofing of responses or of request IP addresses less 
trivial.

>      • Is the age of the stub coming to an end?

no.

>      provide service to important resolvers?

no.

>      • Does TCP need to become the norm (particularly for the above use

no.

>      • How can we explain these changes to others working on network

better documents. it's rare any more to separate concepts and facilities 
from the specification itself. that should be common.

>      presumption that they're not really operations issues?

no. right now DNS is whatever anybody wants it to be. for example, ECS. 
there is no way to say, "this is a bad idea, and won't be standardized." 
there cannot be a way to do this, inside the ietf as it is. last time 
this was done it was by a "DNS Directorate" put together for that sole 
purpose, and it was extremely controversial -- won't scale.

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Tue, 21 Aug 2018 13:21:04 +1000

I am less sure the UDP/TCP thing reduces to "no"

I see no reason any more to assume session cost is too high for a
globally deployed DNS.

I suspect what DNSOPS and a hypothetical directorate thinks about DNS
is less impactful (sorry, hate that word) than what embeds in Android
devices.

de-facto, the world runs on session mediated services. BGP has a
session. QUIC is a session with IP address agility. DNS over HTTthing
is a session.

So there is no necessary end to simple UDP dns, but I suspect over
time, most "edge" DNS queries by volume and device, will move to
another protocol layer.

In email, we used to behave like SMTP was all there was (the ironies,
given how many sendmail configs drove DECnet or UUCP or ACSnet or
BITNET mail..)

We now recognise MTA, MUA, MDA and we live with SMTP/TLS IMAP and POP.
Oh, and gmail...

On Tue, Aug 21, 2018 at 4:08 AM, Paul Vixie <[email-masked]> wrote:
> ....
> there cannot be a way to do this, inside the ietf as it is. last time this
> was done it was by a "DNS Directorate" put together for that sole purpose,
> and it was extremely controversial -- won't scale.
>
> --
> P Vixie
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 21:18:48 -0700

> is less impactful (sorry, hate that word) than what embeds in Android

i don't think there's any decision support coming from those 
observations. the internet is still older and larger than the web, and i 
expect this condition to continue, but if i'm wrong, it will still never 
be small enough to ignore, or indeed, small in any way.

we should support android, and the web. that won't change what the rest 
of the internet needs to keep doing, for reasons of its own, for at 
least the lifetimes of the children of all members of this mailing list.

let me illustrate. a shell user on a virtual container somewhere, in 
2049 let's say, who needs to pull down an update in single user mode so 
she can get out of single user mode, will need to do a dns lookup. yes, 
we have proven that we can use persistent/stateful initiators in that 
use case, and that we can parse json. but can that become mandatory, 
because the web came, and was large, and didn't need datagram transport?

i say no. the internet predates the web and might outlive it.

-- 
P Vixie

---

From: George Michaelson <[email-masked]>
Date: Tue, 21 Aug 2018 14:25:31 +1000

I sort of agree. The addressing, a naming function and routing are the
three legs. If you do naming right, you can drop addressing and use
ephemeral addresses, and if you do routing right you can drop
addresses and do ad-hoc. But you need addresses and routing if you
want to do without names, so I kind of see this as a triumverate we're
grown into now (obviously there are other legs, like security, which
we always cut away in launch and then miss. three legged stools are
not stable...)

But that said, I see this other dimension. we don't run r* commands
any more. We don't run UUCP any more. Things which feel baked in turn
out to be ephemeral to the core function.

So name functions? Up where Brian Trammell is writing drafts? Sure. we
need that. What underlying protocol it maps to, Thats a big statement.
I don't buy that forever more amen it maps to UDP. If somebody makes
DOI work over ICMPv6, I could believe in 25 years we'd migrate to
bootstrap of DOI via ICMPv6 and be out of the DNS moment entirely.

As it stands, almost all bootstrapp-y application phases accept
address literals sorry [address:literals] somehow. Names are only a
convenience function, set against routing.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 21 Aug 2018 14:15:04 +0200

>     • Does TCP need to become the norm (particularly for the above use

TCP support is mandatory now, if that's what you mean (or wasn't clear).
https://tools.ietf.org/html/rfc7766#section-5

In particular, for forwarding it actually makes sense to me to prefer a
connected protocol, even if you don't really need any "state" between
the individual queries, but in any case it's each client's freedom to
choose.  (I'd go right for TLS in the forwarding case, if provided.)

--Vladimir