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

["Liu, Hong" <Hong.Liu@neustar.biz>]

Hi, Asbjorn,

Thanks for discussing this topic. This is my response to your posting [1].
For some reason, I did not get the posting directly from the mailer. I just
found that out by looking throught the mail archive. The following
presenation is somewhat awkward since I have to quote your email.

Quote:
"I don't understand the first part here, why would the losing registrar need
to delete the link to the external host before transfer? He would only need
to go to the new registrar and create the external host there (if it is not
already there), request the transfer, and the domain would automagically
swap to "using" the newly created external host when the transfer is
completed. The domain will resolve during the whole process."
Answer:
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?
Quote:
"The problem with this is that when registrar A in the (for example) dotInfo
registry later wants to rename his host ns1.example.com to for example
ns1.example.info (i.e., moving it into the zone), he would have to first
create the new host, and then update all the 1267 domains using
ns1.example.com to use the new host. This is not a problem in the current
solution. "
Answer:
Yes, this can be inconvenient, but with good reasons. If this is the only
problem, then I believe the benefits of the single copy solution far
outweights the multi-copy one.
 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 <ns>
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 <ns> field, while the host
object ns1.example.com is renamed to ns1.example.info? 
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.
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.
--Hong

[1] http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00102.html