-----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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
