Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Paul Wouters <paul@nohats.ca> Thu, 30 July 2020 19:43 UTC

Return-Path: <paul@nohats.ca>
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 418FA3A0BD4 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 12:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 nGm5qKGlraft for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 12:43:17 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CED3A0BF0 for <dnsop@ietf.org>; Thu, 30 Jul 2020 12:43:16 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BHgnD1Sxjz7pR; Thu, 30 Jul 2020 21:43:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1596138192; bh=+4IcNoCmUJF6sfaXWXB6k1Rm2iCSW0uSBADnL0APSAk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AuFLUPuEtb37QkI/CVe9RjWlE4jmFxpKLFFDKinib49wHGoGD5EVLF+w/RTIB2hLl tG1jx03bmmRZ+rZcWwqavOtGbiNX9R7ZxqGO5NrC01QqFZN9ZopjSekN6XR3a0PJXo dpKuVeFAtUaMxw8djiDjg+iwTHYHddRmzZhiNKPM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KDNT860NqtwG; Thu, 30 Jul 2020 21:43:10 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Jul 2020 21:43:10 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 09D2B6029BA4; Thu, 30 Jul 2020 15:43:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0165182C94; Thu, 30 Jul 2020 15:43:08 -0400 (EDT)
Date: Thu, 30 Jul 2020 15:43:08 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca>
Message-ID: <alpine.LRH.2.23.451.2007301446380.418549@bofh.nohats.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gyl2X4bY1peEjsn2KL5JC91o_dY>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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, 30 Jul 2020 19:43:21 -0000

On Thu, 30 Jul 2020, Joe Abley wrote:

> Has anybody done a survey to find out how many TLD zones actually fits the description of "delegation-only"?
>
> I know for a fact that ORG does not today and I would say is unlikely ever to. For example, any nameserver N that is subordinate to domain D and linked to some other domain E will be served authoritatively from the ORG zone if domain D is suspended and while E continues to be delegared. Suspensions happen regularly, e.g. for domains implicated in technical abuse. There are several thousand examples of such N today and history suggests the number is not becoming smaller. Even if the number of such N could reach zero in ORG, we could never assume the number would remain at zero and still would not be able to assert usefully that the zone is delegation-only.
>
> I don't think ORG is particularly special in this regard; it seems possible that other (possibly many other; possibly most or all) TLD zones are similar. If there are no TLD zones that actually are delegation-only then there seems no obvious application for it, regardless of whether we consider it to be useful or not.

You are mixing up the generic policy of delegation only with the exact
semantics of the bit. The .org is definately what I would call a
delegation-only domain. Now let's examine the corner case you have
and see if/what we can do.

Rephrasing what you are saying is that "sometimes we need to take over
our children and we currently do this in such a away that we would no
longer appear to be delegation only".

So you are saying that if ns1.example.org serves another-example.org
and example.org is suspended for abuse, that you will still service
A records for ns1.example.org and NS records for another-example.org
containing ns1.example.org but no NS records for example.org? In
the hopes that another-example.org keeps working?

Wouldn't that already fail with DNS servers like unbound with:

 	harden-glue: yes
 	harden-dnssec-stripped: yes
 	harden-below-nxdomain: yes
 	harden-referral-path: yes

which is the default in Fedora / RHEL / CentOS and maybe others?

Paul