Re: EPP host renames

I don't see how a registry could allow the domain to be removed in your
test case. IIRC, the RFC explicitly says that you have to delete all
subordinate host objects before deleting the superordinate domain. And it
also says you can't remove a host while there are outstanding references to
it.

I suppose you could prohibit otherdomain.com from adding a reference to
ns1.example.com if the sponsoring registrars don't match. I don't think the
RFC really says anything about that either way, but it's seems a bit
restrictive.


On Wed, Dec 19, 2012 at 12:35 PM, InterNetX - Volker Janzen <
[email protected]> wrote:

> Hi Seth,
>
> funny thing, we discussed this issue in the last days. This is a test
> case I build for our QA suite (using generic domain names as example):
>
> - Create domain example.com.
> - Create host objects ns1.example.com and ns2.example.com and
>   add them to example.com.
> - Create domain otherdomain.com with nameservers ns1.example.com and
>   ns2.example.com.
> - Remove nameservers ns1.example.com and ns2.example.com from
>   domain example.com.
> - Delete domain example.com.
>
> Now there may be two answers from the EPP server:
>
> - 1001, action pending
> - 2305, Object association prohibits operation
>
> In case of 2305, we as a registrar need to take extra steps to delete
> example.com. The best option in my opinion is: rename the
> ns1.example.com and ns2.example.com to something that is out of the
> (.com) zone (and remove all GLUE IPs!).
>
> If the Google registry would allow the delete of the domain anyway (and
> return 1001), we would be fine with that. Otherwhise I'd recommend
> implementing host rename.
>
> One thing to keep in mind: if we manage otherdomain.com, we'd be able to
> remove the GLUE hosts from this domain name, which in pain on our side.
> If the otherdomain.com is not managed by us, we're not capable of doing
> so and we would not be able to delete the domain name.
>
> Hope this helps.
>
>
> Kind regards,
>         Volker Janzen (Senior Developer)
>
> On 12/19/2012 06:18 PM, Seth Goldman wrote:
> > Hi all,
> >
> > For those who are not aware, Google is becoming a registry with the
> launch
> > of the new gTLDs, and so we are currently building out our shared
> registry
> > service. I had a technical question that I hoped that the members of this
> > list could shed some light on.
> >
> > Do registrars generally use or depend on the being able to do host
> renames
> > via EPP? That is, something like this:
> >
> > ...
> > <host:update ...>
> >   <host:name>ns1.example.com</host:name>
> >   <host:chg>
> >     <host:name>ns2.example.com</host:name>
> >   </host:chg>
> > </host:update>
> > ...
> >
> > I can see how this could be useful to a registrar if they were renaming
> > their default nameserver, but it's a pain to implement if you're not
> using
> > a fully normalized RDBMS (which we're not). It also prevents us from
> using
> > the fully qualified host name as the primary key for host objects.
> >
> > Is it horrible to not support this particular scenario, and instead ask
> > registrars to do a delete-add of the new host, and then individually
> update
> > their referencing domains? From my reading of the
> > RFC<http://tools.ietf.org/html/rfc5732#page-15>,
> > registrars must be able to support this scenario anyway, since external
> > hosts could be referenced by domains sponsored by a different registrar:
> >
> > Host name changes can have an impact on associated objects that refer to
> >> the host object.  A host name change SHOULD NOT require additional
> updates
> >> of associated objects to preserve existing associations, *with one
> >> exception: changing an external host object that has associations with
> >> objects that are sponsored by a different client.  Attempts to update
> such
> >> hosts directly MUST fail with EPP error code 2305.  The change can be
> >> provisioned by creating a new external host with a new name and any
> needed
> >> new attributes, and subsequently updating the other objects sponsored by
> >> the client.*
> >
> >
> > Seth
> >
> >
> >
> > _______________________________________________
> > provreg mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/provreg
> >
>
>
>
> Volker Janzen
> Team Entwicklung
>
> --
> InterNetX GmbH
> Maximilianstr. 6
> 93047 Regensburg
> Germany
>
> Tel: +49 941 59559-0
> Fax: +49 941 59579-050
>
> www.internetx.com
> www.facebook.com/InterNetX
> www.twitter.com/InterNetX
>
> Geschäftsführer/CEO: Thomas Mörz
> Amtsgericht Regensburg, HRB 7142
>
> GPG-Key: 0x186C5F77
> GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77
>

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg