Re: [DNSOP] Making domains work even when connectivity fails (Was: the root is not special, everybody please stop obsessing over it

Paul Vixie <paul@redbarn.org> Fri, 15 February 2019 16:44 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 EAD38130FE2 for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 08:44:21 -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, 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 Or3KyS28Hcwy for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 08:44:20 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CBA130FD6 for <dnsop@ietf.org>; Fri, 15 Feb 2019 08:44:20 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:18eb:443:7c1e:38f2] (unknown [IPv6:2001:559:8000:c9:18eb:443:7c1e:38f2]) (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 E1F25892C6; Fri, 15 Feb 2019 16:44:19 +0000 (UTC)
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: Bob Harold <rharolde@umich.edu>, IETF DNSOP WG <dnsop@ietf.org>
References: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org> <20190215095936.qnxuucn6oezj7tsx@nic.fr> <CA+nkc8BcuaGC4TKUzY429Hh2=dZk2dA48=P2ecjwvhV466hT4Q@mail.gmail.com> <20190215143446.6vp57cmlsesswnlt@nic.fr>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <4efcd843-df84-e279-1df7-c240849edfd3@redbarn.org>
Date: Fri, 15 Feb 2019 08:44: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: <20190215143446.6vp57cmlsesswnlt@nic.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IaZrKEpg191kV9XGuLEiJONINiw>
Subject: Re: [DNSOP] Making domains work even when connectivity fails (Was: 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: Fri, 15 Feb 2019 16:44:22 -0000


Stephane Bortzmeyer wrote on 2019-02-15 06:34:
> On Fri, Feb 15, 2019 at 09:29:29AM -0500,
>   Bob Harold <rharolde@umich.edu> wrote
>   a message of 73 lines which said:
> 
>> I think in most solutions, if the name servers for "
>> malware-c-and-c-as-a-service.com" and "com" are both unreachable,
>> the domain should continue to resolve.  But if "com" is reachable,
>> and says " malware-c-and-c-as-a-service.com" no longer exists, it
>> should go away.

this is why serve-stale is most wrong. permission, and an agreement to 
hear a trusted NOTIFY later if the authority wants to do the work of 
keeping track of who it told things to, and the work of telling them 
when something has importantly changed (like a glue address change, a 
name server change, a key change, a signature invalidated, or malware 
removed). this is a subscription (leasing) problem, not a caching one.

> Any volunteer to write a problem statement for the "VIX.SU issue"?
> Short version: "when I'm on the same network that at least one
> authoritative name server of VIX.SU, I want this domain to work, even if there
> is zero Internet connectivity to the outside world" Longer version:
> "TODO (think of: is it automatic or not, does it require prior access
> or not, phantom domains, etc)"

just as root-level is the wrong focus, so is local-level. the reason we 
don't solve this problem with multicast NOTIFY is that the information 
you may need a subscription to (due to potential network partitioning) 
could be in another campus, or another region, or another isp, or 
another country.

-- 
P Vixie