Re: Should a nameserver know about itself?

Shane Kerr <shane@ripe.net> Wed, 30 May 2001 09:25 UTC

Received: from nic.cafax.se ([192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04068 for <dnsop-archive@odin.ietf.org>; Wed, 30 May 2001 05:25:33 -0400 (EDT)
Received: by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f4U94AA4018756 for dnsop-outgoing; Wed, 30 May 2001 11:04:10 +0200 (MEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f4U948Lt018751 for <dnsop@cafax.se>; Wed, 30 May 2001 11:04:08 +0200 (MEST)
Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA11198; Wed, 30 May 2001 11:03:37 +0200 (CEST)
Date: Wed, 30 May 2001 11:03:36 +0200
From: Shane Kerr <shane@ripe.net>
To: "D. J. Bernstein" <djb@cr.yp.to>
cc: dnsop@cafax.se
Subject: Re: Should a nameserver know about itself?
In-Reply-To: <20010529232301.5659.qmail@cr.yp.to>
Message-ID: <Pine.BSI.4.05L.10105301102430.8181-100000@x17.ripe.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-dnsop@cafax.se
Precedence: bulk

On 29 May 2001, D. J. Bernstein wrote:

> Unfortunately, neither ARIN nor RIPE supports glue, despite the last
> paragraph of RFC 1034 section 4.2.2, so reverse lookups on the
> Internet are unnecessarily rickety.

Remember that registries are concerned with address to name mapping, and
this is a name to address mapping - one that is already performed
elsewhere.

The problem as I see it is that in order to provide glue records, the
RIR's need to track the A records similar to what you demonstrated.  
What this means is that when an in-addr.arpa zone changes (e.g. new
nameserver added, nameserver IP changes) the zone administrator has to
remember to update both their own zone files (or equivalent in the
tinydns case) as well as the records at the appropriate RIR.

One possible solution is for the RIR's to allow the recipients of
delegated space the option of maintaining glue information, so they can
decide for themselves whether they want the administrative overhead in
exchange for increased reliablity and response, reduced network and
server load, etc.  In reality it is likely there would be a lot of
garbage - perhaps even reducing the reliability of IN-ADDR.ARPA in
general rather than increasing it.

Would the RIR's then have to run automatic processes to verify their
glue records?  Would (should) they then simply use those all the time
rather than requiring users update them manually at all?  There are
large disadvantages to an automatic process like this.

IIRC, I asked for community input about this issue when I was at ARIN,
and received no feedback - my guess is that the Internet at large
doesn't consider it an important issue.

--
Shane