Hello
we still have an unsolved issue and cannot find a solution. It's still the same as
https://www.unbound.net/pipermail/unbound-users/2015-October/004057.html ...
test-setup:
client -> router -> unbound -> router -> nameserver1 + nameserver2
client's /etc/resolv.conf has only one line: "nameserver ${unbound-ip}"
unbound.conf is minimal:
server:
local-zone: "10.in-addr.arpa." transparent
domain-insecure: "10.in-addr.arpa."
stub-zone:
name: "10.in-addr.arpa."
stub-addr: ${nameserver1-ip}
stub-addr: ${nameserver2-ip}
nameserver1+2 serve 10.in-addr.arpa. using http://cr.yp.to/djbdns/walldns.html
Everything is fine as long as both nameservers are up.
If one server fail (simple case: host up, nameserver down) client get "no servers could be reached" or similar
answers from local stubresolver. A moment later a second query for the same name succeed. But again some queries later we observe timeouts or no answers again.
With tcpdump on both nameservers I see queries that are immediately answers by the running nameserver
if the nameserver is down, I see "ICMP port unreadable" packets back to unbound.
I run "watch -n 1 unbound-control dump_infa | grep arpa"
There is a value "delay" in the line of the failed nameserver that count down from 30...90 up to zero.
After unbound once learned nameserver1 is down I could ask non-cached queries which are answered immediately
Until the delay counter reach 0. Then there is a again the error in answering un-cached queries.
it's unbound-1.5.9 including the patch https://www.unbound.net/pipermail/unbound-users/2016-June/004379.html.
minimal-responses, qname-minimisation and use-caps-for-id are disabled.
Andreas
A. Schulze via Unbound-users:
stub-zone:
name: "10.in-addr.arpa."
stub-addr: ${nameserver1-ip}
stub-addr: ${nameserver2-ip}
Everything is fine as long as both nameservers are up.
If one server fail (simple case: host up, nameserver down) client get "no servers could be reached" or similar answers from local stubresolver.
I have an update.
It works as expected if I use "forward-zone + forward-addr" statements.
In that case my config looks like this:
forward-zone:
name: "10-in-addr.arpa."
forward-addr: ${nameserver1-ip}
forward-addr: ${nameserver2-ip}
Now I could switch of one of both nameservers. As long as one nameserver is up
any question, even for un-cached data, is answered immediately.
Am I right that "forward-zone" is not the correct setup to point unbound to a authoritative nameserver?
So maybe there is still a bug somewhere in unbound-1.5.9 ...
Andreas
reading "man unbound.conf" again and again there are more questions then answers.
forward-zone:
There may be multiple forward-zone: clauses. Each with a name: and zero
or more hostnames or IP addresses.
same text for stub-zone...
what's the use case for a stub/forward-zone with zero stub/forward-host: and stub/forward-addr: ?
stub/forward-first is also confusing to me. default: no = disabled = "do not stub/forward-first" = "stub/forward second" ??
again: it may be helpful to know at least one use case.
stub-zone point to authority servers, forward-zone point to recursive servers.
that mean to me that my current setup is wrong although it's the one that works
while reading the archives I found also that from 2012. Looks really like the same problem!
http://www.unbound.net/pipermail/unbound-users/2012-July/002467.html
Andreas
forward-zone:
name: "10-in-addr.arpa."
forward-addr: ${nameserver1-ip}
forward-addr: ${nameserver2-ip}
add
forward-first: yes
does this fix it ?
if so its a bug imho ?
reading "man unbound.conf" again and again there are more questions then answers.
forward-zone:
There may be multiple forward-zone: clauses. Each with a name: and zero
or more hostnames or IP addresses.
same text for stub-zone...
what's the use case for a stub/forward-zone with zero stub/forward-host: and
stub/forward-addr: ?
stub/forward-first is also confusing to me. default: no = disabled = "do not
stub/forward-first" = "stub/forward second" ??
again: it may be helpful to know at least one use case.
Hello,
following text is not directly related to Unbound but it describes use-cases
for forwarding:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-dns-forwarding.html
Sub-chapter "Forward Policies" describes behavior as implemented in BIND 9
but I guess that Unbound will so the same thing.
I hope it helps.
Petr Spacek @ Red Hat