<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 3:28 PM Doug Barton <dougb@dougbarton.email> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm being told something by my registrar which I find impossible to <br>
believe, but they keep telling me that they have accurately transmitted <br>
my request, and that the answer is no. "Let me 'splain. No, there is too <br>
much. Let me sum up."<br><br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So what am I missing here? I know that in the past it was possible, and <br>
in fact desirable, to remove those obsolete glue records, but now it's <br>
impossible to do it?<br></blockquote><div><br></div><div>Not speaking with knowledge of the specifics, only concerning the general case:</div><div>The RRR (registry/registrar/registrant) system is somewhat complex, and arcane.</div><div>The common language used, EPP, is capable of representing relationships, but is restrictive.</div><div><br></div><div>The root problem is the object model (tied to the database nature of registries).</div><div>A glue record is basically a host record, with a name and IP address(es).</div><div>Domains (registered with the registry, belonging to registrants) have their delegations represented as references to host records.</div><div><br></div><div>This is where things break down: the delegation is to the object, not the name.</div><div><br></div><div>If you change your delegations to a different name, that will either change the reference to a different object, or possibly create a new object and use that for its delegation reference.</div><div><br></div><div>The old object (with the original name) still exists.</div><div><br></div><div>If (and ONLY if) there are no other references (i.e. delegations) to that object, can the object be deleted.</div><div><br></div><div>That rule is enforced, and is tied to the database model for hosts and domains.</div><div><br></div><div>You do generally have the option of renaming the object, and there are some interesting options available.</div><div><br></div><div>One is to change the name to an off-TLD name, in which case the corresponding IP address(es) are removed.</div><div><br></div><div>Using an off-TLD name that is deliberately and permanently unresolvable is a nice, clean way of "breaking" the other domains, who should really not have been using your name server as their name server without your permission.</div><div><br></div><div>An example name would be "SOME_RANDOM_VALUE".empty.as112.arpa (empty.as112.arpa is a zone intended to never have any non-apex records, as the name suggests, and its existence is defined for that purpose in RFC 7535).</div><div><br></div><div>For "SOME_RANDOM_VALUE", it is recommended that you use a GUID type generated value for the label, to ensure it does not collide with anyone else doing the same thing. (There are others doing this already.)</div><div><br></div><div>Hope this helps explain the situation.</div><div><br></div><div>(It's not your fault, and it isn't the registry's fault, it is whoever has for whatever reason delegated some other domain to your name server that has caused the problem.)</div><div><br></div><div>Brian</div></div></div>