Scott,
This is how it was explained to me by the guy whom implemented this. External hosts are partitioned in views per Registrar. The external host (ns.example.com) may exist multiple times (different host:roid) in the SRS, but only once per Registrar. Imagine that RegistrarA created ns.example.com, and is the only instance in the SRS. RegistrarB will see the host ns.example.com as available, and will create a new instance (different host:roid from RegistrarA). If RegistrarB changes the name of the host, only the domains sponsored by RegistrarB will be updated in the DNS. Without an EPP extension there is no way for RegistrarB to know about the existence of the host instance of RegistrarA. The developer told me that no such EPP extension was implemented in the SRS, because it is not needed. Regards, Gustavo On 6/27/16, 12:13, "regext on behalf of Hollenbeck, Scott" <[email protected] on behalf of [email protected]> wrote: > The recent request for support to adopt this document: > > https://datatracker.ietf.org/doc/draft-lozano-rdap-nameservers-sharing-name/ > > got me looking at how "name servers sharing a name" could happen in the first > place. Section 3.2.1 of RFC 5732 doesn't say anything about name server name > MUST uniqueness when creating the host object, so let's assume it happens. > What gets returned in response to an <info> command that uses the name server > name as the lookup value when there are multiple objects that share the same > name? The <info> response doesn't support descriptions for multiple name > server objects, and I don't see anything in the extension registry that > describes an extension to do this. > > Scott > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
