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

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 20 August 2018 17:22 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2D130E71 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=jbXXz42r; dkim=pass (1024-bit key) header.d=yitter.info header.b=VSD3jqLV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCCrg9voKVwk for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:22:45 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A02130E6D for <dnsop@ietf.org>; Mon, 20 Aug 2018 10:22:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6A721BD155 for <dnsop@ietf.org>; Mon, 20 Aug 2018 17:22:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1534785734; bh=0vRHvX0TIloxUbuFOoZcCJBWexnyxARSslA9Sv0HKaU=; h=Date:From:To:Subject:From; b=jbXXz42rKycOb18QPMu/+H95FIBVkdNserVu5adxFll9yoMYX7mIb487UQ02WGwtd rqYnAMBR5rHG2AXZjNIa/do0/rL+0Z/Xzntj8W6J/ISg6I63UrjgjjhtvW9ba3Zvqb 1QCp1me+C9/Fr3alQLPzpHcgQVin/kci/EbfNjLk=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_oEGZ98UQRO for <dnsop@ietf.org>; Mon, 20 Aug 2018 17:22:12 +0000 (UTC)
Date: Mon, 20 Aug 2018 13:22:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1534785732; bh=0vRHvX0TIloxUbuFOoZcCJBWexnyxARSslA9Sv0HKaU=; h=Date:From:To:Subject:From; b=VSD3jqLVFNHRuypfIpqOEQPCKu+Sh5bNH8k+WH/nXk0xrFn2yGRDyDYAOBVwSFS64 PDntiHVtzDh2AWb0tYDHc81nMXCJLDQ3wLqX3TT1Q+zViCMthMjvLV03IbCIWbTqwk lq4wuTp9VRG77HFEJJh8g9gID1PgK4GrGhyOmqHI=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180820172211.GE20505@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-x0kERas3eRykZTSvAI3ofFvNwc>
Subject: [DNSOP] Global DNS architecture changes, "the camel", and so on
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 17:22:48 -0000

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
ajs@anvilwalrusden.com