[dns-operations] 127.in-addr.arpa zone

[Chris Thompson]

On Aug 21 2011, Mike Jones wrote:

>I doubt it causes any operational issues anywhere with this specific
>zone, but I was testing a diagnostic tool i was working on and did a
>PTR lookup on 1.0.0.127.in-addr.arpa and noticed the following:
>
>a.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with a PTR
>record for 1.0.0.127.in-addr.arpa. resolving as "localhost"
>d.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with NXDOMAIN
>for 1.0.0.127.in-addr.arpa.
>e.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with a PTR
>record for 1.0.0.127.in-addr.arpa. resolving as "localhost" on IPv6,
>and NXDOMAIN under in-addr.arpa. on IPv4 (hu?)
>the other in-addr servers are all returning NXDOMAIN under the
>in-addr.arpa. zone

I confirm that from here, except for e.in-addr-servers.arpa over
IPv6, which is giving me NXDOMAIN under in-addr.arpa.

>The IPv4/IPv6 differences observed on E also leave open the
>possibility that different anycast nodes under the same address may be
>configured differently. For the record my IPv4 queries to E go to
>au-anysec1.apnic.net and IPv6 to hk-anysec2.apnic.net.

I am getting hk-anysec1.apnic.net with either protocol. 

>I also had a look at
>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
>and get NXDOMAIN from all servers except e.ip6-servers.arpa which
>responds with localhost (on both IPv4 and IPv6). 

I confirm that as well. It has a locally defined zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
(i.e. all the components above the "1").

>Anyone know if there's any reason for the inconsistency, or just
>something nobody has really thought about and they just did whatever
>when setting up the servers?

I would take a bet that it's the latter!

>                             I had actually assumed 127.in-addr.arpa
>would have been delegated to the AS112 servers but I guess it doesn't
>see the same kind of traffic due to most hosts already having a
>localhost entry in their hosts file.

There has been talk on dnsop at ietf.org about delegating all the 
RFC6303 zones to the AS112 servers, but it's only talk so far.

But to revert to your initial implied question - could it cause
operational problems? Most recursive servers will either have
their own zones defined to reverse lookup 127.0.0.1, or have
something like BIND's automatic empty zone for 127.in-addr.arpa,

But what if they don't? (I experimented with such a setup.)
Without DNSSEC validation, they will just get inconsistent
results depending on which *.in-addr-servers.arpa they ask.
But if they do have DNSSEC validation turned on, the answers
that say "localhost" will fail to validate, there being no
(provably unsigned) delegation to the supposed zone containing
it. As long as there are some (accessible) servers that don't
do that, though, the recursive server should be able to find
one, and generate a validated NXDOMAIN. e,g,

$ dig +dnssec +multi -x 127.0.0.1

; <<>> DiG 9.8.1rc1 <<>> +dnssec +multi -x 127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2875
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.        IN PTR

;; AUTHORITY SECTION:
126.in-addr.arpa.       3600 IN RRSIG NSEC 8 3 3600 20110829203412 (
                                20110822143225 62655 in-addr.arpa.
                                GIyJqvEVKXHK0jjYEB+cRYqiuy02uDMmcD9xuTX0dOYI
                                V20CCjD1xLQn3vmO4GxohxYJK6380dAIhRRzm8yCHdqO
                                TZLij2F78kOZ8pFcXYS01p1ZxO+TqFVv5HMuxPyiKVyq
                                MGisgFv11cBqXi1AvniDqC7iRzp24J3GWg80d3s= )
126.in-addr.arpa.       3600 IN NSEC 128.in-addr.arpa. NS RRSIG NSEC
in-addr.arpa.           3600 IN SOA b.in-addr-servers.arpa. nstld.iana.org. (
                                2011023400 ; serial
                                1800       ; refresh (30 minutes)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
in-addr.arpa.           3600 IN RRSIG SOA 8 2 3600 20110829205849 (
                                20110822143225 62655 in-addr.arpa.
                                J+xSxElRnMfzD49iLstFwoguB8gAw+OVkx4QwkSfOxxT
                                Sv6JOGlpkNoXCzDs7kG8RUVYVvQL5Lz277vJvqNM40+J
                                OQ5eY+exrIgWecfyFxIrizrSiDMqYp+W1X2x2k9YsyAa
                                K8ap3ezCp2kYGycpdmo017KrhFiKfIceGtFgEjw= )
in-addr.arpa.           3600 IN RRSIG NSEC 8 2 3600 20110829223141 (
                                20110822143225 62655 in-addr.arpa.
                                cefqmfteHZHTK4YO51NaGdo25STXfR0AB3HrIluWrLXi
                                CcJq9lglK1rEOTvMfeb+1zPqYQfZy3Kgu1LkSqC9WH6z
                                S92xBTxih91bR4zpTIveUYaIZaFvZj6UDn/ttyZxP3nW
                                1rgaslvlRlvCGB2zJjD+eXtPJPMkzmVQonTNQoc= )
in-addr.arpa.           3600 IN NSEC 1.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 22 16:49:15 2011
;; MSG SIZE  rcvd: 714

(Note the "ad" flag.)

Regardless, it's a messy situation, and I think it would probably be
a good idea for ICANN to issue some guidance to the RIRs operating the
in-addr-servers and ip6-servers about it.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.