Re: "External" hosts in EPP

[asbjorn.rrp@theglobalname.org]

Rick,

I've thought about that myself, and I like that idea too. If we can agree on that, and change the protocol to allow that, I would definitely drink to that. I change my mind about which idea I like best every minute or so, though... :-)


Asbjorn
GNR Ltd


On Mon, 5 Nov 2001 11:17:20 -0800 (PST) Rick H Wesson wrote:
>
>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.
>>
>
>


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