[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
- [DNSOP] Global DNS architecture changes, "the cam… Andrew Sullivan
- Re: [DNSOP] Global DNS architecture changes, "the… Paul Vixie
- Re: [DNSOP] Global DNS architecture changes, "the… George Michaelson
- Re: [DNSOP] Global DNS architecture changes, "the… Paul Vixie
- Re: [DNSOP] Global DNS architecture changes, "the… George Michaelson
- Re: [DNSOP] Global DNS architecture changes, "the… Vladimír Čunát