Re: Should a nameserver know about itself?

bert hubert <ahu@ds9a.nl> Wed, 30 May 2001 10:16 UTC

Received: from nic.cafax.se ([192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04468 for <dnsop-archive@odin.ietf.org>; Wed, 30 May 2001 06:16:35 -0400 (EDT)
Received: by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f4U9tQ2k019358 for dnsop-outgoing; Wed, 30 May 2001 11:55:26 +0200 (MEST)
Received: from home.ds9a.nl (20dyn107.com21.casema.net [213.17.90.107]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with SMTP id f4U9tOLt019353 for <dnsop@cafax.se>; Wed, 30 May 2001 11:55:25 +0200 (MEST)
Received: (qmail 5674 invoked by uid 500); 30 May 2001 09:54:42 -0000
Date: Wed, 30 May 2001 11:54:42 +0200
From: bert hubert <ahu@ds9a.nl>
To: dnsop@cafax.se
Subject: Re: Should a nameserver know about itself?
Message-ID: <20010530115442.E5236@home.ds9a.nl>
Mail-Followup-To: bert hubert <ahu@ds9a.nl>, dnsop@cafax.se
References: <20010529232301.5659.qmail@cr.yp.to> <Pine.BSI.4.05L.10105301102430.8181-100000@x17.ripe.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSI.4.05L.10105301102430.8181-100000@x17.ripe.net>; from shane@ripe.net on Wed, May 30, 2001 at 11:03:36AM +0200
Sender: owner-dnsop@cafax.se
Precedence: bulk

On Wed, May 30, 2001 at 11:03:36AM +0200, Shane Kerr wrote:

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

Automation is the key word here. 

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

Well, it sets policy where it is often not expected. In an age where reverse
delegation is considered less and less important (many administrators do not
even know how it is set up - 'why doesn't it work out of the box'), we
should wonder if IN-ADDR.ARPA delegation should be made more difficult than
it currently is.

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

Well, 'The internet at large' often does not know what is broken. People
generally feel that 'stuff is not quite working as it should', without being
able to blame it on a single issue, like numerous compounded out-of-bailiwick
references causing 'rickety' dns service.

This ignorance about the reasons for bad 'surfing experience' leads to
little or no feedback - I did some experiments with a friend (Remco van
Mook) on three reputable networks (Surfnet, UUnet and Level(3)) and we found
that dns queries are very often answered late enough that the recursing
nameserver has already decided to move on to the next NS record.

Having a lot of out-of-bailiwick references then becomes a major issue in
delaying lookups. But imho, this is more important for forward lookups.

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet