On 7 Mar 2021, at 15:23, Paul Wouters <p...@nohats.ca> wrote: > 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.
Just a point of clarification -- the domain does exist; it's just suppressed from publication in the DNS. jabley@manta ~ % whois -h whois.afilias.net breeat.info | fgrep Status Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: serverHold https://icann.org/epp#serverHold Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod jabley@manta ~ % When it comes to TLD zones, it's necessary to consider the registry data as well as the DNS if you want to be sure you are seeing the whole picture. > 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. gTLD operators can't just remove things that in its opinion are not working or not necessary. The things they can and can't do are constrained by contract. I appreciate that there are many registries that are not run by contracted parties, of course. In general, it's difficult to know for sure what the impact of removing a linked glue record is. A nameserver that doesn't respond today might be fixed tomorrow, or might never be fixed for particular clients due to some other local policy. There may well be extraneous orphan glue records (in the DNS sense) in the ORG zone that could safely be removed, but it's difficult to know for sure unless you have certain knowledge about the names concerned and the intensions of the organisations involved in them. There are definitely orphan glue records (same sense) whose removal would cause operational problems for other domains. [...] > 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. You should feel very free to write up whatever you want :-) but as I have mentioned a few times, so long as there are reasons to suppress publication of zone cuts for particular domains, e.g. for reasons of abuse management, and so long as it's possible to link subordinate host objects to other domain objects that *are* published, and so long as the data model specified in EPP remains as it is, the number of promoted glue records in zones like ORG are not going to reach zero and suppressing orphan glue (orphan in the DNS sense, not the registry sense) definitely has the potential to break things. I don't think you make something a problem by calling it one. These things are only problems because you have a use-case for zones like these being delegation only, and the reality of how these zones are constructed doesn't fit nicely with that. I also don't think you can solve a problem by declaring the solution to be simple on the grounds that you've ignored all the things that would otherwise make the solution complicated :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
