[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: <asbjorn.rrp@theglobalname.org>
cc: <ietf-provreg@cafax.se>
From: Rick H Wesson <wessorh@ar.com>
Date: Mon, 5 Nov 2001 11:17:20 -0800 (PST)
In-Reply-To: <20011105185542.22173.qmail@nameplanet.aftonbladet.se>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: "External" hosts in EPP


asbjorn,

another potential solution is to only requre host objects for hosts that
require glue. in other words hosts outside the zone don't need a host
object created. hosts inside the managed zone require a host object to be
created and associated with the deligation.

-rick


On 5 Nov 2001 asbjorn.rrp@theglobalname.org wrote:

> Hi,
>
> earlier on the list there have been some concerns about out-of-zone hosts [1]. The problem is of course that without a RegistrY-RegistrY mechanism (which is probably out of the EPP-scope), the concept of "ownership" does not apply to out-of-zone hosts.
>
> This means that registration of host objects are basically first-come first-serve. In this lie the problems of RegistrARs blocking deletion (or creation) of hosts, and RegistrARs "hijacking" domains:
>
> If RegistrAR A owns example.com, the protocol will allow RegistrAR B to register ns.example.com in the .NAME Registry, as long as it is the first RegistrAR trying to register that host in the RegistrY. RegistrAR B might now chose to refer to that object from his domain john.smith.name, as the host-object involved do not include any IP addresses used for GLUE records, and therefore seems to be safe. If RegistrAR A now updates the name of the host object to be a .NAME hostname and simultaneously adds IP-addresses (which EPP allows, AFAIK)[2], it unfortunately gives RegistrAR A full control over DNS for "john.smith.name"[3].
>
> I am wondering if the following might be worth considering:
>
> a) For in-zone hosts, everything is as described in EPP-host-03.
>
> b) Out-of-zone hosts, on the other hand, are "private" to a RegistrAR; they are registered on a RegistrAR basis and will be invisible/un-referable for other RegistrARs.
>
> E.g., for ns.john.jones.name in the .NAME RegistrY, everyone can refer to that host and there only exists one instanse of that name in the host table. For ns.example.com, there might be multiple Registrars having registered that object, though they do not really know of (or care about) the other instances, and can thus not refer to the other instances. The key for the host table would then be the combined key of Registrar and hostname, and this would thus be the same for both in-zone hosts and out-of-zone hosts.
>
> This "private" name space for external hosts would necessarily cause a change to how transfers of domains are treated though, as external hosts would have to be dealed with as well... :-d
>
> This method would give the RegistrARs full control over the external hosts they use, and noone can block them from deletion/creation of the host... It might be a bit more complicated, but I see that some problems might be avoided this way.
>
> Comments?
>
>
> Asbjorn
> Global Name Registry
>
>
> [1] Also know as "external" hosts. I.e., hosts that do not exist in the name space of that particular Registry
>
> [2] In http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00088.html, it states that the only thing changable in an external host is the name, but AFAIK you can also add IP-addresses if the new name is now "in-zone" due to the name change.
>
> [3] You might ask why RegistrAR B would refer to an object owned by RegistrAR A, but there is not a(n easy) way for him either to "force" RegistrAR A to release the hostname...
>
>
> --
>  The information transmitted in this email is intended only for the person(s)
>  or entity to which it is addressed and may contain proprietary, confidential
>  and/or privileged material. If you have received this email in error, please
>  contact the sender by replying and delete this email so that it is not
>  recoverable. If you are not the intended recipient(s), any retention, review,
>  disclosure, distribution, copying, printing, dissemination, or other use of,
>  or taking of any action in reliance upon, this information is strictly
>  prohibited and without liability on our part.
>


Home | Date list | Subject list