Subject: Re: Handling of External Host Objects (in the context of domain t ransfer)

From: "Liu, Hong" <[email-masked]>
Date: Tue, 29 Oct 2002 20:09:12 -0500

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

---

From: Asbjorn Steira <[email-masked]>
Date: Wed, 30 Oct 2002 12:24:34 +0000

Hi Hong,

> 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).

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.
> 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
*****************