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

Joe Abley <jabley@hopcount.ca> Tue, 03 November 2020 15:49 UTC

Return-Path: <jabley@hopcount.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 DA4C83A0D1E for <dnsop@ietfa.amsl.com>; Tue, 3 Nov 2020 07:49:49 -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=hopcount.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 VhucAaPm1ZWa for <dnsop@ietfa.amsl.com>; Tue, 3 Nov 2020 07:49:48 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE173A097A for <dnsop@ietf.org>; Tue, 3 Nov 2020 07:49:48 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id bl9so7934411qvb.10 for <dnsop@ietf.org>; Tue, 03 Nov 2020 07:49:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kz7hN+1ZsQe7yL3D9Tbk6CUDsXP4Fw3OBHUi7FoeZlA=; b=Ym9AvMb391ye9Od7FXT+Ww8YnCy6MJakmPlKu33c8IrSMHHffNGNYxQKSu198Ul0Vn 4fN0gYQnU3gMKe42WpqMIFe5Hes58j2kPjY7b3NNZlai1CfhLch3m/WvYdxtUSpzEl3u 3244L738RlHECt66E3ypImuBd1MKQpEoqZkVk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kz7hN+1ZsQe7yL3D9Tbk6CUDsXP4Fw3OBHUi7FoeZlA=; b=pfKWbKavbyM2K8Bqw7ieH+t62pflPlOpJGT7WV4H002j0OvDvZL2IPYVB25Jkzj6RU LDCItMffZPIsIYvVVXHQLAvmLH9Vc3pRtnGu0wnAaQw5R2dUSiAh+9MwuOwhlBMVfspk OY+lMJKmgozh6rgscAag8JrzV6tHVmn6omq8DUCbrKx+oAkpc//pc15vjD6W3Uq/v/KN JlAK1ClCH+GXb8Q8MA2N41h9IBaE7tUxcgzEO5B5Vl0sMk18OT2fZUHx39OJcZTC+fB6 QfnxE2U6J+mALZwwasDR00xzi5oRP6ZG0B4COzBXiJH5oKWoqYwgCL6lh0ZsfrSJr+nq R5UQ==
X-Gm-Message-State: AOAM530p5LXkA+/o9/lwLHX011yIHqwaigeTzJowmy0yRcEbGJZdR0az TII2K+ydCfiayF852qT7DLSHdpdexj1k3jppt5A=
X-Google-Smtp-Source: ABdhPJyXva6spEY+VZtaI75YkgtdGKMJhZn9KlUZ49ULMPLz4IwlzeZp53DSn9mHvZHrW2zJ6qXD/Q==
X-Received: by 2002:a05:6214:192d:: with SMTP id es13mr26114576qvb.27.1604418587226; Tue, 03 Nov 2020 07:49:47 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:1907:91d8:c544:f7e8? ([2607:f2c0:e784:c7:1907:91d8:c544:f7e8]) by smtp.gmail.com with ESMTPSA id p13sm10509096qkj.58.2020.11.03.07.49.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 07:49:46 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <alpine.LRH.2.23.451.2011030956000.2700646@bofh.nohats.ca>
Date: Tue, 03 Nov 2020 10:49:45 -0500
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A141A5B-FD68-4991-BD90-DFE7EFAED49D@hopcount.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> <alpine.LRH.2.23.451.2011030956000.2700646@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XrjGoTGx3fz5euM7VMQ67kDvFX4>
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 15:49:50 -0000

Hi Paul,

On 3 Nov 2020, at 09:59, Paul Wouters <paul@nohats.ca> wrote:

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

Sorry about that, wasn't intentional. See below.

> On Tue, 11 Aug 2020, Paul Wouters wrote:
> 
>> 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

I am familiar with the contents of that blog post and the circumstances surrounding it. My position on the usefulness of this draft has not changed. See below for more detail.

PIR and Afilias identified a software defect that in certain cases allowed glue records to remain in the zone even though they had been removed from the registry. Since the ORG zone is relatively large and since the defect had existed for a long time, the number of lingering orphan glue records was significant, even though the circumstances by which they showed up were relatively rare.

The software defect was eliminated and the glue records associated with the defect were removed.

However, even a cursory look at the ORG zone today, long after these records were removed, reveals that there are many orphan glue records (in the DNS sense, not in the registry sense) that remain. An example of the circumstances that lead to these remaining glue records being present in the zone is the case where a domain is suspended for abuse according to our published procedures; in those circumstances the delegation is removed from the zone but any subordinate glue records that might exist will remain.

On 2020-09-22 there were 7207 such orphan glue records in the ORG zone.

On 2020-11-03 (today, zone serial 2014131123) there are 8155 such orphan glue records in the ORG zone.

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

I have not done a survey of other TLD zones, but perhaps if I have a few spare minutes I'll take CZDS for a spin and see what I can see there.

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

ORG is not a delegation-only zone today, and we do not expect it ever to be a delegation-only zone. Correspondingly, this is not a mechanism we would use in ORG.


Joe