Bugzilla – Bug 516
Unbound validating resolver forwarding to another unbound validating resolver is unreliable on bogus DNSSEC responses
Last modified: 2013-08-08 16:46:31 CEST
l.nic.dk is currently broken (it returns NOERROR with no RRs if you query example.dk and example.dk is unsigned)
With an unbound resolver using another unbound resolver as its only forwarder (both validating) the failure is cached but the query would have worked if one of the other 5 NS were used.
The child unbound resolver is using the CD flag, so the parent unbound resolver returns the invalid response. The child resolver than returns SERVFAIL.
The parent resolver has queried another server after responding to the client, but the client resolver won't be able to retry immediately because it only has one forwarder and that returned invalid data.
The parent resolver needs to act as if it was validating even when the CD flag is set (ignore-cd-flag=yes) but still return the response even if it is invalid (ignore-cd-flag=no).
(In reply to comment #0)
> l.nic.dk is currently broken (it returns NOERROR with no RRs if you query
> example.dk and example.dk is unsigned)
That should read "if you query example.dk for DS records with the DO flag".
Unbound already resolves as if it is validating, also when CDflag is set. But have you configured a trust anchor so that it can actually do the validation? I mean a trust anchor in the upstream unbound?
Unbound already validate results, also when you set CDflag=1 so as to omit bogus stuff that can be fixed up. It'll honor the CDflag and send back results also for bogus information.
Could you perhaps enable higher verbosity on the machines?
Both servers are validating with the root trust anchor configured.
Yes, unbound resolves as if it's validating but it returns the bogus information before it finishes the resolution process.
I have a high verbosity log from both servers but I'll need to filter out some of the config and any other queries first.
Created attachment 231 [details]
Created attachment 232 [details]
I configured *.nic.dk as do-not-query except for a.nic.dk and l.nic.dk.
l.nic.dk has now been fixed so you'd have to simulate that server's NOERROR response to test it.
The client made two queries on behalf of ::1. Both of these received a NOERROR response.
With these logs I should be able to simulate what happens without actually needing the .dk servers to be broken. I just want to know what the responses from the .dk server look like, and those are in the log stream.
Best regards, Wouter
Yes, the dnssec failover in the iterator fails to function here, because the empty response cannot be typed to be from the .dk zone, as there is no SOA RRset that a 'good' nodata response would contain.
Then there is dnssec failover in the validator, and that seems to fail too: the empty response is validated, during that validation it refetches the DS record from a good server, and this is NSEC3-OPTOUT. It allows the unsigned-nodata answer under the NSEC3 optout, classifies it as 'insecure', and passes on the result to the client.
Since the result is classified insecure, the ignore-cd-flag does not make a difference.
I would like to fix both these issues, but need to think about how this can be accomplished.
I have fixed this issue with dnssec lameness detection, it is available in svn trunk of unbound if you need to use it right away.
The issue should be fixed for this case. An in-depth validation fix for this case is not something I can implement, as it seems to work according to RFC.
Thank you for the report. Please let us know if you experience any problems.
Best regards, Wouter