[talk] NSD and reverse zone files

[Patrik Lundin]

On Thu, Jun 30, 2016 at 11:24:25PM +0000, Mark Saad wrote:
> All
>  So Here is the unbound config.
> 
> http://pastebin.com/qwUcM7XD
> I tried a few iterations of this but still I get no reply from nsd
> 

After playing around with your config I think I have tracked down your
problem: The combination of DNSSEC validation and the forward-zone
statament for ".":
===
forward-zone:
    name: "."
    forward-addr: 8.8.4.4
===

unbound attempts to validate the 168.192.in-addr.arpa zone, which fails
when asking the Google recursive service because the answer it sends
does not contain the signed NSEC record necessary. The result of insecure
DNSSEC is SERVFAIL which explains what you are seeing.

Compare the output of asking for a DS record towards a server
authoritative for 192.in-addr.arpa (z.arin.net) and the 8.8.4.4 server:

===
$ dig +dnssec @z.arin.net 168.192.in-addr.arpa DS

; <<>> DiG 9.4.2-P2 <<>> +dnssec @z.arin.net 168.192.in-addr.arpa DS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7545
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;168.192.in-addr.arpa.          IN      DS

;; AUTHORITY SECTION:
192.in-addr.arpa.       10800   IN      SOA     z.arin.net. dns-ops.arin.net. 2016031872 1800 900 691200 10800
192.in-addr.arpa.       10800   IN      RRSIG   SOA 5 3 86400 20160715163218 20160701153218 57162 192.in-addr.arpa. s8EDRm7pHD4HNvTzpOdp0+JyKGEJ2w5HzgHmAfHZooCS0dKd5G0pKvPT U6kTjTOpkcUF4r1vePcCYCqt/+tEt3W+8UiCz5HoWB1ZEKqs/4Fwebsg aCgejp1bSCJ8dCfYtkHwx+R8nXJHm9Jks5HpKcUVE++7D9YPS/6sekXh v8c=
168.192.in-addr.arpa.   10800   IN      NSEC    0.169.192.in-addr.arpa. NS RRSIG NSEC
168.192.in-addr.arpa.   10800   IN      RRSIG   NSEC 5 4 10800 20160715163218 20160701153218 57162 192.in-addr.arpa. HhScKFNyeJbb0bF1iA28mOKkvkiKhDJ31LhCVS1YwK1l3tWxBBoVsvZi nQWo0T9++LMKJ+Ku0q46MeF3LQq9RBDyE8OQp14B4ZEScjdGj3P16NJa WIDyHTzolwU/Ddn6r98IwjMDe+DBAHpQ5WbaViCIVeo0PS7htmpFOJj1 4wo=

;; Query time: 114 msec
;; SERVER: 199.212.0.63#53(199.212.0.63)
;; WHEN: Fri Jul  1 19:14:08 2016
;; MSG SIZE  rcvd: 499
===

===
$ dig +dnssec @8.8.4.4 168.192.in-addr.arpa DS

; <<>> DiG 9.4.2-P2 <<>> +dnssec @8.8.4.4 168.192.in-addr.arpa DS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54545
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;168.192.in-addr.arpa.          IN      DS

;; Query time: 2 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Jul  1 19:14:47 2016
;; MSG SIZE  rcvd: 49
===

Running unbound in debug mode (-d) with the forward-zone results in this message:
===
[1467392180] unbound[8069:0] info: Could not establish a chain of trust to keys for 168.192.in-addr.arpa. DNSKEY IN
===

Removing the forward-zone makes it look like this:
===
[1467392798] unbound[20823:0] info: NSEC RRset for the referral proved no DS.
===

If you want to keep the forward-zone statement your best bet to solve this is
probably to add this:
===
domain-insecure: 168.192.in-addr.arpa
===

Even if you decide to remove the forward-zone it might still be a good
idea to add the domain-insecure line, because it removes the extra work needed
by unbound (which actually introduces a small delay in an initial lookup of a
name) to check that the zone is insecure.

Since the RFC1918 zones can never be DNSSEC-delegated from the root this work
is unnecessary anyway unless you decide to add your own trust anchors.

-- 
Patrik Lundin