I'm trying to use libunbound to talk the local validating unbound resolver and libunbound doesn't set the AD flag on the query as expected[1]. I'm not setting any trust anchors to avoid the validation feature. I'm not aware of any way to configure libunbound to set AD flag in queries. [1] http://tools.ietf.org/html/rfc6840#section-5.7 Relevant code: https://sourceware.org/git/?p=netresolve.git;a=blob;f=backends/dns.c;hb=HEAD#l390 (priv->validate set to false)
Also note that while we need to set AD flag in the query in order to receive the AD flag in the response, we don't want to trust the AD flag, unless it comes from a trusted resolver (as configured by the user or the local one configured e.g. by dnssec-trigger). If we don't trust the AD flag, we need to clear it from the response before passing it to the application. In that case we don't need to set AD flag on the query (and indeed we shouldn't, so it's clear that we don't support AD flags due to local configuration).
What would the point be of setting the AD flag on the query for libunbound? If it receives the AD bit, it is going to completely ignore it anyway, because it is a validating resolver and it will only set the AD bit for things it has validated. As you don't give it any trust anchors , it cannot validate anything, so responses will never have the AD bit. I don't think this behavior is a bug. Sending the AD bit in a query (without DO bit) is only useful for no-validating resolvers. (although I personally don't believe that non-validating resolvers should be passing along AD bits and I dont think anything should accept and AD bit without either validating or asking localhost or asking a trusted resolver (over VPN or via the new dnssec.conf options in glibc)
(In reply to Paul Wouters from comment #2) > What would the point be of setting the AD flag on the query for libunbound? > If it receives the AD bit, it is going to completely ignore it anyway, > because it is a validating resolver and it will only set the AD bit for > things it has validated. As you don't give it any trust anchors , it cannot > validate anything, so responses will never have the AD bit. Thanks, edited summary accordingly. > although I personally don't believe that > non-validating resolvers should be passing along AD bits and I dont think > anything should accept and AD bit without either validating or asking > localhost or asking a trusted resolver Covered already in comment #1. > via the new dnssec.conf options in glibc Any links, please?
Further clarified the summary for a casual reader that might not have the context that we're talking about the library, not the daemon.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Pavel, I think this should be filled into the upstream bugzilla and discussed there first.
If anyone is interested in this feature request, please discuss it with the Unbound upstream directly.