[Unbound-users] forward zone order

[Will Yardley]

I've got some forward zones forwarding to both a local rbldnsd on a
different port, as well as a remote server that's a backup. I had
expected that the behavior would be to prefer the first in the list,
however, from a couple things I noticed today, I'm not so sure.

My config is as follows:

forward-zone:
name: "zen.spamhaus.org"
forward-addr: ***@3768
forward-addr: 131.215.239.55

My questions are:
a) Will this config always prefer the first entry?
b) If not, is there a way to make it prefer the first entry?

TIA
w

[Will Yardley]

To give a more specific example of the behavior I'm seeing, I'm seeing
certain queries fail completely when one of the two forwarders is not
responding.

Unbound is RHEL 6 version (1.4.22).

[in my config; note - unbound-control doesn't seem to list the port]
forward-zone:
name: "sbl-xbl.spamhaus.org"
forward-addr: ***@3768
forward-addr: 131.215.239.55

# unbound-control list_forwards | grep sbl-xbl
sbl-xbl.spamhaus.org. IN forward: 127.0.0.1 X.X.X.55

# dig -p3768 2.0.0.127.sbl-xbl.spamhaus.org

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> -p3768 2.0.0.127.sbl-xbl.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2338
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;2.0.0.127.sbl-xbl.spamhaus.org. IN A

;; ANSWER SECTION:
2.0.0.127.sbl-xbl.spamhaus.org. 60 IN A 127.0.0.2
2.0.0.127.sbl-xbl.spamhaus.org. 60 IN A 127.0.0.4

;; Query time: 0 msec
;; SERVER: 127.0.0.1#3768(127.0.0.1)
;; WHEN: Thu Jan 8 13:19:53 2015
;; MSG SIZE rcvd: 80

# dig 2.0.0.127.sbl-xbl.spamhaus.org

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> 2.0.0.127.sbl-xbl.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31161
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.sbl-xbl.spamhaus.org. IN A

;; Query time: 286 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 8 13:19:59 2015
;; MSG SIZE rcvd: 48


# dig 2.0.0.127.sbl-xbl.spamhaus.org @X.X.X.55

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> 2.0.0.127.sbl-xbl.spamhaus.org @X.X.X.55
;; global options: +cmd
;; connection timed out; no servers could be reached


When the second forward is reachable again, the queries start responding
again.

w

[Will Yardley]

And also, I do have
do-not-query-localhost: no
set already
per http://comments.gmane.org/gmane.network.dns.unbound.user/3234

w

[Will Yardley]

I had expected that the behavior would be to prefer the first in the
list, however, from a couple things I noticed today, I'm not so sure.
name: "zen.spamhaus.org"
forward-addr: xx.xx.xx.xx

I verified that a significant amount of traffic is being sent to the
second forwarder. Short of using external software or setting up an
internal load-balanced VIP, is there any way with unbound to prefer a
specific forwarder (in this case, the local one), except as a failover?

For DNSBL lookups, would I be better off using stub zones instead of
forwarders (the dnsbl servers are authoritative), and would the behavior
be any different then?

w

[W.C.A. Wijngaards]

Hi Will,

Post by Will Yardley

I had expected that the behavior would be to prefer the first in
the list, however, from a couple things I noticed today, I'm not
so sure.

I verified that a significant amount of traffic is being sent to
the second forwarder. Short of using external software or setting
up an internal load-balanced VIP, is there any way with unbound to
prefer a specific forwarder (in this case, the local one), except
as a failover?
For DNSBL lookups, would I be better off using stub zones instead
of forwarders (the dnsbl servers are authoritative), and would the
behavior be any different then?

Yes a stub is better if they are authoritative, likely saves
processing for unbound. The behaviour is the same, it randomly
chooses, based on the ping-times of the servers. There is the
forward-first: option, but I am unsure if it does what you want
(disable the stub clause temporarily if the local ip address fails for
a minute or so).

Best regards,
Wouter

[Will Yardley]

Post by W.C.A. Wijngaards

Post by Will Yardley

I had expected that the behavior would be to prefer the first in
the list, however, from a couple things I noticed today, I'm not
so sure.

I verified that a significant amount of traffic is being sent to
the second forwarder. Short of using external software or setting
up an internal load-balanced VIP, is there any way with unbound to
prefer a specific forwarder (in this case, the local one), except
as a failover?

Yes a stub is better if they are authoritative, likely saves
processing for unbound. The behaviour is the same, it randomly
chooses, based on the ping-times of the servers. There is the
forward-first: option, but I am unsure if it does what you want
(disable the stub clause temporarily if the local ip address fails for
a minute or so).

Shouldn't localhost always be preferred if it's based on latency?
forward-first doesn't appear to do what I want from my reading of it.

forward-first (as I understand it) controls whether or not the public
zone is queried if none of the forwarders respond. In this case, I want
to only query my local mirrors, but I want to always prefer the one
listening on localhost if it's available.

I did verify that stub-zone behaves the same way as forward-zone.

It would be nice if future versions of unbound had the option to control
the behavior, rather than assuming the "smart" solution will work for
everyone.

w