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

Tue Aug 26 13:07:22 UTC 2014

In message <53FC827E.7090401 at redhat.com>, Tomas Hozza writes:
> 
> 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.

No.  It only proves that there is not a trust path from the root
to the zone.  This is *not* the same thing as saying the zone is
unsigned.  It is insecure *with* *respect* *to* the root trust
anchor.  It may or may not be insecure w.r.t. other trust anchors
like those distributed in the dlv.isc.org zone.

> > 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 auth
> va
> > lidated
> > 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resumin
> g
> > 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 a
> t
> > 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 p
> ro
> > 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 a
> t
> > 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: nonexis
> te
> > nce
> > proof(s) found
> > 26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received valid
> at
> > 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 DN
> SS
> > 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-----
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org