[dns-operations] I missed the announcement: .ARPA has been deleted

Chris Thompson cet1 at cam.ac.uk
Fri Feb 12 17:06:32 UTC 2010


On Feb 12 2010, David Blacka wrote:

>
>On Feb 12, 2010, at 9:57 AM, Stephane Bortzmeyer wrote:
>
>> At least, this is what Google Public DNS says:
>> 
>> % dig @8.8.8.8 NS arpa.
>> 
>> ; <<>> DiG 9.5.1-P3 <<>> @8.8.8.8 NS arpa.
>> ; (1 server found)
>> ;; global options:  printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48111
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;arpa.				IN	NS
>> 
>> ;; AUTHORITY SECTION:
>> arpa.			14387	IN	SOA	A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010021100 1800 900 604800 86400
>> 
>> ;; Query time: 17 msec
>> ;; SERVER: 8.8.8.8#53(8.8.8.8)
>> ;; WHEN: Fri Feb 12 15:54:17 2010
>> ;; MSG SIZE  rcvd: 109
>> 
>> 
>> Other TLDs are fine :-)
>
>Yet things below .arpa exist:
>
>% dig @8.8.8.8 NS ip6.arpa.
>
>; <<>> DiG 9.6.0-P1 <<>> @8.8.8.8 NS ip6.arpa.
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28568
>;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;ip6.arpa.			IN	NS
>
>;; ANSWER SECTION:
>ip6.arpa.		66811	IN	NS	ns-sec.ripe.net.
>ip6.arpa.		66811	IN	NS	tinnie.arin.net.
>ip6.arpa.		66811	IN	NS	ns.icann.org.
>ip6.arpa.		66811	IN	NS	sec1.apnic.net.
>ip6.arpa.		66811	IN	NS	ns2.lacnic.net.
>
>;; Query time: 36 msec
>;; SERVER: 8.8.8.8#53(8.8.8.8)
>;; WHEN: Fri Feb 12 10:16:18 2010
>;; MSG SIZE  rcvd: 157
>
>That is unpossible!

Confirm all that.

Queries for the SOA record work OK, and queries for "any" shows the
NS records for "arpa" are actually being cached there:

$ dig any arpa. @8.8.8.8

; <<>> DiG 9.7.0rc2 <<>> any arpa. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33921
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;arpa.                          IN      ANY

;; ANSWER SECTION:
arpa.                   86163   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010021200 1800 900 604800 86400
arpa.                   86163   IN      NS      K.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      B.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      H.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      E.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      A.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      M.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      D.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      F.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      C.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      I.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      G.ROOT-SERVERS.NET.
arpa.                   86163   IN      NS      L.ROOT-SERVERS.NET.

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 12 16:54:35 2010
;; MSG SIZE  rcvd: 288

What an interesting bug ... do we know whether it was there ab initio?

The results for

  dig soa . @8.8.8.8
  dig ns . @8.8.8.8
  dig any . @8.8.8.8

show the data in the last with quite different TTLs (but each
set decreasing properly in real time). That suggests a quite
different caching policy for "any" request results than we are
used to.

-- 
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