Scott,
I see value with addressing this. I would broaden the scope to also include RFC 5732 language: A host name object SHOULD NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object. And the following, which can make it very difficult to undue a prior host name change: A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/10/23, 12:58 PM, "regext on behalf of Hollenbeck, Scott" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: 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://secure-web.cisco.com/1PwAHxpuVEI81sMrjS9l1Va7pUnoEBDLPZMy2YLQkGEMpKSg92ZyHPJGHUc0cKH07gqIxnVBYxpV0L5-ueqdw01YG5TGYar5dnxvgndGPq2Uz0HVlb2GA-rBU5oO_BuLp86B0vad7RYcs0hcaXLAlR0nELPjMyc7Rh7vL39LjeLIBtX1I0q92OoYHtZtpCxo9aK9AgIAinWAGU4o2eIfXUgyiRR8WMavMNk4O8PpM8Kb3sgPwGC681MdR8rdwjRlDMb6elitgM7_XDWxVwzkEJB9sMXZsYmILszND4n5LHcY/https%3A%2F%2Fwww.caida.org%2Fcatalog%2Fpapers%2F2021_risky_bizness%2Frisky_bizness.pdf <https://secure-web.cisco.com/1PwAHxpuVEI81sMrjS9l1Va7pUnoEBDLPZMy2YLQkGEMpKSg92ZyHPJGHUc0cKH07gqIxnVBYxpV0L5-ueqdw01YG5TGYar5dnxvgndGPq2Uz0HVlb2GA-rBU5oO_BuLp86B0vad7RYcs0hcaXLAlR0nELPjMyc7Rh7vL39LjeLIBtX1I0q92OoYHtZtpCxo9aK9AgIAinWAGU4o2eIfXUgyiRR8WMavMNk4O8PpM8Kb3sgPwGC681MdR8rdwjRlDMb6elitgM7_XDWxVwzkEJB9sMXZsYmILszND4n5LHcY/https%3A%2F%2Fwww.caida.org%2Fcatalog%2Fpapers%2F2021_risky_bizness%2Frisky_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 [email protected] <mailto:[email protected]> https://secure-web.cisco.com/14DdAsIt0yawH2AE7ADZuJJ3NjMyXWTOtItbst9n1JAomvH06kRKmdc8_VxDnDqBkr7ZwWnPuAwo_JxxTTh8MRwCKy61-ulgmAlwNk8wedmztZa64RIiKq_umT0bGpd7cdm8LlrTFYYumrk2rkrHQam3A0dQFOQvHJjOc1zhh79rn0oT8s9hNNhW8Sfc37Y1Aa-jc_Xqnj4s3xvcXXf38LENcMDomHGxyWjzD8mYc6GX0r7yIkygq657_YTXxXUroC3JfYtzzfkhrHAB_jIArENlI8n46B_DIi3QjHqaP0t0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/14DdAsIt0yawH2AE7ADZuJJ3NjMyXWTOtItbst9n1JAomvH06kRKmdc8_VxDnDqBkr7ZwWnPuAwo_JxxTTh8MRwCKy61-ulgmAlwNk8wedmztZa64RIiKq_umT0bGpd7cdm8LlrTFYYumrk2rkrHQam3A0dQFOQvHJjOc1zhh79rn0oT8s9hNNhW8Sfc37Y1Aa-jc_Xqnj4s3xvcXXf38LENcMDomHGxyWjzD8mYc6GX0r7yIkygq657_YTXxXUroC3JfYtzzfkhrHAB_jIArENlI8n46B_DIi3QjHqaP0t0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
