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!
-Harry
