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

[Paul Wouters <[e-mail]>]

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