ipv6 reverse dns not working unless +trace is specified

Question

I'm trying to set up reverse dns for ipv6 in my lan. The dns server which should be delegated is at 2001:5c0:1400:b::9 and an host for which RDNS should work is at 2001:5c0:1500:300::1. The problem is, dig -x doesn't seem to work unless +trace is specified:

$ dig -x 2001:5c0:1500:300::1

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 2001:5c0:1500:300::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24545
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. IN PTR

;; Query time: 714 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sun Oct 19 23:31:58 CEST 2014
;; MSG SIZE  rcvd: 101


$ dig -x 2001:5c0:1500:300::1 +trace

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 2001:5c0:1500:300::1 +trace                                                                                      
;; global options: +cmd                                                                                                                            
.                       433182  IN      NS      l.root-servers.net.                                                                                
.                       433182  IN      NS      a.root-servers.net.                                                                                
.                       433182  IN      NS      f.root-servers.net.
.                       433182  IN      NS      c.root-servers.net.
.                       433182  IN      NS      h.root-servers.net.
.                       433182  IN      NS      i.root-servers.net.
.                       433182  IN      NS      g.root-servers.net.
.                       433182  IN      NS      e.root-servers.net.
.                       433182  IN      NS      b.root-servers.net.
.                       433182  IN      NS      j.root-servers.net.
.                       433182  IN      NS      k.root-servers.net.
.                       433182  IN      NS      d.root-servers.net.
.                       433182  IN      NS      m.root-servers.net.
.                       435889  IN      RRSIG   NS 8 0 518400 20141025170000 20141018160000 22603 . kvgfN/rC3esMrbGF3KZFrwogm1EKA+nwZrFMXHf3a9sJsDZdpe4iDrOB 0xKyu9dvcsdfLcVLDMHGojlQqUAOda9KIcOGIdeFXl3IOKAk91XvQfrq mLOz02vrBog6gfFnzA34lGkLan1BtRFqKkjxvIHUyIcxstZkak44p/2/ t1w=
;; Received 913 bytes from 192.168.0.1#53(192.168.0.1) in 369 ms

ip6.arpa.               172800  IN      NS      d.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      b.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      c.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      e.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      f.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      a.ip6-servers.arpa.
ip6.arpa.               86400   IN      DS      13880 8 2 068554EFCB5861F42AF93EF8E79C442A86C16FC5652E6B6D2419ED52 7F344D17
ip6.arpa.               86400   IN      RRSIG   DS 8 2 86400 20141026190000 20141019180000 10069 arpa. oRqujHjYlEPu3LNM61WtGMXvMyXYYxvBnTPxYLhZxs3rZxqLNaqmzMQr 5cGjUBoEPbAQSsSvpXBX/VHKRf0FjcpL1kXt6YcmzwMyMKdlQrC9Rrxz AQd1csbsfpJP6E6AwWz3Vbd/AnsghIk+BRKerC2+DxjCxU8UpV9ae/3v R0o=
;; Received 685 bytes from 192.33.4.12#53(c.root-servers.net) in 77 ms

1.0.c.5.0.1.0.0.2.ip6.arpa. 86400 IN    NS      ns2.gogo6.com.
1.0.c.5.0.1.0.0.2.ip6.arpa. 86400 IN    NS      ns1.gogo6.com.
1.0.c.5.0.1.0.0.2.ip6.arpa. 10800 IN    NSEC    8.c.5.0.1.0.0.2.ip6.arpa. NS RRSIG NSEC
1.0.c.5.0.1.0.0.2.ip6.arpa. 10800 IN    RRSIG   NSEC 5 11 10800 20141102202721 20141019192721 49851 5.0.1.0.0.2.ip6.arpa. GVMC0TF/hNZGCCRXY4bvpvuyqtmqC5mqhVp0DGhxldJ0m64CVzmOcFMf S3aqoggYRPMYqHNKG4Zjg40/IlwXSdsLmTmOQgBu0OBR4tJBGuomqoTP 7BsXeKx0a3Vgz/8mdz1Nf8e4czGWwkCAo/AomluyWKdEDM5bQiX30Uqa e0k=
;; Received 372 bytes from 2001:dc0:2001:a:4608::59#53(e.ip6-servers.arpa) in 373 ms

3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. 3600 IN NS wonderland.broker.freenet6.net.
;; Received 173 bytes from 72.55.143.215#53(ns1.gogo6.com) in 125 ms

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. 3600 IN PTR wonderland.broker.freenet6.net.
;; Received 128 bytes from 2001:5c0:1400:b::9#53(wonderland.broker.freenet6.net) in 0 ms

I also tried online tools like http://www.sput.nl/internet/ipv6/chkip6rev.html and indeed they report a SERVFAIL. I waited a day to see if this was the effect of some caching, but the problem persists. What may be going on here?

Tracing the delegation fails early on, check using an online tool like: JH Software [Trace DNS Delegation](http://www.simpledns.com/lookup-dg.aspx) — Brian, Oct 19 '14 at 22:14
I tried this tool, but it seems to fail just because the dns server is reachable only through ipv6 ("An address incompatible with the requested protocol was used") and it tries to connect using ipv4 — Alberto, Oct 19 '14 at 22:19

Sander Steffann · Accepted Answer · 2014-10-20T18:18:55.147

It will fail for certain DNS resolvers at this delegation:

3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa. 3600 IN NS wonderland.broker.freenet6.net.

DNS server wonderland.broker.freenet6.net only has an IPv6 address:

$ host wonderland.broker.freenet6.net
wonderland.broker.freenet6.net has IPv6 address 2001:5c0:1400:b::9

When you do dig then you are asking your configured DNS resolver to resolve the address for you. If that resolver doesn't have IPv6 then it will not be able to follow this delegation because it can't reach the IPv6-only DNS server. When you do dig +trace then you do all the resolving yourself. If your system has IPv6 then it can follow the whole chain. On a system without IPv6 the resolving would fail as well.

In this case the problem (also?) seems related to a bug in the authoritative DNS server at 2001:5c0:1400:b::9. The answer it sends does not comply to the DNS standard. According to RFC 1034 the original question must be included in the response. Your DNS server however sends an empty Question section (which BIND reports as "too many questions", although technically it is "not enough questions", matching on != 1 I guess):

Domain Name System (response)
  Transaction ID: 0xad20
  Flags: 0x8400 Standard query response, No error
  Questions: 0
  Answer RRs: 1
  Authority RRs: 0
  Additional RRs: 0
  Answers
    1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa:
                           type PTR, class IN, wonderland.broker.freenet6.net

So basically your authoritative DNS server is broken, and dig doesn't care but 'real' DNS resolvers do...

ok, but then why does it fail also using google and opendns ipv6 server (`dig @2001:4860:4860::8888 -x 2001:5c0:1500:300::1` and `dig @2620:0:ccc::2 -x 2001:5c0:1500:300::1`)? — Alberto, Oct 20 '14 at 17:19
On my local resolver I'm seeing `named[1056]: DNS format error from 2001:5c0:1400:b::9#53 resolving 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.5.1.0.c.5.0.1.0.0.2.ip6.arpa/PTR for client 127.0.0.1#52975: too many questions`. Checking pcap files now... — Sander Steffann, Oct 20 '14 at 17:32
Didn't know bind was so pedantic about the spec... should be fixed now! — Alberto, Oct 20 '14 at 19:31

ipv6 reverse dns not working unless +trace is specified

1 Answers1