[Unbound-users] Query over 'forward-addr' / 'forward-first'

[W.C.A. Wijngaards]

-----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"
> <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,
> 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-----