[dns-operations] Verisign won't delete obsolete glue records?

[Doug Barton]

On 2021-03-01 16:15, Brian Dickson wrote:
> On Mon, Mar 1, 2021 at 3:28 PM Doug Barton <dougb at dougbarton.email> 
> wrote:
> 
>> I'm being told something by my registrar which I find impossible to
>> believe, but they keep telling me that they have accurately 
>> transmitted
>> my request, and that the answer is no. "Let me 'splain. No, there is 
>> too
>> much. Let me sum up."
>> 
>> 
> 
>> So what am I missing here? I know that in the past it was possible, 
>> and
>> in fact desirable, to remove those obsolete glue records, but now it's
>> impossible to do it?
>> 
> 
> Not speaking with knowledge of the specifics, only concerning the 
> general
> case:
> The RRR (registry/registrar/registrant) system is somewhat complex, and
> arcane.
> The common language used, EPP, is capable of representing 
> relationships,
> but is restrictive.
> 
> The root problem is the object model (tied to the database nature of
> registries).
> A glue record is basically a host record, with a name and IP 
> address(es).
> Domains (registered with the registry, belonging to registrants) have 
> their
> delegations represented as references to host records.
> 
> This is where things break down: the delegation is to the object, not 
> the
> name.
> 
> 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.
> 
> The old object (with the original name) still exists.
> 
> If (and ONLY if) there are no other references (i.e. delegations) to 
> that
> object, can the object be deleted.
> 
> That rule is enforced, and is tied to the database model for hosts and
> domains.
> 
> You do generally have the option of renaming the object, and there are 
> some
> interesting options available.
> 
> One is to change the name to an off-TLD name, in which case the
> corresponding IP address(es) are removed.
> 
> 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.
> 
> 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).
> 
> 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.)
> 
> Hope this helps explain the situation.
> 
> (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.)
> 
> Brian

Thanks for the explanation about objects vs. host names. In this case 
it's not a third party that is using the old names, it's still us, so we 
don't want to "break" those delegations.

Perhaps I didn't ask my question clearly enough. Let's take a delegation 
for example.com to ns1.example.info and ns2.example.info. There will be 
no host records at Verisign for those two names, right? So how are those 
delegation host names represented in the database, and why can't my 
now-obsolete glue records be represented the same way?

Doug