There's an item on the agenda that I'd like to potentially add to... # H. Using In-Bailiwick Nameservers in .ARPA: # Improving Reverse DNS Lookup Performance # Masato Minda, JPRS # # In June 2004, the JP TLD carried out a change in handling of the way glue # records. Although this change was technically correct, some domains # encountered difficulties in name resolution. # # This presentation explains the problem with old BIND implementations and # suggests recommended way to configure nameservers in .ARPA domain. This # configuration of DNS will improve reverse DNS lookup performance. I have seen this presentation in January at a NANOG (or at least an earlier version of it) and commented then that there is some good reason for this, even if it costs the RIRs the need to support glue data. For one - it makes the reverse map lookup path a bit more direct. However, the benefit isn't overwhelming because of short cuts taken when looking up the "slash-8".in-addr.arpa zones. E.g., if you tcpdump the DNS queries from an empty caching server, you might see this when you omit repeated queries, formerr's, etc: dig +norec -x 209.173.57.182 @l.root-servers.net dig +norec chia.arin.net @i.root-servers.net dig +norec chia.arin.net @i.gtld-servers.net The first is the query, with a referral to the 209.in-addr.arpa zone. The second is the attempt to get the address for chia, one of the servers. The third is a query to .net, and you get back a hybrid answer... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8051 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8 ;; QUESTION SECTION: ;chia.arin.net. IN A ;; ANSWER SECTION: chia.arin.net. 172800 IN A 192.5.6.32 ;; AUTHORITY SECTION: the rest is a normal referral... This is a good crutch - and is a counter to "in-baliwick" server requirements. This crutch comes at a price though - the A record here is obtained from the host objects registered, not via DNS. (It looks like a cached answer, but it's not really.) That's all good, no "flash point problem." Until we get to DNSSEC though. This answer will be RRSIG-less. I suspect that this might become an issue. Maybe? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.