To:
Bruce Campbell <bruce.campbell@apnic.net>
cc:
dnsop@cafax.se
From:
Robert Elz <kre@munnari.OZ.AU>
Date:
Thu, 31 May 2001 14:13:54 +0700
In-Reply-To:
<Pine.BSF.4.21.0105310930110.58053-100000@julubu.staff.apnic.net>
Sender:
owner-dnsop@cafax.se
Subject:
Re: Should a nameserver know about itself?
Date: Thu, 31 May 2001 09:44:33 +1000 (EST) From: Bruce Campbell <bruce.campbell@apnic.net> Message-ID: <Pine.BSF.4.21.0105310930110.58053-100000@julubu.staff.apnic.net> | 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