[talk] NSD and reverse zone files

[Mark Saad]

Patrik 
  Wow now that I look at what I did ; I can't believe how obvious that mistake looks .  Fix that later tonight and see how it works .  

---
Mark Saad | mark.saad at ymail.com

> On Jul 1, 2016, at 1:29 PM, Patrik Lundin <patrik at sigterm.se> wrote:
> 
>> 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