Re: host transfers

[Sheer El-Showk <sheer@saraf.com>]

> As you asked, Scott ;-)
>
> You know, I have a somewhat diametric opinion to that. Tieing name servers to
> domains may be not too difficult for the registry itself, but it generates a
> lot of problems at the registrar level and beneath, esp. if a registrant
> registers his domains with multiple registrars/resellers and starts moving
> them around. As someone who develops software in this context the whole thing
> of linking name servers to domains, additionally depending on the name
> servers' TLDs, is an artificial obstacle, good for nothing, a graveyard for
> LOCs ;-) and is repeatedly a cause to reject registrations/changes. Therefore
> I prefer a system without this tieing.

While I can't disagree with you on the horrors involved in Registrar
tracking of nameserver/domain relations, in a well designed and
self-consistant system the registrar has a full on-site database that
mirrors registry database operations and maintains consistency relatively
easily by this virtue alone (all operations are performed on the
regsitrar database and passed through to the registry).  I'm not speaking
abstractly -- I've been there ... and I did say well designed system; of
course tracking the rules is not easy and maintaining consistency with
the registry on failed commands is no fun.  The only real issue is
sudden, silent acquisition of nameservers through a transfer and that's
what the poll mechanism is for.

>
> In an earlier discussion, you mentioned a way to get faked IP addresses for
> e.g. www.microsoft.com into the system. But this was caused by the fact that
> your current model always generates glue records for a name server that is
> contained in the registry's TLD(s). If the glue record generation is more
> stringent, this problem can be avoided.
>
> The model I have in mind is the following:
>
>  - anyone can register any name server, and multiple name server objects
>    may exist for a single "real" name server (similar to a person who
>    can have multiple contacts with exactly the same data).
>

Then what happens in the following situation:

registrar A registers ns1.A.com and uses it for A.com
registrar B registers ns1.A.com and uses it for B.com

then registrar B renames ns1.A.com to ns1.B.com -- which nameserver does
this affect.  Both?  Only it's "view" of ns1.A.com?  Is your proposal a
seperate nameserver "namespace" for each registrar with the authoritative
glue records only emerging from the "namespace" owning the appropriate
parent domain (as per your comment below).

This seems like hidden behaviour to me which is something I'm
uncomfortable with (never mind that the domain registration world is
already full of such hidden behaviour).  I think you're thinking of a
nameserver as only an IP address alias ... its more than that ... its a
database entity (not tied to its name) that domains can form relations
with independent of IP address or name changes -- this behaviour is very
important for large ISPs who may host many domains on a single machine
which can be renamed or move to a new subnet without changing its domain
relations.


>  - IP addresses can be attached to any name server, but there is no
>    guarantee that these are used (see below)
>

See above ... this seems like you're just misguiding the user by allowing
them to enter data you ignore.

>  - especially, there is no difference between name servers that belong
>    to the registry's TLD(s) or not.
>
>  - in the zone file, a glue record (A/AAAA/A6 record) is generated
>    iff the name server lies in a domain which references this name server
>    (i.e. the domain specifies it in its NS record).
>

I'm not sure if I misrepresented you in trying to understand how you would
allow multiple represtations of a single nameserver.  Please correct me if
I'm in error.  As I understand your system now however, I think it may
make registrar's lives easier by providing them by their own stomping
ground namespace within the registry but it plays havok on generating
viable zones in a predictable way.

Regards,
Sheer