recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

Tue Aug 26 12:50:06 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2014 02:27 PM, Mark Andrews wrote:
> Why would you expect them to succeed? 

Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.

> If you use DLV you are
> expecting anything for which DLV is used as a trust anchor to be
> safe from being spoofed.  The *only* way this can happen is to fail
> if the DLV lookup fails for any reason.

I can understand that. It just didn't seem correct to me for the reason
stated above. Thanks for acknowledging that this behavior is expected.

Tomas

> Mark
> 
> In message <53FC7B35.6040604 at redhat.com>, Tomas Hozza writes:
> Hello.
> 
> I found out that when bind is configured as recursive resolver with
> dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
> lookups for unsigned (UNSECURE) names fail even if the validation
> succeeds (IOW the validation of NSEC3 answer proves that DS does not
> exist so domain (name) is not signed).
> 
> 
> I tested it with one server set up as forwarder running on 127.0.0.1 at 80
> configured not to answer queries for dlv.isc.org (query will timeout).
> 
> I have bind (9.9.4-P2) configured with:
> 
> forward only;
> forwarders { 127.0.0.1 port 80; };
> recursion yes;
> dnssec-enable yes;
> dnssec-validation yes;
> dnssec-lookaside auto;
> 
> 
> Doing a lookup for (unsigned) google.com A record times out:
> # dig @127.0.0.1 google.com A
> 
> ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> @127.0.0.1 google.com A
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12157
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;google.com.			IN	A
> 
> ;; Query time: 4 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Aug 26 14:08:03 CEST 2014
> ;; MSG SIZE  rcvd: 39
> 
> in named log I can see:
> ...
> 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in authva
> lidated
> 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
> nsecvalidate
> 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
> indicates potential closest encloser: 'com'
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
> super-domain com
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 pro
> ves
> name does not exist: 'google.com'
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
> indicates optout
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
> checkwildcard: *.com
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
> super-domain com
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking f
> or
> relevant NSEC3
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
> checkwildcard: *.com
> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexiste
> nce
> proof(s) found
> 26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validat
> ion
> completion event
> 26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
> validation OK
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
> 26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
> 26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
> dsfetched2: ncache nxrrset
> 26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSS
> EC
> returns unsecure (google.com): looking for DLV
> 26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking fo
> r
> DLV google.com.dlv.isc.org
> ...
> 
> This looks to me that the result of DNSSEC validation of A record
> for google.com proved that it is UNSECURE.
> 
> However the validation using DLV proceeds and fails in the end since
> dlv.isc.org can not be resolved.
> 
> 
> Doing a lookup for (signed) nic.cz A record succeeds:
> [root at unused-4-247 ~]# dig @127.0.0.1 nic.cz A
> 
> ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> @127.0.0.1 nic.cz A
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25002
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;nic.cz.				IN	A
> 
> ;; ANSWER SECTION:
> nic.cz.			1163	IN	A	217.31.205.50
> 
> ;; Query time: 7 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Aug 26 14:12:21 CEST 2014
> ;; MSG SIZE  rcvd: 51
> 
> 
> I think this behavior (with unsigned records) may not be completely correct.
> I think since the chain of trust built from the root server proves that
> the domain name is not signed, the following unsuccessful validation using
> DLV should not make the whole lookup fail.
> 
> However I might be wrong, so asking on users list before submitting a bug.
> 
> Thanks!
> 
> Regards,

- -- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT/IJ+AAoJEMWIetUdnzwtlaYH/jljBnuul3yKrTfiLo58IbHQ
8mSMdGVZTXZkaW6I2y0N/Xz1B0orPRe5V8Q512mUmWi3F0GrevDP+Y5K52mHDLVP
te1MKhPzHSUKJ8hAVvlLQCFm5r8VFII9DbonQtC9GNyFp6MVaRaVln2fIcnisBFO
jHZbs4X37siFH86KlWk5qi7L5bsp+V6j9XnJF6OcqsBoQi7x/QqEfzGg5rZVIyqK
wffxM1ejjxbi8ONiAD7Xii7f7cK2H1iv3n0QXpQGsWgJQ/sfwb9VDaEHSKotVJBn
WuNVazIvq/UTtpdoCN43Ptoc9U91dopZiE4oliY4OPIutsfz80mmtKZZU9u4g1I=
=BYKc
-----END PGP SIGNATURE-----