Hi Mark, On 30 Apr 2020, at 19:52, Mark Andrews <ma...@isc.org> wrote:
> On 1 May 2020, at 08:39, Wes Hardaker <wjh...@hardakers.net> wrote: > >> Yep, I suspect some of the bigger TLDs probably couldn't opt in to this >> draft simply because they're full of, um, "history". Until that history >> is cleaned, they probably couldn't deploy it. > > I doubt there is any real history here other than “we didn’t properly clean > up the records when the delegation was removed”. If a DNS provider goes belly > up then all the zones dependent on that provider should FAIL. Its just poor > zone hygiene that leaves orphaned glue in the ORG zone. I don't want to speculate on the actual reasons that orphan glue exists in the ORG zone before actually taking the time to investigate, but I'll note that the EPP data model provides some constraints around host objects and domain objects (e.g. domain objects can't be deleted when there subordinate host objects that exist) and there are reasons for delegations to be removed from the TLD zone while the corresponding domain object in the registry still exists (e.g. as part of domains that are suspended through the normal processes by registrars when they are found to be abusive). I also don't understand the theory that any of these glue records exist because a DNS provider ceases operations. DNS providers don't feature in the RRR model. A failure in a set of nameservers could cause delegations to become lame, but there is no process that I'm aware of where orphan glue is a direct or necessary consequence. Anyway, I am fairly confident in saying that there are legitimate, normal operational processes that can result in orphan glue, and that it's not correct to infer that they all exist for reasons of poor hygiene. This is a topic of interest in a number of places right now. It is definitely on the list of things to investigate. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
