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

Chris Thompson cet1 at cam.ac.uk
Mon Aug 22 15:51:17 UTC 2011

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 and noticed the following:
>a.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with a PTR
>record for resolving as "localhost"
>d.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with NXDOMAIN
>e.in-addr-servers.arpa. is serving 0.0.127.in-addr.arpa. with a PTR
>record for 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
>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
(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, 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

; <<>> DiG 9.8.1rc1 <<>> +dnssec +multi -x
;; 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

; EDNS: version: 0, flags: do; udp: 4096
;        IN PTR

126.in-addr.arpa.       3600 IN RRSIG NSEC 8 3 3600 20110829203412 (
                                20110822143225 62655 in-addr.arpa.
                                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.
                                K8ap3ezCp2kYGycpdmo017KrhFiKfIceGtFgEjw= )
in-addr.arpa.           3600 IN RRSIG NSEC 8 2 3600 20110829223141 (
                                20110822143225 62655 in-addr.arpa.
                                1rgaslvlRlvCGB2zJjD+eXtPJPMkzmVQonTNQoc= )
in-addr.arpa.           3600 IN NSEC 1.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY

;; Query time: 13 msec
;; 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.

More information about the dns-operations mailing list