Re: Should a nameserver know about itself?

Bruce Campbell <bruce.campbell@apnic.net> Fri, 01 June 2001 04:54 UTC

Received: from nic.cafax.se ([192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16696 for <dnsop-archive@odin.ietf.org>; Fri, 1 Jun 2001 00:54:36 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f514Qd7i006962 for dnsop-outgoing; Fri, 1 Jun 2001 06:26:39 +0200 (MEST)
Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f514QZLt006957 for <dnsop@cafax.se>; Fri, 1 Jun 2001 06:26:36 +0200 (MEST)
Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id OAA15385; Fri, 1 Jun 2001 14:26:32 +1000 (EST)
Received: from julubu.staff.apnic.net(192.168.1.37) by int-gw.staff.apnic.net via smap (V2.1) id xma015372; Fri, 1 Jun 01 14:26:10 +1000
Received: from localhost.staff.apnic.net ([127.0.0.1]) by julubu.staff.apnic.net with esmtp (Exim 3.22 #2) id 155gVu-000JsE-00; Fri, 01 Jun 2001 14:26:18 +1000
Date: Fri, 01 Jun 2001 14:26:16 +1000
From: Bruce Campbell <bruce.campbell@apnic.net>
X-Sender: bc@julubu.staff.apnic.net
To: Robert Elz <kre@munnari.OZ.AU>
cc: Shane Kerr <shane@ripe.net>, dnsop@cafax.se
Subject: Re: Should a nameserver know about itself?
In-Reply-To: <3431.991312889@brandenburg.cs.mu.OZ.AU>
Message-ID: <Pine.BSF.4.21.0106011325490.65945-100000@julubu.staff.apnic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-dnsop@cafax.se
Precedence: bulk

On Thu, 31 May 2001, Robert Elz wrote:

>     From:        Shane Kerr <shane@ripe.net>
> 
>   | But I suspect this is exactly what Bruce is suggesting!
> 
> My impression was that Bruce was imagining something different than what
> is actually being suggested here.

Yes and no.  You've said that:

: Anyone delegating pieces of the DNS tree (whether for profit, as a 
: public service, or just to other parts of their own organisation) ought
: to be doing it properly.  And that includes inserting glue records
: whenever they are required.

So, when I refer to 'glue', that is strictly what is required.  In the
case of reverse delegations, that is nameservers within the reverse trees,
being in-addr.arpa (IPv4) and whatever the IPv6 reverse flavour of the
week is.

'Glue' can be extended to be also whats *not* strictly required, being
nameservers currently visible in the forward tree, but that is only of
benefit when the given forward tree is flakey.  (lets not go into that)

>   | Looking at the in-addr.new file from ARIN reveals that there are less
>   | than 25000 unique servers, a nearly trivial number of lookups to perform
>   | to get glue information.

[ snip kre's suggestion of making RIR nservers recursive from RIR
  equipment, and RIRs priming said nservers with pseudo-glue records ]

Workable, doesn't break anything, catches up to address changes in
acceptable (user-controlled via SOA values) time, and is probably a 10
line addition to our current zone generation scripts.

> But it has nothing at all to do with whether the registry will enter
> necessary glue information when it is required - that glue must be manually
> entered into the zone file - by definition, it is required only if there's
> no way to obtain it using normal DNS methods, ie: you hit a circular
> dependency, you can't get the A record for X without first finding the A
> record for X...

Correct. 

> The question isn't whether this is a sane way to delegate things, but that
> given it is a legal way, why is it not being supported by the registries?

An assumption has existed that reverse delegations are delegated to
nameservers in forward domains, making the issue of the RIRs supplying
*required* glue somewhat of a moot point.

> It is somewhat ironic that the in-addr.arpa registries won't insert glue
> when it is needed, and the COM (etc) registries (or maybe it is the root)
> insist on inserting glue when it isn't...

It is, isn't it.

> The only issue here is whether it is possible, not whether it should be
> advocated.   Or at least, that's the only one worth discussing.

The idea of containing nameservers for a reverse zone inside said reverse
zone is not new (certainly not djb's sole idea), and has a certain
elegance.  

Certainly *if* APNIC supported required glue, APNIC would make mention of
it (ns-foo.x.y.z.in-addr.arpa) as *a* reverse delegation method in APNIC's
documentation.

-- 
  Bruce Campbell <bruce.campbell@apnic.net>                +61-7-3367-0490
                      Systems Administrator                          APNIC