I know the guy (Torbjorn Eklov) who wrote the script at test.ipv6.tk so
I asked him about the internals. It is a javascript that check if you
can reach www.trasigdnssec.se (brokendnssec in Swedish). The domain is
deliberately broken; there is a published DS record at the parent but no
corresponding DNSKEY at the child. So it has nothing to do with DO flag
set or not.
So if you can't resolve www.trasigdnssec.se you are obviously doing
validation somewhere.
Do you perhaps have a forwarder to something that validates?
Val-permissive-mode only instructs unbound to return a bogus answer but
not to set the AD-flag (instead of returning servfail). So it will not
disable DNSSEC validation.
I wish I had an unbound to test with where I am right now, but reading
from the manual page you might want to try the module-config option to
turn off DNSSEC validation.
module-config: <"module names">
Module configuration, a list of module names separated
by spaces, surround the string with quotes (""). The modules can be
validator, iterator. Setting this to "iterator" will result in a
non-validating server. Setting this to "validator iterator" will
turn on DNSSEC validation. The ordering of the modules is important.
You must also set trust-anchors for validation to be useful.
however, it will still perform queries with the DO bit, and validation.
It will just pass the data along anyway (as if the client send the CD bit)
This is because a client of unbound may be validating and thus needs the
signatures, and it sets the DO bit to fetch the signatures for clients
that need them for validation.
however, it will still perform queries with the DO bit, and validation.
It will just pass the data along anyway (as if the client send the CD bit)
This is because a client of unbound may be validating and thus needs the
signatures, and it sets the DO bit to fetch the signatures for clients
that need them for validation.
That's exactly what I was thinking after reading the other reactions (and being more awake ?).
Well, I did some testing, it seems I pretty much found the cause of the problem. The tool uses a simple
timer to wait for the DNS-answer and if it could an answer before that time it says: does not validate
But as my unbound is just used by me and a few people in the same building, no records for the
NS's of the SE-TLD, etc. were not cached and thus it just took to much time to resolve it the first time.
If I reload it works as expected.
I do have a suggestion, maybe it would be wiser for the creator of the javascript to use the onerror
and onload events of the images he's trying to load. That is probably more reliable then a simple
timer.
