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.
for-upstream:
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
lookups.
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
forward-zone:
name "."
address: Upstream internet resolver
forward-zone:
name "example.com"
address: LAN master
auth-zone:
name "lanONE.example.com"
master: LAN maser
auth-zone:
name "lanTWO.example.com"
master: LAN maser
auth-zone:
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
for.
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'
time...
Thanks for any hints,
-harry
More information about the Unbound-users
mailing list