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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
