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

Paul Wouters <paul@nohats.ca> Tue, 03 November 2020 14:59 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 23EC63A0C6A for <dnsop@ietfa.amsl.com>; Tue, 3 Nov 2020 06:59:41 -0800 (PST)
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 HFv_zNfposyz for <dnsop@ietfa.amsl.com>; Tue, 3 Nov 2020 06:59:39 -0800 (PST)
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 ECB7D3A0C8B for <dnsop@ietf.org>; Tue, 3 Nov 2020 06:59:38 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CQXxh0fMSzFMG; Tue, 3 Nov 2020 15:59:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604415576; bh=VKA/VtH/bgoCwUT091qNg08nRm2JVgRjuZ2xrh8S6XE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XXlfyWA+ugM4LrLSWOx9Cvqkuy8wlCR1sNN+T/eA9DOnP0vTNZ8VkbetcEUYazIH7 kCnnYAUBI+D6DEr76V4lLSeaOZBMlS1ZXLYRsIB/lZ+hMU3BES+rgmaNZLT7VL2o8o MoP+cieitsDOFAQVXdSJcN9cjP8nFck5d4CtZqXw=
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 Q5gVFzLvW1fo; Tue, 3 Nov 2020 15:59:34 +0100 (CET)
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; Tue, 3 Nov 2020 15:59:34 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 349F36020F63; Tue, 3 Nov 2020 09:59:33 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3331423FDD4; Tue, 3 Nov 2020 09:59:33 -0500 (EST)
Date: Tue, 03 Nov 2020 09:59:33 -0500
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <alpine.LRH.2.23.451.2008112048410.99493@bofh.nohats.ca>
Message-ID: <alpine.LRH.2.23.451.2011030956000.2700646@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> <alpine.LRH.2.23.451.2008112048410.99493@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UVG4E8unQRHvVYYEhcMjZ6kGlc4>
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: Tue, 03 Nov 2020 14:59:41 -0000



Joe,

You never replied to this. I would really appreciate an answer so that
the Working Group knows whether or not your objection is still relevant,
based on the below developments of the Registry that is running the
TLD for which you were speaking.

As this seems to be the only outstanding technical issue with the draft,
it would be nice to get this answered. The remaining question then
becomes if the draft is worth it to enable the feature for those who
see value in it.

Regards,

Paul


On Tue, 11 Aug 2020, Paul Wouters wrote:

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