Subject: [provreg] EPP host renames

From: Seth Goldman <[email-masked]>
Date: Wed, 19 Dec 2012 12:18:14 -0500

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

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 09:30:08 -0800

Hi Seth,

Even if this is not used as often as it should, you're going to find yourself in a situation where you will need to support it in order to be RFC compliant. If you decide not to implement it, you risk getting yourself in an extended evaluation, which you may not want.

Francisco

On Dec 19, 2012, at 9:18 AM, Seth Goldman <[email-masked]> 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 ...>
> 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, 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-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 19 Dec 2012 17:38:51 +0000

> 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?

It's horrible from a protocol conformance perspective. I don't know if registrars depend on the feature or not, but I do know that not supporting mandatory parts of the protocol will make it difficult for them to work with your implementation.

Scott

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Wed, 19 Dec 2012 18:44:29 +0100

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)

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

---

From: "Gould, James" <[email-masked]>
Date: Wed, 19 Dec 2012 18:18:45 +0000

Seth,

If you're going to support host objects versus host attributes, I believe you should support the ability to rename a host.  With host objects you would need to use a surrogate key instead of a natural key.  You could opt for using the host attribute approach defined in RFC 5731 if you don't want to treat hosts as true objects.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 19, 2012 12:18 PM
To: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: [provreg] EPP host renames

Hi all,

...
<host:update ...>
  <host:name>ns1.example.com<http://ns1.example.com></host:name>
  <host:chg>
    <host:name>ns2.example.com<http://ns2.example.com></host:name>
  </host:chg>
</host:update>
...

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:

Seth

---

From: Seth Goldman <[email-masked]>
Date: Wed, 19 Dec 2012 13:31:33 -0500

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-masked]> wrote:

> On 12/19/2012 06:18 PM, Seth Goldman wrote:
> > Hi all,
> >
> Volker Janzen
> Team Entwicklung

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 13:32:59 -0500

Hi,

When we implemented Info and subsequent TLDs we used host objects but did not support the rename. We expected registrars to do create a new host object and update individual domains. We had many admonishments for this from registrars and did implement it for internal hosts later on.

Note more specifically, host objects were subordinate to the parent domain object  which was key to our approach for disallowing orphaned glue records. I'm not a big fan of the attribute approach.

Also, given the need to identify unique lifespans for the same domain string and hostnames ( a domain can have multiple lives) I would always use a permanently unique identifier as a primary key versus a fqdn or hostname.

Hope that helps!

Michael Young

M:647-289-1220

On 2012-12-19, at 13:18, "Gould, James" <[email-masked]> wrote:

> <82F8FEBC-E856-4D62-9857-D12B446CEFE8[53].png>
>  
> James Gould
> From: Seth Goldman <[email-masked]>
> To: EPP Provreg <[email-masked]>

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 10:33:42 -0800

In other set of events.

How to handle when the domain is deleted during the renewGracePeriod and has subordinate hosts?

On Dec 19, 2012, at 10:31 AM, Seth Goldman <[email-masked]> wrote:

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

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 10:39:49 -0800

I bring this question, because in this case I guess we'll have to prevent the domain from being deleted in the first case, which will trigger the autoRenewGracePeriod to end.

If the registrar wants to really get rid of the domain, will have to update the hosts (rename or delete), and then issue the delete command.

Francisco Obispo

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 13:41:15 -0500

Exactly

Michael Young

M:647-289-1220

---

From: Seth Goldman <[email-masked]>
Date: Wed, 19 Dec 2012 13:41:54 -0500

I see. You're saying that the host object rename lets you work around the
scenario where another registrar has a reference to one of your subordinate
host objects. Otherwise, you're stuck in a scenario where you can't delete
the domain until that other registrar removes its reference. Fair point,
there's clearly no workaround for that.

On Wed, Dec 19, 2012 at 1:39 PM, Francisco Obispo <[email-masked]> wrote:

> I bring this question, because in this case I guess we'll have to prevent
> the domain from being deleted in the first case, which will trigger the
> autoRenewGracePeriod to end.
>
> If the registrar wants to really get rid of the domain, will have to
> update the hosts (rename or delete), and then issue the delete command.
>
>
>

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 10:44:25 -0800

well if another registrar is referencing the host you created, you're not supposed to allow the update: 

From RFC5732:

   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.

On Dec 19, 2012, at 10:41 AM, Seth Goldman <[email-masked]> wrote:

> I see. You're saying that the host object rename lets you work around the scenario where another registrar has a reference to one of your subordinate host objects. Otherwise, you're stuck in a scenario where you can't delete the domain until that other registrar removes its reference. Fair point, there's clearly no workaround for that.

Francisco Obispo

---

From: Seth Goldman <[email-masked]>
Date: Wed, 19 Dec 2012 13:47:15 -0500

Ah right, of course.

Isn't a hole in the EPP spec then? Another registrar can effectively hold
your domain hostage and prevent its deletion by adding a reference to one
of its subordinate hosts.

On Wed, Dec 19, 2012 at 1:44 PM, Francisco Obispo <[email-masked]> wrote:

> > I see. You're saying that the host object rename lets you work around
> the scenario where another registrar has a reference to one of your
> subordinate host objects. Otherwise, you're stuck in a scenario where you
> can't delete the domain until that other registrar removes its reference.
> Fair point, there's clearly no workaround for that.
>
> Francisco Obispo

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 13:50:10 -0500

That's the kind of behaviour that gets a registrar in trouble with their agreements - it's not a common occurrence 

Michael Young

M:647-289-1220

On 2012-12-19, at 13:47, Seth Goldman <[email-masked]> wrote:

> Ah right, of course.
> 
> Isn't a hole in the EPP spec then? Another registrar can effectively hold your domain hostage and prevent its deletion by adding a reference to one of its subordinate hosts.
> 
>

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 10:55:44 -0800

Consider the following:

test.TLD -> sponsored by registrar_a
example.TLD -> sponsored by registrar_b

test.TLD
  ns: ns1.example.tld
  ns: ns2.example.tld

example.TLD
  ns: ns1.test.tld
  ns: ns2.test.tld

registrar_a wants to delete test.TLD, issues a delete command for ns1 and ns2.test.TLD and it fails because of object associations.

the registrant has disappeared and registrar_a no longer has a way to charge him for the renewal

registrar_b cannot proceed with the change because the registrant of example.TLD is not responding to emails

The auto-renew proceeds in the registry, and charges the registrar for the operation.

So technically this can go on and on for a while, unless there's registry policy around it:

- We will allow the delete command, put it in a pending state for 5 days,
- if in 5 days the domains using the host are not updated we proceed with 
  the delete.

Any other thoughts?

Francisco Obispo

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 14:07:58 -0500

I'm not sure why you are solving a dispute between two registrars.

Currently registrar a contacts registrar b and complains. Registrar b disassociates the host object regardless of the fact the registrant went silent. Why? Because in all likelihood it's the same registrant behind both domains at two different registrars and they are ultimately responsible for managing their domains. If its actually two separate registrants with no relation, then registrar b has absolutely no reason not to remove the association.

This comes down to registrars and registrants doing their part as well AND well constructed RRAs in all parties joint interests.

Michael Young

M:647-289-1220

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 19 Dec 2012 11:21:32 -0800

> I'm not sure why you are solving a dispute between two registrars.

Well I'm not, but I'm just saying that registry policy could help fill in the gaps when stuff like this happens.

> Currently registrar a contacts registrar b and complains. Registrar b disassociates the host object regardless of the fact the registrant went silent. Why? Because in all likelihood it's the same r…

I agree, at the end, if the registrar's don't solve it, they'll end up paying for the renewals themselves.

Francisco Obispo

---

From: Christopher Browne <[email-masked]>
Date: Wed, 19 Dec 2012 14:43:00 -0500

> This comes down to registrars and registrants doing their part as well AND well constructed RRAs in all parties joint interests.

While the EPP standard doesn't speak specifically to this, it's pretty
reasonable to consider that the registrant that holds the domain is
intended to exercise control over the attendant zone.

We've done some agonizing over this, sadly not arriving at answers
that were sufficiently clear to assert as public policy, but here are
some thoughts...

It would seem reasonable that child hosts should always be modifyable
by the registrar owning the parent domain, or, (my preference), owned
by that registrar.
That would have the consequence that child hosts could at the very
least be put on clientHold.

Also possible would be to consider that Registrar A should be able to either:
a) Delete the child hosts, which would have the "cascade" effect of
removing references from other registrars' domains, or
b) Be allowed to submit <domain:update> requests specifically to
remove child hosts from other registrars' domains.

These possible policies all cross inter-registrar boundaries, but if
the registrant, as customer of Registrar a, is supposed to exercise
control over the zone defined by the domain, while they may not be
documented scenarios in the EPP RFCs, they are still at least
plausibly appropriate.

The current state of affairs is troublesome, leaving dealing with this
to some out-of-band communications.

---

From: Seth Goldman <[email-masked]>
Date: Wed, 19 Dec 2012 14:55:59 -0500

Actually, the RFC only says that this action is disallowed for external
hosts. For subordinate hosts, it's not well defined.

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 15:23:24 -0500

:-)

Michael Young

M:647-289-1220

---

From: Michael Young <[email-masked]>
Date: Wed, 19 Dec 2012 15:32:48 -0500

Hi Chris

The problem with the solutions you discussed is exactly what you stated, it involves cross registrar behaviour. 

Solution A is probably more tenable but still leaves the registry with another mass function which has its own risks.

At least the current situation causes registrar a and b to cooperate. This is a corner case that doesn't crop up often.

Michael Young

M:647-289-1220

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Dec 2012 07:08:31 +0100

On 19 dec 2012, at 19:47, Seth Goldman <[email-masked]> wrote:

> Isn't a hole in the EPP spec then? 

There are a number of unclear things in the EPP spec when you combine domain and host objects plus think of who the sponsoring registrar is.

I have a case where this is the scenario in one TLD:

Registrar A is sponsor for examplea.tld. Registrar B is sponsor for exampleb.tld. Now examplea.tld want to use ns2.exampleb.tld as name server. A name server that exists in the zone for exampleb.tld but not in the tld zone as glue (yet). The problem is that Registrar A is not allowed to create the ns2.exampleb.tld host object as they are not sponsor of the exampleb.tle, and it is not allowed to update the domain object exampleb.tld as the host object is subordinate to tld. A deadlock that so far after several months is not possible to resolve even via out of band mechanisms (i.e. pen, paper and letters).

So, having host objects as real objects can create very very very problematic situations. So be careful what you ask for.

   Patrik

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Thu, 20 Dec 2012 08:58:45 +0100

Hi,

> to charge him for the renewal

I thing the sponsoring registrar of a domain name must be able to
delete the domain name. If there is e.g. a court decision that the
registrar (or registrant) has to delete a domain name immediately, be
might not have the time to discuss which other registars have
associated host objects.

Another point: if you add status clientHold to the domain name, it
disappears from the zone. Shouldn't this include the GLUE hosts and
make them unresolvable as well?

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com

GPG-Key: 0x186C5F77

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Thu, 20 Dec 2012 09:02:01 +0100

Hi,

On 12/19/2012 08:07 PM, Michael Young wrote:

> Currently registrar a contacts registrar b and complains. Registrar b
> disassociates the host object regardless of the fact the registrant
> went silent.

if you want to be able to reach the registrar b, a host:info command has
to tell you which domains are connected to your host object. Is this
behaviour in the RFC?

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com

GPG-Key: 0x186C5F77

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 20 Dec 2012 09:50:07 +0100

On 20/12/12 07:08, Patrik Fältström wrote:
> There are a number of unclear things in the EPP spec when you combine domain
> and host objects plus think of who the sponsoring registrar is.
>
> Registrar A is sponsor for examplea.tld. Registrar B is sponsor for
> exampleb.tld. Now examplea.tld want to use ns2.exampleb.tld as name server. A
> name server that exists in the zone for exampleb.tld but not in the tld zone
> as glue (yet). The problem is that Registrar A is not allowed to create the
> ns2.exampleb.tld host object as they are not sponsor of the exampleb.tle, and
> it is not allowed to update the domain object exampleb.tld as the host object
> is subordinate to tld. A deadlock that so far after several months is not
> possible to resolve even via out of band mechanisms (i.e. pen, paper and
> letters).
>
> So, having host objects as real objects can create very very very problematic
> situations. So be careful what you ask for.
>
> Patrik
>

Hi,

I completely agree, but how realistic is the scenario? At the end, the zone of 
examplea.tld must be published on the actual name server addressed via 
ns2.exampleb.tld, i.e. the name server must be configured as a master or slave 
respectively, so it is likely that the two parties have to communicate somehow 
anyway. Only if more than two parties are involved, then probability of such a 
scenario increases IMHO.

Regards,

Klaus

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 Dec 2012 10:53:21 +0100

> So, having host objects as real objects can create very very very problematic situations. So be careful what you ask for.

agree, but it is an immediate consequence of the "wide" glue policy.

-Peter

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Dec 2012 11:09:16 +0100

On 20 dec 2012, at 09:50, Klaus Malorny <[email-masked]> wrote:

> I completely agree, but how realistic is the scenario? At the end, the zone of examplea.tld must be published on the actual name server addressed via ns2.exampleb.tld, i.e. the name server must be configured as a master or slave respectively, so it is likely that the two parties have to communicate somehow anyway. Only if more than two parties are involved, then probability of such a scenario increases IMHO.

Well, I have two such cases, because what also have to happen of course is that the registry do not allow registrarA to create a host object that is subordinate to a domain that registrarB is sponsor for.

   Patrik

---

From: Michael Young <[email-masked]>
Date: Thu, 20 Dec 2012 09:13:35 -0500

For host:info? There's nothing explicit in the child elements describing 
a client that is associated with the host object.

   Example <info> response:

    S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
    S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
    S:  <response>
    S:    <result code="1000">
    S:      <msg>Command completed successfully</msg>
    S:    </result>
    S:    <resData>
    S:      <host:infData
    S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
    S:        <host:name>ns1.example.com</host:name>
    S:        <host:roid>NS1_EXAMPLE1-REP</host:roid>
    S:        <host:status s="linked"/>
    S:        <host:status s="clientUpdateProhibited"/>
    S:        <host:addr ip="v4">192.0.2.2</host:addr>
    S:        <host:addr ip="v4">192.0.2.29</host:addr>
    S:        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
    S:        <host:clID>ClientY</host:clID>
    S:        <host:crID>ClientX</host:crID>
    S:        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
    S:        <host:upID>ClientX</host:upID>
    S:        <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
    S:        <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
    S:      </host:infData>
    S:    </resData>
    S:    <trID>
    S:      <clTRID>ABC-12345</clTRID>
    S:      <svTRID>54322-XYZ</svTRID>
    S:    </trID>
    S:  </response>
    S:</epp>

However under statuses it says:

- linked
The host object has at least one active association with another object, 
such as a domain object. Servers SHOULD provide services to determine 
existing object associations.

So there's a directive to provide that information you are looking for.  
However its a SHOULD not a MUST - 10 years later I'm leaning towards a 
MUST :-)

I'm not sure it really needs to be done in the host:info command for 
example: if I process a delete command against a host and it fails as a 
result of an existing association, then data about that existing 
association can be part of the error response.  A list of all 
associations with even a single host object could be a massive 
response.  More than one way to solve for this.

-M

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Thu, 20 Dec 2012 15:16:45 +0100

Hi Michael,

> However its a SHOULD not a MUST - 10 years later I'm leaning towards a

I agree. This information is very useful.

> association can be part of the error response.

This would be a good idea. Even if there are e.g. 1000 associated
domains and the number in response is limited, you'll be able to find
and fix them all step by step.

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com

GPG-Key: 0x186C5F77