Re: Handling of External Host Objects (in the context of domain transfer)

[Asbjorn Steira <asteira@gnr.com>]

Hi Hong,


> The paragraph I quoted from epp domain mapping is the following:
> "DNS domains can be delegated to external hosts. If a domain has been
> delegated to an external host, a client MUST have created a host 
> object for each delegation to an external host before requesting a 
> domain transfer. A transfer request or approval MUST fail with EPP 
> error code 2305 if host objects representing the external hosts are 
> not managed by the requesting client at the time a transfer request is 
> made and at the time the transfer request is approved."
> So in my previous email, 2(a) is the result of the last sentence, 
> while 2(b) is the restatement of the second sentence. The main problem 
> is with 2(a).
> What is your read on the last sentence above?


It might not be 100% clear, but my understanding of the sentence is 
*not* that the external host object must be owned by the (potentially) 
gaining registrar, but that he must have an external host object with 
the same name server name in his name space.

> [SNIP] First and foremost, I would like you to explain why registrar A 
> can avoid massive update on all 1267 domains at the EPP protocol level 
>  (not at the registry DB level). Host objects are associated with 
> domains via the element, and the value of that element is the host 
> name. Are you saying that the 1267 domains using ns1.example.com as a 
> nameserver do not need to be changed to ns1.example.info in the 
> corresponding  field, while the host object ns1.example.com is renamed 
> to ns1.example.info? 


Yes, host objects are in a sense associated with domains names using the 
host name, but it links to the host object, not the host name directly. 
So by changing the name of a host from for example ns1.example.tld to 
ns2.example.tld, all the 1267 domain names will be automatically updated 
to use the new name name server, which to me makes perfect sense.

> Note that we are talking about explicit client-initiated operations, 
> not implicit registry server operations. Scott has said many times on 
> this list that implicit server operations are bad, and I agree. I 
> don't think that renaming an external host should implicitly trigger 
> the registry server to update all the domains using that host as 
> nameserver.


If one views hosts as separate objects, and domains as separate objects 
linking to host objects, a change of host name only changes the name of 
*one* object, it does not trigger a registry server to update domains. 
But the change will be reflected in all domains linking to the name 
server object we updated. So, to me this is not implicit registry server 
operations.

> Most importantly, renaming a host object (internal or external) while 
> it is linked with other domains is a _very bad_ idea since doing so 
> creates all sorts of inconsistency problems for domains that reference 
> the host object.
> Host objects are identified externally by hostnames in EPP. Changing a
> hostname is equivalent to creating another object, since the external 
> handle of the object has changed.
> I would not go as far to ban such operation in EPP, but the best 
> common practice should RECOMMEND NOT DOING SO.


I beg to differ :-). I think renaming a host object is very powerful for 
corporations/people handling numerous domain names. Being able to change 
host name only once instead of 1267 times makes life much simpler.


Asbjorn


PS  "Why 1267?"



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************