search

NLnetLabs / unbound

Unbound is a validating, recursive, and caching DNS resolver.
https://nlnetlabs.nl/unbound
BSD 3-Clause "New" or "Revised" License
3.12k stars 358 forks source link

Resolving sas.com with dnssec-validation fails though signed delegations seem to be (mostly) correct #986

Open gongsearch opened 10 months ago

gongsearch commented 10 months ago

Not sure if this is really a bug but I would like to note this. Trying to resolve "sas.com" fails with unbound (head) if dnssec-validation is enabled:

2024-01-04T10:40:01 sdb unbound: [898890:1] info: validation failure : signature for expected key and algorithm missing from 40.120.32.101 for key sas.com. while building chain of trust 2024-01-04T10:40:01 sdb unbound: [898890:2] info: validation failure : signature for expected key and algorithm missing from 40.120.32.101 for key sas.com. while building chain of trust 2024-01-04T10:40:01 sdb unbound: [898890:1] info: validation failure : signature for expected key and algorithm missing from 15.197.178.251 for key sas.com. while building chain of trust 2024-01-04T10:40:01 sdb unbound: [898890:3] info: validation failure : signature for expected key and algorithm missing from 3.33.177.68 for key sas.com. while building chain of trust 2024-01-04T10:40:01 sdb unbound: [898890:0] info: validation failure : signature for expected key and algorithm missing from 15.197.178.251 for key sas.com. while building chain of trust 2024-01-04T10:40:01 sdb unbound: [898890:0] info: validation failure : signature for expected key and algorithm missing from 3.33.177.68 for key sas.com. while building chain of trust

Checking dnssec-setup with verisign says everything is fine:

https://dnssec-analyzer.verisignlabs.com/sas.com#

Checking against dnsviz.net. As far as I understand there seems to be a valid path and also an invallid path in the trust-chain:

https://dnsviz.net/d/sas.com/dnssec/

For my very limited understanding of dnssec the chain of trust has at least one valid path and for this unbound should resolve - or am I wrong here?

wcawijngaards commented 10 months ago

The failure is exactly the invalid path in the trust chain. This is the option, harden-algo-downgrade: no. The default is 'no' and this makes the lookup work for me, since the trust chain works for one path. If you have the option enabled, this is why it fails, because the option specifically detects this situation, one path has a bad signature, and then fails it for you. Since one trust path has a bogus signature and one trust path has a working signature, there is a choice what to do, more lenient, or more strict. With the option this can be controlled. The default is 'no' for it, and this makes unbound accept the working signature.

I guess the option is enabled in your config. If so, I guess you want to disable the option, since you say you expect the working trust path to be accepted.