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 <gavin.br...@centralnic.com> het > volgende geschreven: > > 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 > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
