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

[Arth Paulite]

Thanks Mike and Chris,

All nodes in e.in-addr-servers.arpa anycast will now give consistent 
response: NXDOMAIN for 1.0.0.127.in-addr.arpa  PTR.

regards,

--
Arth Paulite
APNIC - Infrastructure Services


On 23/08/2011 01:51, Chris Thompson wrote:
> 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.
>