I watch this thread with great interest, initially I was
quite adamant that glue should _never_ be seen in the
in-addr.arpa. However...
On 09/03/2005, at 2:54 AM, Edward Lewis wrote:
At 11:20 +0100 3/8/05, Bruce Campbell wrote:
From a Registry POV, allowing in-bailiwick glue adds the requirement
of
keeping track of the IP addresses used; whilst it is clearly the
responsibility of the child to keep the parent informed about changes,
most people simple do not think about these things until breakage
occurs,
with the finger of blame being pointed at the parent for not
supporting
the do-what-I-want-not-what-I-say interface correctly.
It's true that the RIR's don't have to worry about glue maintenance,
don't fret - the registrants already do. ;) The glue is somewhere...
Whilst the concept of glue records in the in-addr.arpa tree
goes against the pragmatic interpretation of the current RFC,
I don't see that it would be a huge stretch of resources for
this RIR to approach the issue of glue administration provided
that the proposal to do so was presented and accepted at the
APNIC dns-sig outlining the issues of migration, acceptance,
zone file growth, signed zone growth (and most other
stumbling blocks).
I don't mean to push for the RIR's to maintain glue, just to point out
that if they do, it isn't "new pain" just "moved pain." ;)
The downside of the RIR's not maintaining glue is an arguable
(arguable) performance hit of having an iterating name server chase
down so many name server addresses (independent of old BIND problems).
Also, because of old BIND, .net servers (where most of the /8 in-addr
name servers are) have to give out "extra glue" because old BIND got
"lost" on the way. ("Old" BIND.)
While I agree that the old bind aspect is an issue, for me the
larger benefits are about reduction in root traversal as
outlined in Fujiwara-san's presentation. Having the resolver go
back to the root 3 or more times to find the non-cached A
records for the NS RRs certainly appears laboured.
Additionally I can also see that from a top wise approach having
glue in the in-addr.arpa tree means that there is a potential
for arpa to be self consistent removing the reliance on the
.net hierarchy for the initial /8 delegations and then the
same follow-on effects in ccTLD/gTLD space for subsequent
delegations to resource holders.
Also, should ip6.arpa delations take hold, having glue in-situ
will probably reduce any adverse scaling effects on performace.
As for the world of lame, and the current APNIC
policy of un-delegating the lame - APNIC might
need to take a fresh look at the way we do things..
(Though I don't think the work there is ground breaking)
If the current RFC is a blocking factor here, I would
be quite happy to work on the draft to see a change.
Terry
--
Terry Manderson APNIC Secretariat
[EMAIL PROTECTED] http://www.apnic.net
tel: +61 7 3858 3100 fax: +61 7 3858 3199
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
