Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful

Paul Wouters <paul@nohats.ca> Sun, 07 March 2021 20:23 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 542533A1C39 for <dnsop@ietfa.amsl.com>; Sun, 7 Mar 2021 12:23:31 -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 R8lKUMA2VyLI for <dnsop@ietfa.amsl.com>; Sun, 7 Mar 2021 12:23:27 -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 3F4AC3A1C38 for <dnsop@ietf.org>; Sun, 7 Mar 2021 12:23:27 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DttG30MzHz3Td for <dnsop@ietf.org>; Sun, 7 Mar 2021 21:23:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1615148603; bh=Zi0VUXZAXGaParwikCMgf06olCw0X/R2hvUDS2D1Ny8=; h=Date:From:To:Subject:In-Reply-To:References; b=SKVyLskdTkFwnLRGyirHMWlxfccmr1xywtlLtfmxllw8VXSIedN2qW9+1BQn0tPAu vUv0+FoQrhXXXyrStAX16KUxYQ+AoTZwnH3JvW/84LcxMyDj2pInZaMWhy4s8jmaBz HlBbmU393y0c76eEPtK9cNK06L8O/YczAyBgMUd4=
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 9Spl9eEJbuFT for <dnsop@ietf.org>; Sun, 7 Mar 2021 21:23:21 +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 for <dnsop@ietf.org>; Sun, 7 Mar 2021 21:23:21 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC1E86029B62; Sun, 7 Mar 2021 15:23:19 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D366E66B1E for <dnsop@ietf.org>; Sun, 7 Mar 2021 15:23:19 -0500 (EST)
Date: Sun, 7 Mar 2021 15:23:19 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop@ietf.org
In-Reply-To: <A0E0A513-5FE6-4201-8028-6D2E303B97E6@dukhovni.org>
Message-ID: <9691651a-ee7e-7884-64f9-a2274a9d897f@nohats.ca>
References: <20201103221931.C535A2556CB7@ary.qy> <A0E0A513-5FE6-4201-8028-6D2E303B97E6@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BufL0kWQcTYZ8SSOy4xDWRgCEhY>
Subject: Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful
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: Sun, 07 Mar 2021 20:23:31 -0000

On Sun, 7 Mar 2021, Viktor Dukhovni wrote:

> For a somewhat more complete picture, below you'll find John Levine's data
> augmented with recent delegation counts for all the CZDS zones including
> the ones not listed him, where presumably the count of stray non-glue address
> records was zero.

> For example, for .biz, in addition to the two signed non-apex A records,
> there are also three internal bookkeeping records:
>
>  _nicname._tcp.biz. srv     0 0 43 whois.nic.biz.
>  whois.biz.         cname   whois.nic.biz.
>  www.whois.biz.     cname   whois.nic.biz.

The _prefix records are not a problem, as these are exempted by the
draft. Semantically, these records state something about the zone itself
and cannot be mistaken for a delegation.

The whois and nic records are common in TLDs. I thought it would be
better not to have hardcoded exceptions, and just have people do the
minor change of converting these into real delegations.

Note that the count presented has other issues too. For example,
the first pseudo random domain I picked to look further from the top
of the file:

info.txt.gz:ns1.breeat.info.	86400	in	rrsig	a	7	3	86400	20201123152255	20201102142255	27464	info.	cDhuFyGRJqi2uJnAuYMuHguwvHQx498oIQawSOXNBMxewSnudEeeElsgXXw3vuN1t+tOX2v9Y+WMdB5Wh3I1gkon3xxC6ZX2njDq5wcqDNFIm/pGpZkM2Bwv/7uzU9Hx8r+Lmn3lNgyhEKFc0f/H8ESveGw93jK/bkoQnjQf5qI=
info.txt.gz:ns1.breeat.info.	86400	in	rrsig	a	8	3	86400	20201123152255	20201102142255	44286	info.	Kx2nR9MxG2NDbO8pYGlwET5JFjvIJnYMswvptkU/oqj2a5bb4i1qU9cBQg6P5zZ7ekstxCJjV08HyUkh30b9Sn/sCJovVA+OEoOEef4r+yij2XQN93kvli19fqNDfNPEnO8fQqZ3ifcvFvs8S1EEJKlcPVSsnlSVnFPPRVlye/U=
info.txt.gz:ns2.breeat.info.	86400	in	rrsig	a	7	3	86400	20201123152255	20201102142255	27464	info.	mVxcu2heoUVOuahh9GODtZBMomdYZ1MsiJ41nYAgf0SCUy8oD9qJ/7yCFZg7WOyiGNUHEtuyBBAyj6DxKbSURDOhZ3Auarha298bo2z4n8Q4HIBMjFWE4imQ9K9ZayB8j2uG8i7V8l7asnbGKvM1b4C7fnB43pY7L9pt8xcAIZc=
info.txt.gz:ns2.breeat.info.	86400	in	rrsig	a	8	3	86400	20201123152255	20201102142255	44286	info.

These are 4 RRSIG for 2 name servers with an A record for which the
domain no longer exists.  Note that ns1 and ns2 point to the same single
IP address. I don't know how many other zones use these two nameservers,
but a quick check shows that there are no DNS server running on that IP
address anyway.

The TLD might as well just remove the glue. It is just garbage. It only
causes users longer timeouts into the inevitable failure of reaching those
nameservers. That is, actually not having these records is an _advantage_
over having them.

I don't have access to the original data used here, but it would be
interesting to know what percentage of this glue actually keeps a
domain running, and what percentage is just a futile attempt to keep
up a dying domain but only causing delay without gains.

I also cannot see if domains using these nameservers are still up at
all, running on other nameservers that are not running on promoted glue.
That would also be interesting to know. Perhaps someone with access to
the original data could run a script to determine that.

Regardless, as explains before. The problem is not hard to solve by
moving the signed glue into its own delegated special zone, which would
have the benefit of _clearly_ indicating to anyone who sees these NS
records that the domain is about to fall over. It is an improvement to
do this even if you don't do it to prepare for being a delegation_only
zone.

Based on this and the recent .org glue cleanup, I think there might even
be a good reason to write up a new draft about promoting-stale-glue-is-bad.

Paul