Re: [DNSOP] the root is not special, everybody please stop obsessing over it

Paul Vixie <paul@redbarn.org> Thu, 14 February 2019 23:23 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 C30D3131170 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 15:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ncAsSKJJ7QNI for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 15:23:19 -0800 (PST)
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 6F85D12F1A5 for <dnsop@ietf.org>; Thu, 14 Feb 2019 15:23:19 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:b448:8ed0:27c1:2c1b] (unknown [IPv6:2001:559:8000:c9:b448:8ed0:27c1:2c1b]) (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 57A56892C6; Thu, 14 Feb 2019 23:23:19 +0000 (UTC)
To: Mark Andrews <marka@isc.org>
Cc: IETF DNSOP WG <dnsop@ietf.org>
References: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org> <C976AB63-C8BD-4F11-8A1A-ADAE05D52CA3@isc.org>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <10b79e6a-caf5-3c0b-fe70-a1ad47656100@redbarn.org>
Date: Thu, 14 Feb 2019 15:23:18 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
In-Reply-To: <C976AB63-C8BD-4F11-8A1A-ADAE05D52CA3@isc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/he66k1-Kptpmd3kAgDxRZRHf7fw>
Subject: Re: [DNSOP] the root is not special, everybody please stop obsessing over it
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 14 Feb 2019 23:23:21 -0000


Mark Andrews wrote on 2019-02-14 14:13:
...
>> the fact that i have to hotwire my RDNS cache with local zone glue in order to reach my own servers when my comcast circuit is down or i can't currently reach the .SU authorities to learn where VIX.SU is, should not only concern, but also embarrass, all of us.
> 
> Having the local recursive server having a copy of the local zones was
> always part of DNS’s deployment model.  Having authoritative servers not be
> recursive servers is not the same as recursive servers not being
> authoritative for some zones.

i didn't expect you to need the broader example. the narrow example 
where i can't find my own zones is trivial. it's when i can't find other 
services whose dns is authoritatively served within my isp or my region, 
because even though i have connectivity within that isp or that region, 
there is a political or physical connectivity break between that isp or 
that region and the rest of the world, for example, the servers for 
TLD's and 2LD's and 3LD's whose delegators are outside my connectivity.

> One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In
> named we work around this by having a also-notify clause in the zone’s
> configuration clause.

that won't help. an authority server must have a protocol by which they 
can, at their own discretion, opportunistically invalidate prior 
answers, and which can be trusted by the RDNS servers hearing those 
invalidation messages.

> 
> DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing
> this result after.  With a little bit of EDNS negotiation both can be transmitted in
> a response.

that won't help the case which is more common than connectivity splits, 
which is where the old data has become harmful (key compromised, server 
or network offline, emergency renumber or rehoming or rekeying required).

let's stop thinking of this as a root problem or a TLD problem. the 
metadata an RDNS will need to reach and trust servers it can reach, may 
be on the wrong side of a network partition. that includes the entire 
NS/DS and DNSKEY/RRSIG chain, plus A/AAAA glue. we need partial zone 
authority, like a mini-slave, where the RDNS has _subscribed_ to the 
content it is keeping, and has a potential trust relationship with the 
owner of that data. we can argue about whether it's like mini-IXFR in 
which case it can answer authoritatively for the partial data it has 
leased. but we should not be talking about second TTL's, or root-only 
solutions like 7706.

vixie

-- 
P Vixie