Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1164040 - [RFE] libunbound: optionally work as a non-validating resolver, set AD flag in queries, accept AD flag in responses
Summary: [RFE] libunbound: optionally work as a non-validating resolver, set AD flag i...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Tomáš Hozza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: dnssec
TreeView+ depends on / blocked
 
Reported: 2014-11-14 00:37 UTC by Pavel Šimerda (pavlix)
Modified: 2018-01-22 13:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-22 13:52:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Pavel Šimerda (pavlix) 2014-11-14 00:37:14 UTC
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)

Comment 1 Pavel Šimerda (pavlix) 2014-11-16 11:28:49 UTC
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).

Comment 2 Paul Wouters 2014-11-17 07:28:24 UTC
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)

Comment 3 Pavel Šimerda (pavlix) 2014-11-18 10:50:43 UTC
(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?

Comment 4 Pavel Šimerda (pavlix) 2014-11-18 11:37:54 UTC
Further clarified the summary for a casual reader that might not have the context that we're talking about the library, not the daemon.

Comment 5 Jaroslav Reznik 2015-03-03 17:05:20 UTC
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

Comment 6 Tomáš Hozza 2015-04-01 15:36:12 UTC
Pavel, I think this should be filled into the upstream bugzilla and discussed there first.

Comment 7 Tomáš Hozza 2018-01-22 13:52:03 UTC
If anyone is interested in this feature request, please discuss it with the Unbound upstream directly.


Note You need to log in before you can comment on or make changes to this bug.