Query over 'forward-addr' / 'forward-first'

Unbound
1

Hi All,

I've just started looking at Unbound, under FreeBSD 9, currently running unbound 1.4.17.

I have three 'local' nameservers on our LAN, and I've been using:

"
forward-zone:
        name: "."
        forward-addr: 1.1.1.1
        forward-addr: 2.2.2.2
        forward-addr: 3.3.3.3
        forward-first: yes
"

[obviously 'example' IP's!]

This seems to work fine - i.e. under normal circumstances, queries are answered fine. If I deliberately "fail" 1.1.1.1 - queries are still answered, ditto if I fail 2.2.2.2 as well - they are all sent to 3.3.3.3 to be resolved, and the system can still resolve names.

In 1.4.17 how are forwarders selected? - From syslog/verbose logging - it appears it latches onto one, and stays with it (maybe the fastest responder?)

Is there any way of seeing (e.g. from 'unbound-control dump_infra') which forwarders it considers 'available' or 'not available' / down?

Also, can someone clarify what 'forward-first' actually means? - In the man page it says:

"If enabled, a query is attempted without the forward clause if
              it fails. The default is no."

With this set to 'yes' - if I fail all the forwarders, nothing gets resolved (I was kind of expecting it to retry the query - with the roots? - i.e. no forwarders?) - or does this not apply if you're trying to forward "."?

Thanks for your time,

-Karl

2

Hi Karl,

Hi All,

I've just started looking at Unbound, under FreeBSD 9, currently
running unbound 1.4.17.

I have three 'local' nameservers on our LAN, and I've been using:

" forward-zone: name: "." forward-addr: 1.1.1.1 forward-addr:
2.2.2.2 forward-addr: 3.3.3.3 forward-first: yes "

[obviously 'example' IP's!]

This seems to work fine - i.e. under normal circumstances, queries
are answered fine. If I deliberately "fail" 1.1.1.1 - queries are
still answered, ditto if I fail 2.2.2.2 as well - they are all sent
to 3.3.3.3 to be resolved, and the system can still resolve names.

In 1.4.17 how are forwarders selected? - From syslog/verbose
logging - it appears it latches onto one, and stays with it (maybe
the fastest responder?)

Unbound randomly picks one from the available list. It uses RTT
banding (slow ones are not used, e.g. if it times out).

Is there any way of seeing (e.g. from 'unbound-control
dump_infra') which forwarders it considers 'available' or 'not
available' / down?

Yes, dump_infra would do so, the IP addresses are listed, right?
Or, unbound-control lookup .

Also, can someone clarify what 'forward-first' actually means? - In
the man page it says:

"If enabled, a query is attempted without the forward clause if
it fails. The default is no."

With this set to 'yes' - if I fail all the forwarders, nothing
gets resolved (I was kind of expecting it to retry the query - with
the roots? - i.e. no forwarders?) - or does this not apply if
you're trying to forward "."?

It resolves the query with the roots. But this may need a timeout of
several seconds before it does so.

Best regards,
   Wouter

3

Is there any way of seeing (e.g. from 'unbound-control
dump_infra') which forwarders it considers 'available' or 'not
available' / down?

Yes, dump_infra would do so, the IP addresses are listed, right?
Or, unbound-control lookup .

Thanks for your reply...

The IP addresses were listed. Given time I've seen that the 'rto' field seems to go to high values for 'failed' unavailable servers, e.g.

"
1.1.1.1 rto 119000 msec, ttl 756, ping 161 var 222 rtt 1049, tA 2, tAAAA 0, tother 3, probedelay 17, EDNS 0 probed.
2.2.2.2 rto 119000 msec, ttl 758, ping 0 var 94 rtt 376, tA 2, tAAAA 0, tother 3, probedelay 13, EDNS 0 assumed.
3.3.3.3 rto 119000 msec, ttl 759, ping 0 var 94 rtt 376, tA 2, tAAAA 0, tother 3, probedelay 13, EDNS 0 assumed.
"

So I presume that's what I'm looking for rather than a 'down' type flag?

Also, can someone clarify what 'forward-first' actually means? - In
the man page it says:

"If enabled, a query is attempted without the forward clause if
it fails. The default is no."

With this set to 'yes' - if I fail all the forwarders, nothing
gets resolved (I was kind of expecting it to retry the query - with
the roots? - i.e. no forwarders?) - or does this not apply if
you're trying to forward "."?

It resolves the query with the roots. But this may need a timeout of
several seconds before it does so.

I don't see this here - if I deliberately fail the DNS servers being forwarded to, nothing resolves, e.g. having null-routed all the forwarders (and checking from the command line they're not available) I get:

"
#time dig www.intel.com

; <<>> DiG 9.4.3-P2 <<>> www.intel.com
;; global options: printcmd
;; connection timed out; no servers could be reached
0.000u 0.007s 0:18.00 0.0% 0+0k 0+0io 0pf+0w
"

That's a timeout of 18 seconds gone by. If I repeat the query it still fails - over, and over (with timeout between 8 and 20 seconds), nothing gets resolved (see the 'dump_infra' above for unbound's state at the time).

With verbose logging turned on, queries in this state are fired off to the forwarders - multiple times (and go unanswered), but it seems never to decide to query "the roots".

If I remove the "forwarders" section and restart unbound, it quite happily provides DNS resolution based on the root servers (so it does work - just not when 'forward-zone "."' is used it appears).

-Karl

4

Hi Karl,

Is there any way of seeing (e.g. from 'unbound-control
dump_infra') which forwarders it considers 'available' or 'not
available' / down?

Yes, dump_infra would do so, the IP addresses are listed, right?
Or, unbound-control lookup .

Thanks for your reply...

The IP addresses were listed. Given time I've seen that the 'rto'
field seems to go to high values for 'failed' unavailable servers,
e.g.

" 1.1.1.1 rto 119000 msec, ttl 756, ping 161 var 222 rtt
1049, tA 2, tAAAA 0, tother 3, probedelay 17, EDNS 0 probed.
2.2.2.2 rto 119000 msec, ttl 758, ping 0 var 94 rtt 376,
tA 2, tAAAA 0, tother 3, probedelay 13, EDNS 0 assumed. 3.3.3.3
rto 119000 msec, ttl 759, ping 0 var 94 rtt 376, tA 2, tAAAA 0,
tother 3, probedelay 13, EDNS 0 assumed. "

So I presume that's what I'm looking for rather than a 'down' type
flag?

Yes.

The forward_first was not implemented for the root domain. It is
implemented now in svn trunk - it must pick up the root hints when the
forward server fails and root hints are stored in a different data
structure.

Best regards,
   Wouter