Bugzilla – Full Text Bug Listing
|Summary:||Unbound validating resolver forwarding to another unbound validating resolver is unreliable on bogus DNSSEC responses|
|Product:||unbound||Reporter:||Simon Arlott <bugzilla.nlnetlabs.simon>|
|Component:||server||Assignee:||unbound team <unbound-team>|
Description Simon Arlott 2013-08-03 15:26:57 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).
Comment 1 Simon Arlott 2013-08-03 15:27:59 CEST
(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".
Comment 2 Wouter Wijngaards 2013-08-05 09:24:46 CEST
Hi Simon, 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? Best regards, Wouter
Comment 3 Simon Arlott 2013-08-05 13:29:48 CEST
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.
Comment 6 Simon Arlott 2013-08-05 23:29:14 CEST
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.
Comment 7 Wouter Wijngaards 2013-08-06 16:42:46 CEST
Hi Simon, 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
Comment 8 Wouter Wijngaards 2013-08-07 09:41:08 CEST
Hi Simon, 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. Best regards, Wouter
Comment 9 Wouter Wijngaards 2013-08-08 11:30:16 CEST
Hi Simon, 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. Best regards, Wouter
Comment 10 Wouter Wijngaards 2013-08-08 16:46:31 CEST
Hi Simon, 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