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

Paul Wouters <paul@nohats.ca> Wed, 12 August 2020 00:56 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 8D44B3A0E15 for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 17:56:01 -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 Cuy6djaUlQQj for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 17:56:00 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 E585E3A0E0A for <dnsop@ietf.org>; Tue, 11 Aug 2020 17:55:59 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BRB8Y541SzFJm; Wed, 12 Aug 2020 02:55:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1597193757; bh=euZ4OCS94mkFhA2uTjlIfzYLWELbkUXjx8yFy6ysGkA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Og4oBOlE+z+3Zonc2srsgy3A8WnpNNhNfSiH+waEeHcNKxj1/u9U7XldBdWq1QOai 7yjut3HjWPYOQEqY3sJkYcAu/ok9M4MtlC3/Yc1xHudk0oSR3O9LzxamGezTd3WuX3 I7V6T6mhsh4mjqc9SY/yOK0fPBWoPv8gfScetllA=
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 vvX2lCe0bAfJ; Wed, 12 Aug 2020 02:55:56 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [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; Wed, 12 Aug 2020 02:55:56 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8AF6B6029BA5; Tue, 11 Aug 2020 20:55:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8275D66A7B; Tue, 11 Aug 2020 20:55:54 -0400 (EDT)
Date: Tue, 11 Aug 2020 20:55:54 -0400
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: Petr Špaček <petr.spacek@nic.cz>, dnsop@ietf.org
In-Reply-To: <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca>
Message-ID: <alpine.LRH.2.23.451.2008112048410.99493@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/mLUMMJyot-91Ocu9S9ts3jEgUOo>
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: Wed, 12 Aug 2020 00:56:02 -0000

On Thu, 30 Jul 2020, Joe Abley wrote:

>> I do not believe that is correct. The first and foremost purpose is for
>> the bit to signal the parent zone's behaviour in a public way that
>> prevents targeted / coerced attacks from the parent. This allows
>> policy violations to be rejected even if these violating DNS answers
>> are DNSSEC signed.
>
> 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.

So this statement aged badly with today's announcement from Afilias:

http://www.circleid.com/posts/20200811-afilias-to-protect-tlds-against-potential-orphan-glue-exploits/

 	Afilias has informed registrars and registry clients that it is
 	taking steps to remove orphan glue records from 200+ TLD zones
 	in its care. This will eliminate the potential for a handful of
 	domain names to be misused.

 	Afilias identified a handful of domain names among the 20 million names

> 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.

Well, 200+ TLD's are now removing this problematic orphan glue due to
security reasons unrelated to this draft.

So my question to Joe is, did you have any other concerns with allowing
this draft to move forward?

Paul