[dns-wg] WG Agenda for RIPE50

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.