Unbound 1.7.2rc1 pre-release

Harry Schmalzbauer list.unbound at omnilan.de
Tue Jun 5 13:51:22 UTC 2018

Am 05.06.2018 um 09:38 schrieb Harry Schmalzbauer:
> Am 05.06.2018 um 09:29 schrieb W.C.A. Wijngaards:
>> Hi Harry,
>> On 05/06/18 09:23, Harry Schmalzbauer wrote:
>>> Am 04.06.2018 um 14:07 schrieb W.C.A. Wijngaards via Unbound-users:
>>>> Hi,
>>>> Unbound 1.7.2rc1 pre-release is available:
>>>> https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz
>>>> sha256 
>>>> 561c33f80b757820e3bd632cd339673da84a71dbb6328d124324db2c63a7f833
>>>> pgp
>>>> https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz.asc
>>> Hello,
>>> me again, again regarding auth-zones:
>>> I'm running 1.7.2rc1 on FreeBSD11.2/adm64 and can confirm that the
>>> NOTIFY-dedlock vanished.
>>> But CNAME records aren't resolved as soon as the record comes from
>>> auth-zone:.
>>> Other problems keep me from thinking/researching, but as far as I know,
>>> the authoritative server has to return the CANME results alsong with 
>>> the
>>> record, correct?
>> Yes, but only if you set for-downstream: no and for-upstream: yes.
>> With for-downstream, if that was enabled, then unbound responds with the
>> authority response to the downstream client, and that response does not
>> contain the CNAME result (in fact Unbound includes CNAME results, but
> Hello Wouter,
> thanks a lot for your quick help.
> Pilot error here: I had for-downstream: yes (and for-upstream: yes).
> Sorry for the noise, will need some time to have a closer look at 
> those two options and their meaning.
> Your hints are very helpful, but I'm unsure what I want right now ;-)
>> only if it is from the same auth-zone). The for-upstream: yes makes
>> unbound resolve CNAMEs, and pick information from the auth-zone where
>> necessary.
>> If the config that is used has these settings, then I would be
>> interested in some more information.  What CNAME and so?  How to
>> reproduce or perhaps a simple verbosity 4 log of what is happening.
> Will drop a note as soon as I had time to play with that, but I guess 
> everything is working like designed, it's just a configuration error 
> on my side.

Hello Wouter, all,

I can confirm that setting "for-downstream: no" leads to A answers for 
A-queries when RR type is CNAME.

But unfortunately I don't get the idea.  Maybe somebody (besides the 
developers) else has already thought about the two for-(down|up])stream: 
options and can tell me what I'm missing.

Please correct me if my assumptions are wrong, which  I'd like to try to 
describe here for those two options.

As far as I understand, setting "for-upstream: no" can have only one 
usecase: To copy remote zone data to a local file. Without defining the 
zonefile:, this setting was completely useless as far as I understand, 
since the resolver doesn't use that data at all.

     For convenience, quoting the man page here (for-upstream:):
         Default yes.  If enabled, unbound fetches data from this data
         collection for answering recursion queries.  Instead of sending
         queries over the internet to the authority servers for this
         zone, it'll fetch the data directly from the zone data. Turn it
         on when you want unbound to provide recursion for downstream
         clients, and use the zone data as a local copy to speed up

for-downstream: (assuming "for-upstream: yes" is kept as default setting):
Setting "for-downstream: no" is an option to validate unauthoritative 
answers to clients.  The records are taken from the local copy of the 
zone data, but additionally validated before returned _without_ aa flag.

Keeping "for-downstream: yes" as the default setting, flags answers as 
authoritative (aa) to the clients, and the records came from the local 
copy of the zone data.  No validation is done before answering.

     For convenience, quoting the man page here:
         Default yes.  If enabled, unbound serves authority responses to
         downstream clients for this zone.  This option makes unbound
         behave, for the queries with names in this zone, like one of the
         authority servers for that zone.  Turn it off if you want
         unbound to provide recursion for the zone but have a local copy
         of zone data.  If for-downstream is no and for-upstream is yes,
         then unbound will DNSSEC validate the contents of the zone
         before serving the zone contents to clients and store validation
         results in the cache.

(Sorry if formating doesn't make it onto the list, I'm not used to my 
new MUA)

My problem: CNAME records are not resolved, at least not, if the CNAME 
record points to a different zone, although unbound also has 
authoritative zone data for it!

My scanario:

                          Upstream internet resolver
LAN-client ------ UNBOUND
                         LAN master

     name "."
     address: Upstream internet resolver

     name "example.com"
     address: LAN master

     name "lanONE.example.com"
     master: LAN maser

     name "lanTWO.example.com"
     master: LAN maser

     name "2.0.192.in-addr.arpa"
     master: LAN master

With the default settings (for-upstream: yes and for-downstream: yes), 
'drill @UNBOUND host123.lanONE.example.com A IN' I get an authoritative 
answer with the corresponding A record as long as 
host123.lanONE.example.com has either an A record or the CNAME points to 
the same zone.
Now I have the following data in the zone:
host123.lanONE.example.com. CNAME host123.lanTWO.example.com.

The query above returns the CNAME record as authoritative answer, but 
doesn't show the A records, for the zone, which it is also authoritative 

I'm missing the reason why one would want that behaviour!?!

I can get my desired behaviour by overriding the default with 
"for-downstream: no", but in my case unbound unsucessfully/unnecesarrily 
validates answers, which are unauthoritative – while I'd like them to be 
authoritative but unvalidated.

Sorry if there's something obvious I'm not seeing and wasting peoples' 

Thanks for any hints,


More information about the Unbound-users mailing list