Re: host transfers

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

Patrick wrote:
> 
> Dear all,
> 
> Sorry to be late and sorry if I am a little heavy(?) with what
> follows, I just want to be sure to understand everything.
> 
> On Thu, Aug 09, 2001 at 11:17:24AM +0200, Klaus Malorny took time to write:
> > 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...
> 
> Ok, this is true. But see above, I think your proposal does create
> the same problem :
> client goes to registrar B to make changes in IP and it does not see
> they are used at all (since it should have gone through A).
>

Unfortunately, I don't understand your example. Eventually this will help you:
If the client asks registrar B to change something, it typically changes only
domains registered via B and not those registered via A.

 
> > 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
> 
> [..]
> 
> > 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.
> 
> Why don't you have glue record for ns3.A.com ??

Why should I? They are not required. Why doesn't www.A.com appear here? Because
it's not required. ns3.A.com is not used to operate the A.com domain. The zone
file for .com IS NOT AUTHORITIVE for A.com, therefore it is not authoritive for
any A record (or any other record) in the A.com zone. Please remember that glue
records are an aid to solve a technical problem and they definitely break the
concept of authoritative zones.

> I do not understand.
> ns1.A.com / ns2.A.com / ns3.A.com are 3 nameservers, and they should
> be treated in the same way.

But they are not identical. What about a name server, e.g.,
ns.microsoft.customers.A.com? Is it o.k. that it appears in the TLD zone? I
don't think so.

> 
> Do you mean that the glue record is not needed since IP address of
> ns3.A.com is in ns{1,2}.A.com authoritatives for A.com ?
> If yes, I do not think it is a good idea to have one setup for the
> first two nameservers, and another for the others.

Yes and no, as there seems to be a misunderstanding.

No. Any name server below A.com that IS USED AS a name server FOR the domain
A.com should get its glue record. If the A.com has five NS records with
ns1.A.com ... ns5.A.com, all should get a glue record, of course.

Yes. A name server that is not enlisted in the domain's NS list should NOT get a
glue record.

> 
> > 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.
> 
> And then there is the problem outlined above :
> when the client will want to change IP address of ns3.a.com if he
> goes through registrar B, it will be possible, but will have not
> useful use. Whatever IP the client will try to put, it will NOT be
> reflected in the zone file, since to do that he should go through
> Registrar A.

Compare this to the contacts. My real world address in the contact isn't
normally used, except in some case of 'emergency'. Similarily, the specified
addresses are only used if and only if we have this special emergency case of
'zone bootstrapping', where glue records are required. This needs to be
communicated to the people.

> Of course it can just be written/explained to the client that he
> needs to go through Registrar A. But people make assumptions, and if
> the client sees it possible to change IP through B, he will try, and
> will not understand why it does not work at all.

I think people are able to understand that they can only modify a name server's
IP at the registrar where the corresponding domain is registered. To be correct,
they have to look into the domain record, look at the referenced name server and
determine the sponsoring registrar. Another way is to create a new record and
update the domain accordingly. It's exactly the same process as the modification
of, let's say, the phone number of a technical contact.

> 
> In fact, with your proposal, even IP address of ns3.A.com through
> Registrar A has no meaning since it is not included in zone file,
> thus the problem outlined just below do not exist. But still I do not
> understand/think it is a good idea that ns3.A.com is not in the zone
> file.

As I mentioned earlier, the zone file of the domain is the authoritative source,
not the registry. It is an unnecessary duplication of information.

> 
> But do your model with another example : Registrar B for B.com uses
> ns2.A.com and not ns3.A.com
> How do you will handle it ? The problem outlined above then exists :
> Registrar A chooses IP address of ns2.A.com

> If you try to change it through Registrar B (which have also a record
> for ns2.A.com), the change will not appear in zone file.

Registrar B's copy of the record is not referenced in A's domain object as a
name server, but A's own record. Therefore, not the IP address of B's record is
used, but the IP address of A's record. So it behaves as you describe. And it
should behave like this, because the registry does not know whether registrar B
has the right to update the IP address. As long as we are stuck with this
"registrar sponsoring model", there is no other solution. A registrar may grant
another registrar the right to choose the IP address by referencing a name
server object of him in the domain (as in situation #1 with domain B.com).
Theoretically, the following is possible:

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 (R2)
                                     ^^

In this situation, R2 and only R2 is able to change the IP of N2. R1 may update
domain A.com, of course, and switch to another name server object that also
describes ns2.A.com and that is sponsored by R1, resulting in the original
situation. Although this is a quite unusual situation, I don't see any cause why
this should be prevented by the registry. It's not the registry's duty.


> 
> > 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.
> 
> In that case, please also take into account another (current)
> problem.
> Right now, for example if you want to destroy domain A.com you can
> not until there are no more nameservers child of this domain used
> anywhere else.

This is not true, with my definition of "anywhere else". See below.

> In your model, will Registrar A be able to delete A.com if he wants,
> since Registrar B has created ns3.A.com and I think that Registrar A
> has no way to know that ?
> If no, then it is a big problem.

Our company, Knipp, owns the domain knipp.de. We have name servers (beside
others) ns2.knipp.de and ns3.knipp.de, that customer can use as
primary/secondary name servers. 

So he may register a domain, e.g. B.com with the name servers ns2.knipp.de and
ns3.knipp.de. Knipp could delete the domain knipp.de at DENIC. Nobody at
Verisign/NSI would take notice about that. Nevertheless, the domain B.com would
become disfunctional. 

Vice versa, Knipp could use the name servers ns1.knipp.net and ns2.knipp.net for
the domain knipp.de, but Verisign/NSI would not prohibit me of deleting these
name servers or even the domain knipp.net, despite the ongoing usage.

Even if a customer registers the domain B.com with ns3.A.com and ns4.A.com, the
operator of these name servers could push the power switch and render the
(obviously) holy grail of strong binding of name servers to their domains
useless.

Whether it is a problem at all, and whether it is a small or a big one, it
already exists.


I don't want to be offensive. But the more I read in this list here the more I
am missing the 'global view' of the participants, the view beyond the borders of
the registry system. Big efforts are taken to have some consistency in a single
registry and they are defended by all means - although their contribution to the
stability of the Domain Name System are marginally. Even worse, due to the fact
that we get more and more ccTLD/gTLD registries around the world (especially
think of the upcomming separation of the com/net/org registry), it will become
quite uncommon that the name servers of a domain belong to the same TLD which
make these efforts useless. On the other hand, problems that may arise from this
fact are not considered in any way. The assumptions the current name server
concept is based on are from a time long ago where NSI was the only BIG registry
and where customers directly registered with NSI. Therefore, the emerging
protocols that have been proposed here until now may be new, but their concepts
are still the same old ones. No real advance.

This disappoints me somehow.

> 
> Regards,
> Patrick Mevzek.

regards,
Klaus Malorny