-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karl,
On 07/18/2012 03:25 PM, Karl Pielorz wrote: > > > --On 18 July 2012 13:01 +0200 "W.C.A. Wijngaards" > <[email protected]> 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, > 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 >>> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDVUeAAoJEJ9vHC1+BF+NpBsQAKoC7F4YZNF1LvRB3GOCktr4 h5Au0TGc7I6sycEzjKF60fhxF8aKZ0zKah7N+Cdkr58tO9aCaIIy4XZyQyg2wNMV 4QyvYrFuOJJHrkDOtznhnPxVBb12n9TXCW8tIyrQ6aq0v4VnvK+GMZ2Y1dovCQZb RbRzaefy8CHrC/7cXqpn0hoQ4Y5q04PqXaiNJVHKlFwBmAMFExqyy3DBDE34gQb5 bVew5dezQiy42McceQ/vsvp6Ao0xYaIVvz/myhmtMMACIJyV+Th6RCX6GTIODMkb RB0ma/Z2hA+Dv+Nwsp/Qmn0AHrsq1djvtlKWWl7MFf6mn/LtRCF6owG4NS31ENho zWm8O2s5P1aRi5GlvCfEp1jK3q12RhxTaO70HKl/J1Y9ihjHMf09De7sgdXLF/hR Lv7fj3eTEQiAm21Z36jBE6hrPAlfTGFAoVJ1uTiHWRIu9R4qk0jErMaXdMKc8uYO Sm1g4FZTq+ulD0xZOCCE4Bsx/pBlBwOSyD5WOdsCK3H3hhGdC2f9ElfA3ThTAjWA 05OfJrat6c1ikLhiSTXMYsSaBfCsz3+RPvYYD91DvmwA+FiyIIptA2aCefqktcaq mugZmU83SxPZPV0uAo61NFycoDNMToxFULb5W6dxzAEBR2gSvBzt/eWDB1kbiT7Z 4XK8sy97p2ABHbD6DH+8 =SNXg -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
