[Unbound-users] Query over 'forward-addr' / 'forward-first'
wouter at nlnetlabs.nl
Mon Jul 23 13:43:58 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 07/18/2012 03:25 PM, Karl Pielorz wrote:
> --On 18 July 2012 13:01 +0200 "W.C.A. Wijngaards"
> <wouter at nlnetlabs.nl> wrote:
>>> 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,
> " 18.104.22.168 rto 119000 msec, ttl 756, ping 161 var 222 rtt
> 1049, tA 2, tAAAA 0, tother 3, probedelay 17, EDNS 0 probed.
> 22.214.171.124 rto 119000 msec, ttl 758, ping 0 var 94 rtt 376,
> tA 2, tAAAA 0, tother 3, probedelay 13, EDNS 0 assumed. 126.96.36.199
> 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
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
>>> 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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Unbound-users