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

Tomas Hozza thozza at redhat.com
Tue Aug 26 12:42:26 UTC 2014


On Tue 26 Aug 2014 02:32:24 PM CEST, Kevin Darcy wrote:
> So you care enough about security to implement DNSSEC, but you run your
> forwarder on port 80. Interesting...
>
>                                                             - Kevin

It is completely artificial setup for testing purpose only.

> On 8/26/2014 8:19 AM, Tomas Hozza wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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
>> authvalidated
>> 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 for
>> relevant NSEC3
>> 26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking for
>> relevant NSEC3
>> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
>> 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 for
>> relevant NSEC3
>> 26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 proves
>> 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 for
>> 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 for
>> 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: nonexistence
>> proof(s) found
>> 26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validation
>> 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 DNSSEC
>> returns unsecure (google.com): looking for DLV
>> 26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking for
>> 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/HswAAoJEMWIetUdnzwtNkoH/it+eUSHs9n6doXeweAgwc6V
>> GnE+sfdZ28Hm77euf6ACRPGBgP9ZA9vq3k2hvFo2JbNejoFd1gj0WTNphlL2tSoE
>> QECltLCbCHSZj8vo7dOoN9kusRKSuKi9rP0Lp/DXCDvhqJ+Woq8y5cgvkLRT5snA
>> lgR3hfc44Rc9Tp4K6NoLX7pBVt1nWRWp4hFyJUuZ5B0qXWMCNyBioeNSe2yIFowE
>> uV33TazpImavG4qXUjwV1f4EXSgjuSzEUUn2sAm9LdD6knMAOYPpCXw203mtSCan
>> +JoXUcwxN+gZHEQaMSBoTsw7DxZS8NVtfdMxrvpL+Ro+LTzs3CJZioc1JjuVpas=
>> =0zaE
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>>
>>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com


More information about the bind-users mailing list