Re: message is bogus, non secure rrset with Unbound as local caching resolver
Hi,
On 04/03/16 11:39, Havard Eidnes wrote:
>>> Following the "not a bug" response from the BIND maintainers
>>> yesterday evening, can you please point to chapter and verse
>>> mandating this behaviour for non-authoritative recursive
>>> resolvers?
>>
>> RFC4035 3.2.3 for validators, all RRsets in answer and authority
>> sections should be authentic ...
>
> That's an incomplete quote. A more complete quote would be:
>
> 3.2.3. The AD Bit
>
>The name server side of a security-aware recursive name server MUST
>NOT set the AD bit in a response unless the name server considers all
>RRsets in the Answer and Authority sections of the response to be
>authentic. The name server side SHOULD set the AD bit if and only if
>the resolver side considers all RRsets in the Answer section and any
>relevant negative response RRs in the Authority section to be
>authentic. [...]
>
> However, since the CD ("Checking Disabled") bit is set in the query
> Unbound sends to its forwarder, the AD ("Authentic Data") bit is of
> course not set in its response, so this whole section doesn't really
> apply.
But unbound is trying to set the AD flag in its reply. And thus it
needs all the RRsets to be secure. Thus, the reply from the forwarder
with CD flag becomes bogus.
I fixed it so that Unbound uses CD=0 to send queries to a forwarder.
Unless a dnssec trust anchor exists above the qname, in which case CD=0
is only attempted on the first query.
CD flag is still used on all queries to authorities.
Best regards, Wouter
>
> Please also note that this section only talks about setting the AD
> bit, not about whether it's mandatory to include "all required DNSSEC
> records that the querier is missing and which are required to validate
> the included information".
>
> If such or a similar mandate exists on a recursive resolver, it must
> come from elsewhere.
>
> Therefore my suggestion: "If the validator needs more information to
> complete validation, it had better ask for it explicitly."
>
> As has been pointed to elsewhere in this thread there's a question of
> whether setting the CD bit in queries sent to a forwarder is
> appropriate, but RFC 6840 (Clarifications and Implementation notes for
> DNS security) seems to recommend the practice, ref. section 5.9, but
> also lists a number of different ways this can be done, ref. appendix
> B, which also mentions the possibility of there being more than one
> validator on the path, as can be the case when using a forwarder.
>
> Regards,
>
> - Håvard
>
signature.asc
Description: OpenPGP digital signature
Re: L-Root IPv6 address renumbering
On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: Not quite, I want to avoid two things: 1) The sysadmin should never have to update the root hints by hand. "apt update && apt upgrade" should upgrade any packages needed to bring the root hints up to date. 2) The package maintainers shouldn't have to patch and rebuild each package with compiled in root hints when a root server is renumbered. At what point would a binary have a newer internal roots hints than the filesystem root.hints file when a user is using #1 to keep updated? Is there a subset of users who would update the binary but not apt update/upgrade? I guess to me, it seems better to directly address whatever failed to update the external root.hints than to add complexity of a "will-she won't-she" of using defined data files. Also, does any of this matter? The root hints just used to find the root servers on initialization, and then the resolver retrieves and uses the current roots anyway. Resolvers need to update eventually, but it's not a networking-breaking level of urgency either, is it? -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: L-Root IPv6 address renumbering
Dave Warren via Unbound-users wrote: > On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: > >Not quite, I want to avoid two things: > > > >1) The sysadmin should never have to update the root hints by hand. > >"apt update && apt upgrade" should upgrade any packages needed to bring > >the root hints up to date. > > > >2) The package maintainers shouldn't have to patch and rebuild each > >package with compiled in root hints when a root server is renumbered. > > At what point would a binary have a newer internal roots hints than the > filesystem root.hints file when a user is using #1 to keep updated? Is there > a subset of users who would update the binary but not apt update/upgrade? This is a good point, it doesn't really matter for the distro user, I guess. > I guess to me, it seems better to directly address whatever failed to update > the external root.hints than to add complexity of a "will-she won't-she" of > using defined data files. > > Also, does any of this matter? The root hints just used to find the root > servers on initialization, and then the resolver retrieves and uses the > current roots anyway. Resolvers need to update eventually, but it's not a > networking-breaking level of urgency either, is it? I agree, the consequences are extremely mild in the first place. We still go to the trouble of backporting the root hint updates, though. -- Robert Edmonds edmo...@debian.org
Re: message is bogus, non secure rrset with Unbound as local caching resolver
On 2016-03-17 15:19, W.C.A. Wijngaards via Unbound-users wrote: I fixed it so that Unbound uses CD=0 to send queries to a forwarder. Unless a dnssec trust anchor exists above the qname, in which case CD=0 is only attempted on the first query. Hi, I did a quick test here, and can confirm that this fixes the problem. Thank you very much for looking into this problem! Best regards, Olav Morken UNINETT
Re: message is bogus, non secure rrset with Unbound as local caching resolver
> But unbound is trying to set the AD flag in its reply. And thus it > needs all the RRsets to be secure. Thus, the reply from the forwarder > with CD flag becomes bogus. Yes, I know unbound is trying to validate the answer. However, insisting that a recursor return all pertinent data required for validation of the response, especially with cd=1 set in the query, is unreasonable. > I fixed it so that Unbound uses CD=0 to send queries to a forwarder. > Unless a dnssec trust anchor exists above the qname, in which case CD=0 > is only attempted on the first query. Not sure I understand what it means to have a "trust anchor exist above the qname", but otherwise I suspect and hope this will cure the problem. > CD flag is still used on all queries to authorities. Of course. Regards, - Håvard
Re: L-Root IPv6 address renumbering
On 2016-03-16 14:06, Robert Edmonds via Unbound-users wrote: Dave Warren via Unbound-users wrote: On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: Not quite, I want to avoid two things: 1) The sysadmin should never have to update the root hints by hand. "apt update && apt upgrade" should upgrade any packages needed to bring the root hints up to date. 2) The package maintainers shouldn't have to patch and rebuild each package with compiled in root hints when a root server is renumbered. At what point would a binary have a newer internal roots hints than the filesystem root.hints file when a user is using #1 to keep updated? Is there a subset of users who would update the binary but not apt update/upgrade? This is a good point, it doesn't really matter for the distro user, I guess. I may be wrong, but for those who take the time and effort to build their own Unbound, I see them either using a root.hints file because they know what they're doing, or not because they've never heard of it (or because they know what they're doing) I'm sure there's some small group that will create one and abandon it, but I just can't imagine that this type would remember to manually update the binary. I agree, the consequences are extremely mild in the first place. We still go to the trouble of backporting the root hint updates, though. I agree that it's worth doing, but the keep-it-simple of just reading the configured file or not seems like it's more valuable than guessing at whether the file should be used or ignored. Also, the principle of least surprise, a user will expect that the file will be used or not. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: L-Root IPv6 address renumbering
W.C.A. Wijngaards via Unbound-users wrote: > But I think just setting the configuration option for root-hints in > unbound.conf is probably just what you want? Do you still need to be > able to set a default value for the root-hints file location, or is it > just as good to set it in unbound.conf (or unbound.conf.d/ drop-file) ? Would setting a compile-time default value also apply to libunbound? Just setting it in /etc/unbound.conf will only apply to the daemon, right? -- Robert Edmonds edmo...@debian.org
