A validating DNS server usually returns a so-called "ad" flag to indicate that the DNS response contains authenticated data. At the moment, we only check if a domain with an invalid DNSSEC signature fails to resolve, but this is not sufficient here. Will have a look at this myself.
(In reply to Peter Müller from comment #0) > A validating DNS server usually returns a so-called "ad" flag to indicate > that the DNS response contains authenticated data. As you said, it *indicates* that the response has been verified. > At the moment, we only check if a domain with an invalid DNSSEC signature > fails to resolve, but this is not sufficient here. Getting the ad flag out of the output of dig is not really easy. Hence we deemed this way as one that is sufficient enough. Ultimately we do not need to be 100% sure that the DNS server supports DNSSEC, because unbound will properly verify every response that comes back from the upstream server. This just exists to not pass anything to unbound that makes it behave funny.
(In reply to Michael Tremer from comment #1) > (In reply to Peter Müller from comment #0) > > A validating DNS server usually returns a so-called "ad" flag to indicate > > that the DNS response contains authenticated data. > > As you said, it *indicates* that the response has been verified. Yep. But it is a negative indicator: If the flag is missing, the resolver does not support DNSSEC for sure (unless, of course, it is some software written without RFC knowledge :-), but if the flag is present, we can't be sure, either. > > > At the moment, we only check if a domain with an invalid DNSSEC signature > > fails to resolve, but this is not sufficient here. > > Getting the ad flag out of the output of dig is not really easy. Hence we > deemed this way as one that is sufficient enough. That surprises me. I thought of somethig like this one: dig soa ipfire.org +dnssec | grep "\;\;\ flags:" | awk -F\: '{ print $2 }' | awk -F\; '{ print $1 }' | grep "\ ad"; As you can see, I love one-liners of bash code... ;-) > > Ultimately we do not need to be 100% sure that the DNS server supports > DNSSEC, because unbound will properly verify every response that comes back > from the upstream server. This just exists to not pass anything to unbound > that makes it behave funny. True. However, I'd like to implement that since it does not harm and might catch some resolvers without DNSSEC letting requests to dnssec-failed.org fail. Not sure if they exist, but in North America, DNS manipulation seems to be used frequently.
Sent in second version of the patch, this time with 50% less "grep". :-)
Fixed in upcoming release Core Update 120 (https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=438da7e0a012cb979e77efcb923ab86b9078fb57).
We only mark bugs as fixed when the solution is released (https://wiki.ipfire.org/devel/bugzilla/workflow)
Core Update 120 has been released.