Subject: [regext] Confusion around non-uniqueness of nameserver objects

From: Gavin Brown <[email-masked]>
Date: Mon, 20 Dec 2021 17:09:36 +0000

Hi all,

I was recently contacted by an otherwise clueful person who was confused because an RDAP query for a particular nameserver object seemingly showed the wrong sponsoring registrar.

Upon investigation, it was revealed that the nameserver in question was subordinate to domain in another TLD. The user was expecting the RDAP record to show the registrar of the sponsoring registrar of the parent domain, rather than the registrar who happened to create it, because two different TLDs can use two unrelated registry systems, and there is no synchronisation between them, therefore nameserver objects are not globally unique in the way that domain names are.

It occurred to me that it may be possible to mitigate this confusion: in response to nameserver queries, an RDAP server can include a "related" link to the "authoritative" RDAP server (constructed using the bootstrap registry).

My question to this group is how useful this would be? Does it solve a real problem?

Thanks,

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.

https://www.centralnic.com

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 21 Dec 2021 16:16:13 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gavin Brown
> Sent: Monday, December 20, 2021 12:10 PM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] Confusion around non-uniqueness of
> nameserver objects
>
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Hi all,
>
> I was recently contacted by an otherwise clueful person who was confused
> because an RDAP query for a particular nameserver object seemingly
> showed the wrong sponsoring registrar.
>
> Upon investigation, it was revealed that the nameserver in question was
> subordinate to domain in another TLD. The user was expecting the RDAP
> record to show the registrar of the sponsoring registrar of the parent
> domain, rather than the registrar who happened to create it, because two
> different TLDs can use two unrelated registry systems, and there is no
> synchronisation between them, therefore nameserver objects are not
> globally unique in the way that domain names are.
>
> It occurred to me that it may be possible to mitigate this confusion: in
> response to nameserver queries, an RDAP server can include a "related" link
> to the "authoritative" RDAP server (constructed using the bootstrap
> registry).
>

[SAH] Sounds useful to me. What did the otherwise clueful person think?

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 21 Dec 2021 17:34:43 +0100

Inviato da iPhone

> Il giorno 21 dic 2021, alle ore 17:16, Hollenbeck, Scott <shollenbeck=[email-masked]> ha scritto:
> 
> 
>> 
+1
Mario
> Scott
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 21 Dec 2021 11:42:47 -0500

On Mon, Dec 20, 2021, at 12:09, Gavin Brown wrote:
> It occurred to me that it may be possible to mitigate this confusion: 
> in response to nameserver queries, an RDAP server can include a 
> "related" link to the "authoritative" RDAP server (constructed using 
> the bootstrap registry).

This seems to me similar to an authoritative nameserver suddenly 
becoming recursive, because to reply it has to construct an answer out of data
that is not just locally but comes from external sources.

It may help the client or not (the use clear is not clear to me, it boils down
to user confusion over a specific pattern on how nameservers are handled in domain
name registries, so not sure it warrants a server change), but it is more work for the server,
and the client ought to be able to do all of that just by itself.

Also exactly like for DNS, the RDAP server is then serving data that he is
not really authoritative on, so why would the client trust it on that?

Plus, technically it wouldn't be easy. Extracting the "domain" part out
of the nameserver name would need basically the Public Suffix List, with all
its caveat.

> My question to this group is how useful this would be? Does it solve a 

I am not seeing the problem this solves, in the sense that if there is a problem,
the client has already everything it needs to solve it by itself.

Plus, what is a usefulness for the client to know the sponsoring registrar
of a nameserver? To know who to contact to amend something like glues or
its use in some domain names?

If a request to RDAP server authoritative on TLD X comes back with information
with a domain using a nameserver whose name is in a domain under TLD Y,
aka an external nameserver, I see really no usefulness that it is indeed
under sponsorship of registrar A sponsoring that domain in registry of TLD Y,
instead of being under sponsorship of registrar B having created this external
host object at registry of TLD X.

Besides, I doubt all servers to suddenly do this extra work, so clients
will anyway need to handle that on their end in some cases, so they should
just be prepared to do it for all cases, and hence no extra new work needed
for any servers.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Gavin Brown <[email-masked]>
Date: Wed, 22 Dec 2021 10:57:02 +0000

On 21 Dec 2021, at 16:16, Hollenbeck, Scott <[email-masked]> wrote:
>> [snip]

He agreed that the above solution would be effective.

G.

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 23 Dec 2021 22:36:09 +0100

How funny that history repeats itself. This exact issue is how I got involved in EPP now 20 years ago:
https://mailarchive.ietf.org/arch/msg/provreg/P19uXw4zn8GGxH0jc8XS2qNpYO4/ <https://mailarchive.ietf.org/arch/msg/provreg/P19uXw4zn8GGxH0jc8XS2qNpYO4/> 
I had the exact same issue because someone hijacked my name server registration with Network Solutions back then.

The problem is not in the RDAP protocol. The problem is in local policy.
Glue policy to be precise.
When you have a narrow glue policy, there is no need to register a glue record for out of bailiwick name servers in your local TLD registry.
There should not be a name server record with an ownership in you registry database for a name server that is out of zone for your TLD. In whois, you could simply return the result of a DNS query as courtesy to fill the IP address in the output, but this would certainly not be authoritative data.

When EPP and RDAP was developed, I was told that a name server record doesn’t need to be unique in the database to solve this issue for existing databases that served a wide glue policy. And people should be so smart as to avoid out of bailiwick glue. (I disagree from a redundancy point of view). If your name server is already registered by someone else, simply add another record for the same name server in the registry database for the out of bailiwick name server. It’s glue is not authoritative and used anyway. Only in the registry for which the name server is in zone, it should be unique because it produces a glue record in the DNS, and the the ownership of the name server record should match the registered domain in that registry. But this is local policy for the registry to determine how to calculate what glue should be in the zone. The gTLD’s simply used a first come first served policy for both domains and name server registrations in the background. Because it was too much work for the gTLD system in use back then (don’t know if it still is the same) to clean up the invalid nameserver registrations since it served multiple TLD’s at the same time and it was hard to separate them, this issue was never resolved. The only thing that changed is that gTLD’s no longer published glue records for ccTLD suffix name servers in their zone files when calculating from the database what should be in the com/net/org zone.

So conclusive: The RDAP protocol is not going to solve this corner case. It was decided that this is local policy about database structure and record validation, and is not included in the protocol specification on how to interact with the database.
I still have the opinion any TLD registry should have a narrow glue policy and not register ownership or IP addresses for out of zone name servers in their database. (The EPP protocol only specifies how to interact with the database, not how the database is structured or validated. Registration of ownership of a name server record that is out of zone for your TLD can simply be ignored or refused by local policy) 

But certainly interesting to see this discussion return.

- -- 
Antoin Verschuren - No Hat

> Op 20 dec. 2021, om 18:09 heeft Gavin Brown <[email-masked]> het volgende geschreven:
> 
> Hi all,
>