Re: Should a nameserver know about itself?

[Robert Elz <[e-mail]>]

    Date:        Thu, 31 May 2001 09:44:33 +1000 (EST)
    From:        Bruce Campbell <[e-mail]>
    Message-ID:  <[e-mail]>


  | Then (taking into account the RIR's previous experience with glue records
  | and the resounding lack of people caring about the reverse tree etc), what
  | would be the 'best' way of doing this?

  | 	Nameserver IPs collected at time of request, onus on
  | 	client/requestor to ensure that they are kept up to date.

That's the easy way of course.

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

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

kre