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

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

"Hollenbeck, Scott" wrote:
> 
> >-----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/>

Hi Scott,

first of all, I agree to your analysis regarding the problem of the deletion
of a domain without the deletion of its name servers, and I also think that
the consequences of it should be avoided. Nevertheless, I would like to remark
that this problem will appear whatever we define in this protocol caused by
the ability to use name servers outside the control of the registry, i.e. name
servers belonging to other ccTLDs or gTLDs not managed by the registry. 

There are solutions to the problem of course. I haven't deliberated the
following two solutions completely, but I would like to mention them:

1) If a domain gets deleted, all existing name servers are deleted also. If
these name servers are used in any other domain, they are removed from these
domains, i.e. each those domains looses one name server. A drawback of this
solution is of course a lot of hidden changes not visible to the registrars
that might be affected by that. But the registrars could be notified.

2) We had a long debate about unique identifiers on the list recently. This
solution would really use them! The name servers belonging to a certain domain
do not reference the domain by its name, but by its UID. If the domain gets
deleted, its UID becomes void. The name server objects remain intact, but due
to the void reference they are no longer used for the zone file generation.
The registrar sponsoring the name server would get a notification about the
deletion of the domain. In the circumstance that a new domain is created with
the same name, this domain would get another UID, different to the UID of the
previous domain. The existing name servers would still have the old UIDs in
their references and would not be used for the zone generation. By an update,
the registrar may change the name server. If he uses the same domain again,
the UID of the reference will be updated to the new UID.

For the problem you mention for the registration of name servers by registrars
not sponsoring the corresponding domain, one could either disallow the
specification of the IP address or just ignore it in the zone file generation.
(There we come back to the discussion "Nameserver MUST HAVE IP", so I'll stop
here).

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