Maintained by: NLnet Labs

Unbound 1.6.4/1.6.5: Unexpected AD=0 for signed NODATA at zone apex?

W.C.A. Wijngaards
Thu Aug 24 17:28:28 CEST 2017


Hi Viktor,

This is what verbosity 4 tells me:
[1503588441] libunbound[20640:0] info: verify rrset pat.dedyn.io. SOA IN
[1503588441] libunbound[20640:0] debug: verify sig 16713 8
[1503588441] libunbound[20640:0] debug: verify result: sec_status_secure
[1503588441] libunbound[20640:0] info: verify rrset
3645142tqk02bkonalf8lhipr7bs92k2.pat.dedyn.io. NSEC3 IN
[1503588441] libunbound[20640:0] debug: verify sig 16713 8
[1503588441] libunbound[20640:0] debug: verify result: sec_status_secure
[1503588441] libunbound[20640:0] debug: Validating a nodata response
[1503588441] libunbound[20640:0] debug: nsec3: keysize 1024 bits, max
iterations 150
[1503588441] libunbound[20640:0] debug: NODATA response is insecure
[1503588441] libunbound[20640:0] info: validate(nodata): sec_status_insecure

So I guess the max iterations of 300 is a bit too much.

Best regards, Wouter

On 24/08/17 16:42, Viktor Dukhovni via Unbound-users wrote:
> 
> I had unbound 1.6.4 listening on the loopback interface with
> validation enabled.  Unexpectedly, for a DNSSEC signed zone
> with no MX records, the NODATA response from unbound has AD=0:
> 
> $ dig +nosplit +dnssec +ad -t mx pat.dedyn.io @127.0.0.1
> 
> ; <<>> DiG 9.11.1-P3 <<>> +nosplit +dnssec +ad -t mx pat.dedyn.io @127.0.0.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46584
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 8192
> ;; QUESTION SECTION:
> ;pat.dedyn.io.                  IN      MX
> 
> ;; AUTHORITY SECTION:
> pat.dedyn.io.           60      IN      SOA     ns1.desec.io. hostmaster.desec.io. 2017084887 10800 3600 604800 60
> pat.dedyn.io.           60      IN      RRSIG   SOA 8 3 60 20170907000000 20170817000000 16713 pat.dedyn.io. ICHfyC1jcmI7hk/qcvs1mHU+DXgiAHp56tHZ0DrBIlg8Qrzj9MI8stHcWT6J7mf4e+3PMN+p34RvFokGAMqeHQ2qN4QSe1yX+Evj5RCI6Gx125ae/S0xCSnUuz4tfcmuorn+Ljk//2a8j2q+w6awrCqdoAMaVAdIMmHmmuHKhpQ=
> 3645142tqk02bkonalf8lhipr7bs92k2.pat.dedyn.io. 60 IN NSEC3 1 0 300 D7E2042737B912B9 4O4UISQPPPTC260I5BQ6R816IC02HFI5  A NS SOA RRSIG DNSKEY NSEC3PARAM
> 3645142tqk02bkonalf8lhipr7bs92k2.pat.dedyn.io. 60 IN RRSIG NSEC3 8 4 60 20170907000000 20170817000000 16713 pat.dedyn.io. ZkcJecwn698jOHCFN+Fn6Z3qGTZuIzVo0W25cLG6NB0DCnMdVhmD2FpWvaIT8OVWIyMSxdbC99T4pvSkdZakZWRfeJNeomwrWvbYGkGNgo/3uoQRfvm5WgTHjmoYP9QopEKpra5L2Dm8l4fQagp+BBos48QNlKeABqTkiufLEts=
> 
> ;; Query time: 46 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Aug 24 10:26:18 EDT 2017
> ;; MSG SIZE  rcvd: 530
> 
> Both DNSViz and Google's public resolvers report the NODATA as secure (AD=1):
> 
>     http://dnsviz.net/d/pat.dedyn.io/dnssec/?rr=15&a=all&ds=all&doe=on&ta=.&tk=
> 
> $ dig +nosplit +dnssec +ad -t mx pat.dedyn.io @8.8.4.4
> 
> ; <<>> DiG 9.11.1-P3 <<>> +nosplit +dnssec +ad -t mx pat.dedyn.io @8.8.4.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5148
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;pat.dedyn.io.                  IN      MX
> 
> ;; AUTHORITY SECTION:
> pat.dedyn.io.           59      IN      SOA     ns1.desec.io. hostmaster.desec.io. 2017084887 10800 3600 604800 60
> pat.dedyn.io.           59      IN      RRSIG   SOA 8 3 60 20170907000000 20170817000000 16713 pat.dedyn.io. ICHfyC1jcmI7hk/qcvs1mHU+DXgiAHp56tHZ0DrBIlg8Qrzj9MI8stHcWT6J7mf4e+3PMN+p34RvFokGAMqeHQ2qN4QSe1yX+Evj5RCI6Gx125ae/S0xCSnUuz4tfcmuorn+Ljk//2a8j2q+w6awrCqdoAMaVAdIMmHmmuHKhpQ=
> 3645142tqk02bkonalf8lhipr7bs92k2.pat.dedyn.io. 59 IN NSEC3 1 0 300 D7E2042737B912B9 4O4UISQPPPTC260I5BQ6R816IC02HFI5  A NS SOA RRSIG DNSKEY NSEC3PARAM
> 3645142tqk02bkonalf8lhipr7bs92k2.pat.dedyn.io. 59 IN RRSIG NSEC3 8 4 60 20170907000000 20170817000000 16713 pat.dedyn.io. ZkcJecwn698jOHCFN+Fn6Z3qGTZuIzVo0W25cLG6NB0DCnMdVhmD2FpWvaIT8OVWIyMSxdbC99T4pvSkdZakZWRfeJNeomwrWvbYGkGNgo/3uoQRfvm5WgTHjmoYP9QopEKpra5L2Dm8l4fQagp+BBos48QNlKeABqTkiufLEts=
> 
> ;; Query time: 212 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: Thu Aug 24 10:24:59 EDT 2017
> ;; MSG SIZE  rcvd: 530
> 
> I just upgraded to 1.6.5 and retried, and get the same results.
> I see one interesting thing about this domain:
> 
>    *  The DS records are published with digests 1, 2, 3 and 4,
>       which includes GOST(3).  I build unbound without GOST
>       support.  (The GOST code in OpenSSL is not well maintained,
>       and I prefer to avoid it).
> 
> Does anyone know why unbound is returning "AD=0"?  Is it a feature or
> a bug?  Somewhat verbose output from "unbound-host" below...
>        
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170824/d2406b28/attachment.sig>