On 2021-03-01 16:15, Brian Dickson wrote:
On Mon, Mar 1, 2021 at 3:28 PM Doug Barton <[email protected]> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to