RE: 3.4/Object Ownership, esp. Name Server Ownership

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>-----Original Message-----
>From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
>Sent: Wednesday, April 11, 2001 7:41 AM
>To: 'Klaus Malorny'; ietf-provreg@cafax.se
>Subject: RE: 3.4/Object Ownership, esp. Name Server Ownership

[snip]

>Now, one can argue (and we have, we've talked about this more than once)
>that this is a restrictive model, and that any registrar should be able to
>create a host in foo.com.  As I've said before, this introduces a different
>set of difficulties regarding management of foo.com that I believe are more
>difficult to solve.  Once you have multiple registrars creating objects
that
>are hierarchically related to foo.com the registrar of foo.com doesn't have
>a complete picture of the domain object, which may lead to inter-registrar
>(that is, _competing_ registrar) coordination requirements and associated
>problems.

After taking some more time to step back and consider the operational issues
associated with changing the domain-name server relationship as described in
the requirements draft, I'd like to ask anyone who believes that the
separation model is more appropriate to explain how the following scenarios
might be addressed:

The possibility of redirection and DoS attacks increases if multiple
registrars are capable of registering hosts as name servers.  For example,
registrar A sponsors foo.com, which has been delegated to ns1.foo.com and
ns2.foo.com.   Host www.foo.com exists in the foo.com zone.  Registrar B
registers www.foo.com as a name server object, with an IP address different
from the one specified in the foo.com zone, resulting in a redirection that
registrar A (and the registrant of foo.com) can do nothing about without
explicit action from registrar B, who may refuse to cooperate.  Yes, even
registrar A can register www.foo.com as a name server and cause problems,
but with only one registrar involved the problem is _much_ easier to
resolve.

If we allow domain objects (such as foo.com) to be deleted without requiring
deletion or renaming of name server objects (such as ns1.foo.com) registered
under the domain, we allow creation of orphaned A records.  This doesn't
have an immediate operational consequence for the DNS (queries for something
like www.foo.com will yield an NXDOMAIN response), but it does become a
garbage collection issue in the zone that publishes the glue record for
ns1.foo.com, which remains after foo.com has been deleted.  This, too, can
present a denial of service issue when someone re-registers foo.com and they
try to register a name server named ns1.foo.com, which won't be possible
because the old ns1.foo.com remains!

<Scott/>