Re: host transfers

[Klaus Malorny <Klaus.Malorny@knipp.de>]

Sheer El-Showk wrote:
> 
> > [...]
> 
> 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.

You are right regarding the consistency. But we often have a situation like
this:

Registrant R goes to registrar A and registers a.com with ns1.a.com and
ns2.a.com. Some time later. Now, registrar B has a good offer, and R wants to
register a domain with him, lets say b.com with ns.b.com and ns3.a.com.
"Sorry, we can't do that, you can't use ns3.a.com" - "Why, a.com is my
domain?" ... and so on...

So many things may be logical from a registry's view, but when it comes down
to the registrant, it may look quite different.

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

Like with contacts, a registrar may not change an object that is sponsored by
another one. He may use the ns object of the other registrar, but need not.
Also, he could create another object for this name server. My modelrequires,
of course, that the registry objects for name servers are not identified by
the domain name of the name server, but by a handle, or, in EPP-speak, by a
ROID. So, answering your question:

A.com uses ns1.A.com
B.com uses ns1.B.com

The terminology "alias" you use is a good way to describe the function of the
name server object in the registry's repository, but it is not an alias for
the IP addresses of the name server, instead, for the name server as a whole.
Changing the object changes all domains associated with it, but not the name
server per se.

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

I wouldn't call this namespace. A registrar would be free to use a different
registrar's ns object, create a single object for his own purpose or even a
dozen. It's the purpose of the registrar to do a suitable housekeeping.
Nevertheless, I don't see a havoc. To the contrary, I propose to rely more on
the DNS itself for the resolution of name server IP addresses by limiting the
generation of glue records. As I mentioned earlier, the proposed model acts
similar to the current model if this deals with name servers for which it is
not authoritive. So if you see a havoc here, do you also see a havoc there?

Maybe the following example explains a bit:

Situation:
----------

Two registrars: R1, R2

R1:
  A.com, using ns1.A.com, ns2.A.com
    ns1.A.com, 1.1.1.1
    ns2.A.com, 2.2.2.2
    ns3.A.com, 3.3.3.3
R2:
  B.com, using ns1.B.com, ns3.A.com
    ns1.B.com, 4.4.4.4

current model:
--------------

registry objects:

domain        A.com, ns1.A.com, ns2.A.com (R1)
name server   ns1.A.com, 1.1.1.1 (R1)
name server   ns2.A.com, 2.2.2.2 (R1)
name server   ns3.A.com, 3.3.3.3 (R1)

domain        B.com, ns1.B.com, ns3.A.com (R2)
name server   ns1.B.com, 4.4.4.4 (R2)

zone file:

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
ns3.A.com.   A          3.3.3.3
B.com.       NS         ns1.B.com.
B.com.       NS         ns3.A.com.
ns1.B.com.   A          4.4.4.4


Please correct me if this is incorrect.

my model:
---------

situation #1: R2 shares ns3.A.com with R1

registry objects:

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)
name server  N3: ns3.A.com, 3.3.3.3 (R1)

domain       B.com, N4, N3 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)

zone file:

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
B.com.       NS         ns1.B.com.
B.com.       NS         ns3.A.com.
ns1.B.com.   A          4.4.4.4

note that no A record exists for ns3.A.com.



situation #2: R2 has an own object for ns3.A.com

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)
name server  N3: ns3.A.com, 3.3.3.3 (R1)

domain       B.com, N4, N5 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)
name server  N5: ns3.A.com (R2)

zone file:

exactly the same as above, even if R2 specifies an (arbitrary) IP address for
N5.


situation #3: R2 has an own object for ns3.A.com, R1 not


domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)

domain       B.com, N4, N5 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)
name server  N5: ns3.A.com (R2)

zone file:

exactly the same as above, even if R2 specifies an (arbitrary) IP address for
N5.


If registrant of A changes the IP address of ns3.A.com in the DNS(!!), B will
continue to work. R2 can easily migrate to a different name server just by
changing N5. All other domains also using N5 would migrate, too.

You may say: "It could be that ns3.A.com does not exist". That's quite true.
But the current model does not guarantee this neither. Even if you define an A
record for ns3.A.com, the IP address may be wrong or the machine behind this
may not be configured correctly.


change:
name server:  N5: ns2.B.com, 5.5.5.5 (R2)

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
B.com.       NS         ns1.B.com.
B.com.       NS         ns2.B.com.
ns1.B.com.   A          4.4.4.4
ns2.B.com.   A          5.5.5.5

> 
> Regards,
> Sheer


regards,
Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0