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
> real problem?
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 protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
