Re: Should a nameserver know about itself?

[Shane Kerr <[e-mail]>]

On Thu, 31 May 2001, Robert Elz wrote:

>   | 	RIR automagically keeps track of IP address changes applicable to
>   | 	nameservers referenced as glue
> 
> That's the one I'd like.  In any random forward domain, that's
> probably unsupportable.  In the in-addr.arpa tree, it is perhaps
> almost reasonable to do that.
> 
> Recall we're only talking about necessary glue - not just any random
> A record for any random nameserver that someone happens to dump on
> you.
> 
> If I request an in-addr.arpa delegation to munnari.oz.au and supply
> you with munnari's current IP addresses, you should simply trash
> those (ignore them - regardless of what I tell you, I really *don't*
> want you listing A records for munnari in your servers, even if I
> don't know that I don't want that, really, I don't...)

But I suspect this is exactly what Bruce is suggesting!  And to be
honest, I think what most network administrators would expect.  Not that
I know most network administrators....

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.

A scan by each RIR, perhaps based on one of the TTL values in the SOA
record with a reasonable minimum refresh time (wouldn't want to query
NEC.COM every 2 hours, for instance) could probably achieve the goal of
inserting glue records, although not in the way that the
ns.x.y.z.in-addr.arpa A record fans want.  :)

This would also have the side benefit of being a nice reference for
broken delegations, in case the Internet community wanted to pursue
more proactive means of improving in-addr.arpa delegation.

> On the other hand, if I apply for in-addr.arpa delegation of
> 1.168.192.in-addr.arpa and list ns.1.168.192.in-addr.arpa as the
> nameserver and give you its A record, then that is necessary glue,
> and you have to list it for the delegation to work.  Your only other
> option is to refuse to do the delegation on the grounds that you
> don't like the name of my nameserver - and that is not really
> acceptable.
> 
> Keeping track of those A records (since chances are that you'll only
> see a handful, if that, a year) shouldn't be too hard - though for
> it to work relies on the set of nameservers for the zone not all
> changing addresses at the same time.  That ought to be an
> operational requirement for any set of nameservers for a zone - but
> we know how seriously people take those kinds of requirements...

This is probably so for a large number of cases, but not true for ISP's
that have lots of disjoint IP space.  True, they won't have to update
the information very often once correct, but every time they buy a
smaller ISP they're going to have to worry about not only integrating
the different infrastructure into their own, but also now changing a set
of records in one or more RIR databases to use their preferred name
servers.

There is also the issue of educating administrators on this methodology,
which isn't the way that most forward delegation is carried out (e.g.
one of nominum.com's name servers is ns-ext.vix.com, which doesn't fit
in the "use only name servers in the domain to respond authoritatively
for that domain" model.

Does anyone who administers a lot of IP space have strong feelings on
this issue?

Shane