Hi, I am unable to resolve the reverse DNS records for addresses in my subnet 2a00:14f0:e01d::/48 (R32713 on tunnel T72649, NIC handle MALC-RIPE) using any installation of BIND as a DNSSEC-validating recursive resolver. It seems to have a problem with the DNSSEC signatures somewhere in the delegation chain. Attempt to resolve via DNSSEC-validating BIND 9.9.1-vjs197.15-P2 resolver on 127.0.0.1: $ dig -x 2a00:14f0:e01d:0:60f1:54ff:fe0b:ef7f @127.0.0.1 ; <<>> DiG 9.9.1-vjs197.15-P2 <<>> -x 2a00:14f0:e01d:0:60f1:54ff:fe0b:ef7f @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53189 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa. IN PTR ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 4 17:21:29 2012 ;; MSG SIZE rcvd: 101 The same query with DNSSEC validation turned off (+cd): $ dig -x 2a00:14f0:e01d:0:60f1:54ff:fe0b:ef7f @127.0.0.1 +cd ; <<>> DiG 9.9.1-vjs197.15-P2 <<>> -x 2a00:14f0:e01d:0:60f1:54ff:fe0b:ef7f @127.0.0.1 +cd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61523 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa. IN PTR ;; ANSWER SECTION: f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa. 14379 IN PTR bebhionn.retrosnub.co.uk. ;; AUTHORITY SECTION: d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa. 14103 IN NS ns1.retrosnub.co.uk. d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa. 14103 IN NS ns0.retrosnub.co.uk. ;; ADDITIONAL SECTION: ns0.retrosnub.co.uk. 172503 IN A 178.18.118.26 ns0.retrosnub.co.uk. 172503 IN AAAA 2001:470:9321:f003:bc9d:1dff:fe9b:7466 ns1.retrosnub.co.uk. 172503 IN A 217.168.153.95 ns1.retrosnub.co.uk. 172503 IN AAAA 2a00:14f0:e01d::ff:fe00:1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 4 17:21:50 2012 ;; MSG SIZE rcvd: 263 The BIND logs from a failed query: Sep 4 17:16:54 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/ DS/IN': 2001:7e8:1:102::a#53 Sep 4 17:16:54 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/ DS/IN': 193.1.31.74#53 Sep 4 17:16:54 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/DS/IN': 38.229.76.3#53 Sep 4 17:16:54 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/DS/IN': 78.141.179.38#53 Sep 4 17:16:54 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/DS/IN': 2001:770:18:8::4#53 Sep 4 17:16:55 betelgeuse named[18707]: error (no valid RRSIG) resolving '1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/DS/IN': 2620:0:6b0:a:250:56ff:fe99:78f7#53 Sep 4 17:16:55 betelgeuse named[18707]: error (no valid DS) resolving 'f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/PTR/IN': 2001:470:9321:f003:bc9d:1dff:fe9b:7466#53 Sep 4 17:16:55 betelgeuse named[18707]: validating @0x7f209401b970: f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa PTR: bad cache hit (1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/DS) Sep 4 17:16:55 betelgeuse named[18707]: error (broken trust chain) resolving 'f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa/PTR/IN': 217.168.153.95#53 My zone d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa is not signed, which shouldn't in itself cause this problem. Indeed the problem also occurs if I query a name outside my zone, e.g. dig -x 2a00:14f0:e000:5b::1 . There is however a break in the trust chain as shown at http://dnssec-debugger.verisignlabs.com/f.7.f.e.b.0.e.f.f.f.4.5.1.f.0.6.0.0.0.0.d.1.0.e.0.f.4.1.0.0.a.2.ip6.arpa -- perhaps if 0.f.4.1.0.0.a.2.ip6.arpa (Gyron's zone) is not yet signed, then 0.e.0.f.4.1.0.0.a.2.ip6.arpa (SixXS's zone) should remain unsigned too? Or perhaps this is a BIND bug? Thanks, Malcolm Scott