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

Paul Vixie <paul@redbarn.org> Mon, 20 August 2018 18:08 UTC

Return-Path: <paul@redbarn.org>
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 C632F130E86 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 11:08:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DPl6woMiC543 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 11:08:35 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C09130E4A for <dnsop@ietf.org>; Mon, 20 Aug 2018 11:08:35 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 80924892C6; Mon, 20 Aug 2018 18:08:35 +0000 (UTC)
Message-ID: <5B7B03A2.7060307@redbarn.org>
Date: Mon, 20 Aug 2018 11:08:34 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>
CC: dnsop@ietf.org
References: <20180820172211.GE20505@mx4.yitter.info>
In-Reply-To: <20180820172211.GE20505@mx4.yitter.info>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tJPsAC7i7Q59IqC3LvXgosFFa8U>
Subject: Re: [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 18:08:37 -0000


Andrew Sullivan wrote:
...
>
> 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?

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.

>      • Do we need something like "submission port for DNS", so that
>      large concentrated systems can protect themselves and still
>      provide service to important resolvers?

no.

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

no.

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

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

>      • Do we have an appropriate venue to discuss these issues, on the
>      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