>>> The failure appears because of a signature mismatch. But why is >>> validation taking place when the actual resolver can't talk dnssec? My >>> config file looks like this: >> It should fall back to non-secure. If your forwarder changes again to one >> that does relay dnssec information, unbound drops the cache and uses the >> validator again (If I understood Wouter correctly, I have not verified >> this myself) > > It does not do that! That would be a downgrade attack! > > However, this idea is significantly popular, and there is even an option > for unbound: harden-dnssec-stripped that you can turn off. > You are then susceptible to the downgrade attack, but it does the above. > > Best regards, > Wouter Hi Wouter, Usually I just lurk on this mailinglist, but this time I have a question about DNSSEC. I'm not familair with all details of DNSSEC, but I thought it doesn't really matter all that much where you get the DNSSEC information from, as long as you have a copy of the public root key or maybe something from a DLV-system. You would be able to verify it all the way from the top down to the record that you want to verify. A forwarded would then just be a cache, you could ask that forwarded to retrieve the right RR and you'd be able to verify it. This is what I always assumed, let's say the root is signed ( I assume with DLV it's kind of similair ): 1. you know the root is signed, you have the public key (or whatever key material you need), you get the right records and you verify these records. They can't be changed, otherwise the signatures wouldn't match. 2. It has a record that says .org is signed and it has to match with this key. 3. you ask for .org information and it HAS to be signed, if it isn't signed or doesn't match, it's invalid. and so on. So where can the records be stripped ?