RFC 5731 contains text that has led some domain name registrars to adopt an operational practice of re-naming name server host objects so that they can delete domain objects. The text in question can be found in Section 3.2.2, "EPP <delete> Command":
"A domain object SHOULD NOT be deleted if subordinate host objects are associated with the domain object. For example, if domain "example.com" exists and host object "ns1.example.com" also exists, then domain "example.com" SHOULD NOT be deleted until host "ns1.example.com" has either been deleted or renamed to exist in a different superordinate domain." A host object might need to be renamed if, for example, it is associated with a domain object (such as example2.com) that's managed by another registrar. The registrar that wants to delete example.com is advised not to do so because of the association with ns1.example.com, but they can't remove the association because the example2.com domain object is managed by a different registrar. If this second registrar doesn't, or can't, change the delegation of example2.com, the first registrar must rename the host object to disassociate ns1.example.com from example.com. There's a risk in renaming the host object, though. If the host is renamed using a domain that isn't currently registered, such as ns1.randomfoo.example, it becomes possible for someone to gain DNS resolution control of ns1.randomfoo.example by registering randomfoo.example and creating ns1.randomfoo.example. The topic is described in this paper from 2021: https://www.caida.org/catalog/papers/2021_risky_bizness/risky_bizness.pdf The paper incorrectly says that "the constraints dictated by EPP do not allow the domain to be removed" (the text in 5731 is SHOULD NOT, not MUST NOT), but the risk associated with the practice exists. 5731 does not describe the rationale for the SHOULD NOT, the risk associated with renaming, or how to mitigate that risk. It's my personal belief that the SHOULD NOT is still valid guidance and that there's no need to change anything in 5731, but we do have an opportunity to do what 5731 does not by writing a BCP-candidate I-D that addresses the topic. That assumes, of course, that we can identify best practices. So, questions for the working group: Is this a topic we should address? If we want to address it, how? New I-D as I suggested above? 5731 erratum? Re-open 5731 and add text (this one is definitely NOT my preference)? Something else? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
