On Tue 26 Aug 2014 03:07:22 PM CEST, Mark Andrews wrote:
> In message <53fc827e.7090...@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.
OK, now I understand why it has to fail if configured to use DLV
but the validation using DLV failed for whatever reason.
Thank you!
>>> 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.6040...@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@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@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-----
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
_______________________________________________
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
