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

[janusz sienkiewicz <janusz@libertyrms.info>]

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