Hi, sorry for the rather longwinded email. In the interest of saving some time, here is a short summary:
We get the error "message is bogus, non secure rrset" from Unbound in some cases when resolving a wildcard CNAME record. The cause appears to be an upstream BIND resolver that in some cases returns an authority section containing NS-records but no RRSIG-record for those records. A longer version of the questions are at the end, but in short: * Is this a bug in Unbound (it should handle those types of responses) or in BIND (it should not generate those kind of responses). * Could (and should?) Unbound be extended to deal with this type of responses (no matter whether they are legal or not)? Now the longwinded version: We have an Unbound server running as a local caching resolver on a server. This instance is configured to forward requests to two resolvers, one running Unbound and one running BIND. Both Unbound servers are running 1.4.22 from Debian Jessie. The BIND server is running version 9.9.8P2. This error occurs frequently when doing lookups for a domain "pingapi.paas.uninett.no". This is handled by a wildcard CNAME pointing at "paas-lb.uninett.no". Since this is a wildcard CNAME, is must be authenticated with a NSEC3-record in the authority section. As far as we can tell, the problem occurs because the BIND server is occasionally returning responses with NS-records in the authority-section that does not include the RRSIG records. There are actually two errors from Unbound due to this: The first is when doing a request for the "pingapi.paas.uninett.no". In that case, the response from the resolver running BIND looks something like this: ;; ANSWER SECTION: pingapi.paas.uninett.no. 85 IN CNAME paas-lb.uninett.no. pingapi.paas.uninett.no. 85 IN RRSIG CNAME [...] paas-lb.uninett.no. 158 IN A 158.38.213.52 paas-lb.uninett.no. 158 IN RRSIG A [...] ;; AUTHORITY SECTION: st5rjlutdrm3le5lla3r11bu3qu2qk06.uninett.no. 85 IN NSEC3 [...] st5rjlutdrm3le5lla3r11bu3qu2qk06.uninett.no. 85 IN RRSIG NSEC3 [...] uninett.no. 3408 IN NS server.nordu.net. uninett.no. 3408 IN NS benoni.uit.no. uninett.no. 3408 IN NS nac.no. uninett.no. 3408 IN NS ns.uninett.no. uninett.no. 3408 IN NS nn.uninett.no. Note that the signature for the NSEC3-record is present, but no signature for the NS-records. At that point, Unbound rejects the response, and tries a different server: info: validator operate: query pingapi.paas.uninett.no. A IN debug: CNAME response was wildcard expansion and did not prove original data did not exist info: validate(cname): sec_status_bogus debug: iterator[module 1] operate: extstate:module_finished event:module_event_pass info: resolving pingapi.paas.uninett.no. A IN Once the query hits the resolver running Unbound, it succeeds, and the local resolver moves on to resolving the "paas-lb.uninett.no" domain. At that point, it may query the resolver running BIND, and will get a response looking like: ;; ANSWER SECTION: paas-lb.uninett.no. 299 IN A 158.38.213.52 paas-lb.uninett.no. 299 IN RRSIG A [...] ;; AUTHORITY SECTION: uninett.no. 1118 IN NS ns.uninett.no. uninett.no. 1118 IN NS server.nordu.net. uninett.no. 1118 IN NS nac.no. uninett.no. 1118 IN NS nn.uninett.no. uninett.no. 1118 IN NS benoni.uit.no. Now I am a bit unclear about what happens, but as far as I can tell, Unbound sort-of accepts this response, since the authority-section isn't necessary to validate the answer. However, it then fails with the error from the subject line: [...] info: reply from <.> 158.38.212.107#53 info: query response was CNAME info: resolving pingapi.paas.uninett.no. A IN info: processQueryTargets: pingapi.paas.uninett.no. A IN info: sending query: paas-lb.uninett.no. A IN debug: sending to target: <.> 2001:700:0:ff00::1#53 debug: cache memory msg=89289 rrset=121419 infra=3788 val=77277 debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply info: iterator operate: query pingapi.paas.uninett.no. A IN info: iterator operate: chased to paas-lb.uninett.no. A IN info: response for pingapi.paas.uninett.no. A IN info: reply from <.> 2001:700:0:ff00::1#53 info: query response was ANSWER info: finishing processing for pingapi.paas.uninett.no. A IN debug: validator[module 0] operate: extstate:module_restart_next event:module_event_moddone info: validator operate: query pingapi.paas.uninett.no. A IN info: validator operate: chased to . TYPE0 CLASS0 info: validate(cname): sec_status_secure info: validate(positive): sec_status_secure info: message is bogus, non secure rrset uninett.no. NS IN My guess is that it somehow tries to combine the response it got from the server running BIND, which contains an authority-section with NS records but no RRSIG, and the response it got from Unbound, containing the NSEC3-record and its RRSIG record. At that point, Unbound has a response containing three items in its authority-section: * The NSEC3-record for the wildcard CNAME * The RRSIG-record for the NSEC3-record * The NS-records, without any RRSIG-record I see that Unbound has some code for dealing with the case where the authority-section contains NS-records without RRSIG records, but that code does handle this case. The questions I have are: * Is this a bug in BIND or in Unbound, or something else? I am not clear on what recursive resolvers supposed to do with RRSIG-records in the authority section. The DNSSEC specification is very clear on what authorative servers should do (i.e. always include them; if not possible to include them also drop the record they sign). I have however not been able to determine what the behavior should be when the server is a recursive resolver. * Could the code in Unbound be extended to deal with this case as well? As mentioned, I see that code was added to deal with the case where there are only unsigned NS-records in the authority-section. Could that code be made generic, so that it will always strip unsigned NS-records, even when there are other records present? Best regards, Olav Morken UNINETT
