Subject: Re: Handling of External Host Objects: Single vs. Multi Copy Solutions (was: in the context of domain transfer)

From: janusz sienkiewicz <[email-masked]>
Date: Fri, 01 Nov 2002 16:02:51 -0500

Asbjorn,

please see comments below ...

Asbjorn Steira wrote:

> (a) Mass updates (I). In the single-copy model, a registrar potentially
> needs to do x thousand domain update commands when changing a name
> server name from ns1.example.tld to ns2.example.tld. This can be done
> with only one host update command in multi-copy.
>
> (b) Mass updates (II). As far as I can see, the single-copy model won't
> support any kind of moving name servers into the zone, you would always
> need to run update commands for all domains. In most cases, this would
> work fine in the multi-copy model.
>
> That's the only things I can come up with right now.

I can see ability to do mass updates as a double edged sword. It is easy to trigger a massive database update and DNS glue records generation by a mistake with host update. It also opens big window of opportunities for DoS attacks.

Regards,

Janusz Sienkiewicz

> Hong,
>
> please see comments below...
>
> Asbjorn
>
> Liu, Hong wrote:
>
> > In terms of (3), you are making an assumption about server policy in
> > terms of who is eligible to query an external host using . What if the
> > server policy is any client is eligible to query a host object? Will
> > the server return 2303 if the client does not have a private copy
> > while there are many other private copies out there? How can a server
> > return multiple instances of the same external host in an response?
> >
> > So the only way out is to codify in the protocol that a client can
> > only its private copy for external hosts. This is in effect enforcing
> > a server policy. As discussed on the list many times before, the
> > protocol should be flexible enough to allow different policies, but
> > _not_ to enforce a specific policy. In addition, this is no longer an
> > implementation issue, it now becomes a protocol issue.
>
> I realize that the sponsoring registrar can only view his own copy of
> the host object, and even though this is not perfect, I don't think this
> is a big problem. There is not really any useful information related to
> an external host, the only thing that might be of interest is the status
> of the object.
>
> > As for whois, to avoid confusion, an end user now needs to use both
> > the hostname and the registrarID to query an external host. I would
> > not speculate how many end users really know or care about
> > registrarIDs. They use whois just want to find out if a host exists or
> > not. Plus, most of the whois implementations today do not provide
> > {hostname,registrarID} query capability. Are you suggesting that even
> > the whois part (and user behavior) needs to be modified in order to
> > accommodate the multi-copy model? Is it introducing more problems in
> > order to solve _a_ problem?
>
> This depends on how you implement it - the end user does not necessarily
> need to know the registrar name/id. For .name we simply return all the
> instances of the object, for example:
> http://www.nic.name/cgi-bin/whoisweb.cgi?type=public&page=query&d=d&qt=nameserver&q=NS.NEWDREAM.NET
>
> > In terms of the support for reference-based renaming, the
> > server-centric single-copy model does not prohibit such operation.
> > That is, a sponsoring registrar is still capable of renaming any
> > internal host objects created through it. The problem is
> > reference-based renaming for external host objects. In our single-copy
> > approach, this has to be done one-by-one.
> > However, for the multi-copy model, reference-based renaming only works
> > for massive external-to-external nameserver updates. For other cases,
> > it has to perform the nameserver updates one-by-one for most of the
> > domains:
>
> > (5) Partial updates. For example, both registrant A and registrant B
> > use ISP X's DNS hosting services. Suppose both A and B register their
> > domains through the same registrar R, using the same set of namesevers
> > provided by X that are external hosts. Now B decides to use ISP Y's
> > DNS hosting service instead. Suppose that the nameservers provided by
> > Y are also external hosts.
> > Then registrar R cannot just rename X's nameservers to Y's since A's
> > domains are still using X's nameservers. So R has to update B's
> > domains one-by-one.
>
> This could be done with only one host update command in a multi-copy
> universe.
>
> > (6) External-to-internal. Suppose ISP X is also a registrant of R. It
> > creates a set of internal hosts through R. So R is the sponsoring
> > registrar of these hosts. Then X decides to use these hosts as
> > nameservers to provide DNS hosting services to all the domains in the
> > same registry. Then R cannot just rename the external hosts to the
> > internal ones since those internal hosts already exist in the
> > registry. So R will have to update each domain of A and B one-by-one.
>
> Would be the same for single-copy and multi-copy...
>
> > Another scenario could be that R implicitly creates these internal
> > hosts by renaming the external hosts. In this case, R does not need to
> > update each domain of A and B one-by-one. However, other registrars
> > will have to update domains one-by-one: they cannot just rename their
> > private copies to the internal hosts since they are not the sponsoring
> > registrar of those internal hosts.
>
> Would be the same for single-copy and multi-copy...
>
> > (7) Internal-to-external. Suppose ISP X has an internal host sponsored
> > by R that is being used as a nameserver of other domains. Now X wants
> > to replace that with an external host. There are two cases to consider:
> > (a) R already has a private copy of the external host. Then R cannot
> > rename the internal host to the external host. Instead, R will have to
> > update each domain one-by-one that uses the internal host as nameserver.
>
> Would be the same for single-copy and multi-copy...
>
> > (b) R does not have a private copy of the external host. R can rename
> > the internal host to the external host without any problem since it is
> > the sponsoring registrar, and all domains sponsored by R that are
> > using the internal host as nameserver now points to the external host.
> > In both cases, domains sponsored by other registrars that use the
> > internal host as nameserver will have to be updated one-by-one. To
> > make things even worst, in the case of 7(b), before these updates are
> > completed, domains in other registrars will be pointing to private
> > copy of external host in R.
> > This violates the very principle of the multi-copy model!
>
> I think this was discussed on the list at some point. And I think this
> is the biggest "problem" we identified with the multi-copy solution.
>
> > In summary, I would like to get answers from the multi-copy proponents
> > for the following questions:
> >
> > (i) What are the advantages of the multi-copy model as compared to the
> > server-centric single-copy model?
>
> (a) Mass updates (I). In the single-copy model, a registrar potentially
> needs to do x thousand domain update commands when changing a name
> server name from ns1.example.tld to ns2.example.tld. This can be done
> with only one host update command in multi-copy.
>
> (b) Mass updates (II). As far as I can see, the single-copy model won't
> support any kind of moving name servers into the zone, you would always
> need to run update commands for all domains. In most cases, this would
> work fine in the multi-copy model.
>
> That's the only things I can come up with right now.
>
> I do see that the single-copy model solves the 7b-problem and
> potentially makes the transfer process a bit easier, and I guess it is
> all about if you want that or if you rather wanna make mass updates
> easier. I see strong and weak points with both solutions...
>
> > (ii) What are the complaints on the former client-centric single-copy
> > model that are not addressed by the server-centric single-copy model,
> > but are solved by the multi-copy model?
>
> Not having dealt with RRP registries, I cannot answer this :-).
>
> (Asbjorn)
>
> --
> Asbjorn Steira
> The Global Name Registry, Limited
>
> Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
> *****************
> What's your .name?
> Get one at www.name
> *****************

---

From: "Jens Wagner" <[email-masked]>
Date: Sat, 2 Nov 2002 11:50:16 +0100

----- Original Message -----
From: "Liu, Hong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 31, 2002 12:37 AM
Subject: RE: Handling of External Host Objects: Single vs. Multi Copy
Solutions (was: in the context of domain transfer)

...
> (7) Internal-to-external. Suppose ISP X has an internal host sponsored by
R
> that is being used as a nameserver of other domains. Now X wants to
replace
> that with an external host. There are two cases to consider:
rename
> the internal host to the external host. Instead, R will have to update
each
> domain one-by-one that uses the internal host as nameserver.
> (b) R does not have a private copy of the external host. R can rename the
> internal host to the external host without any problem since it is the
> sponsoring registrar, and all domains sponsored by R that are using the
> internal host as nameserver now points to the external host.
> In both cases, domains sponsored by other registrars that use the internal
> host as nameserver will have to be updated one-by-one. To make things even
> worst, in the case of 7(b), before these updates are completed, domains in
> other registrars will be pointing to private copy of external host in R.
...

Hong,

Just thought about your point 7(b):

Registrar R1 creates domain dom1.tld
Registrar R1 creates host ns1.dom1.tld (internal host)
Registrar R1 updates domain dom1.tld to use nameserver ns1.dom1.tld
(internal)
Registrar R2 creates domain dom2.tld with nameserver ns1.dom1.tld (internal)
so far, its seems to be ok:
----
dom1.tld managed by R1 has nameserver ns1.dom1.tld
dom2.tld managed by R2 has nameserver ns1.dom1.tld
----

now we apply Scenario 7(b):
Registrar R1 renames host ns1.dom1.tld (internal) to ns.dom.ext(,R1)
(external)

What does the Registry DB look like now?
----
dom1.tld managed by R1 has nameserver ns.dom.ext(,R1) (external)

What happens with dom2.tld? Three possibilities:
1. dom2.tld managed by R2 has nameserver ns1.dom1.tld (internal)
2. dom2.tld managed by R2 has nameserver ns.dom.ext(,R1) (external)
3. dom2.tld managed by R2 has nameserver ns.dom.ext(,R2) (external)
----

(1.) should not be possible, because R1 removed the internal host
ns1.dom1.tld by renaming it.
(2.) should not be possible, because ns.dom.ext(,R1) must not be accessible
by R2.
(3.) should not be possible, because this would mean that R1 created an
external host object ns.dom.ext(,R2) in the repository of R2.

Or did I get anything wrong?

Best regards,

Jens Wagner
Key-Systems GmbH