Am 12.06.2019 um 16:21 schrieb Harry Schmalzbauer via Unbound-users:
Am 11.06.2019 um 14:43 schrieb Wouter Wijngaards via Unbound-users:
…
Why is it that you could not do the suggested config file fix?  Set for both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?
Hello Wouter,

this leads to the reply:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 37468
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.sample1.local.    IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.       8       IN      SOA     a.root-servers.net.
nstld.verisign-grs.com. 2019061100 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1 msec

This is no answer clients can hanlde.
Unfortunately, I didn't get the idea of for-downstream:no.
Which client would want a root hint?
Maybe there's something else wrong with my setup?
Did you set for-upstream: yes ?

It seems to give an answer from the root zone instead of the authority
zone, but I thought it would have used the authority zone.
To answer myself, do you have a forward-zone?  For me it then works if a
stub-zone exists (above the name).  So, two entries of stub-zone: name:
"sample1.local" and stub-zone: name: "sample2.local" would make it work
for me.  The issue is that unbound with a forward-zone, does not think
that it should perform recursion so getting data from the authority zone
is not what it wants, because the upstream recursor is doing the recursion.

Hi Wouter,

thanks a lot for that hint.
I always had forwarding "." defined, nice catch – it never came to my mind that this could cause "for-downstream: no"-anomalies; and newer asked if the reply I've been wondering about ever since is correct...

So with forwarder defined and auth-zone: in place, one has to set "for-downstream: no" and _additionally_ define stub-zone: for the same auth-zone: names !?
Will try that next time, thanks!

I had a test setup available, so I tried and I can confirm that the addtitional stub-zone: definition leads to correct replies from auth-zone: when forwad-zone: "." is defined. But, when I set "for-downstream: no" (in order to get CNAME records resolved) the replies don't have AA set. Some MS mechanism needs authoritative answers to determine correct ActiveDirectory "location". _And_ I'd need x-zone CNAME working, which is not possible as far as I understand.
Please correct me if I'm wrong.

Thanks,

-harry

Reply via email to