Maintained by: NLnet Labs

[Unbound-users] 'SERVFAIL' reply from forwarder leads to query storm?

W.C.A. Wijngaards
Tue Jul 31 15:10:42 CEST 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Karl,

Format error?  The 206.188.198.53 server is a public server and it
generates format errors, dig works, but dig +dnssec produces some sort
of fake upward delegation to appear lame.

The BIND server responds with servfail.  Unbound tries the servers
before going to the authorities, it exhausts all the options before it
goes to the authorities.  Thus it elicits servfail (several times)
from  all of the available servers before it moves to the fallback
authority option.  This is likely what happens here?

Found a bug in forward-first setting of the RD flag, though (and fixed
it).

Best regards,
   Wouter

On 07/26/2012 03:59 PM, Karl Pielorz wrote:
> 
> Hi,
> 
> We're running unbound 1.4.17 under FreeBSD 9. Unbound is setup as
> a simple 'forwarder' to our BIND 9 recursive servers, i.e.
> 
> " forward-zone: name: "." forward-addr: 1.1.1.1 forward-addr:
> 2.2.2.2 forward-first: yes "
> 
> This works, but appears to have issues for 'malformed' / invalid
> domains.
> 
> For example - if the client goes to query "MX for hayoo.com"
> (probably a typo of 'yahoo.com') - we see Unbound forward it to the
> first forwarder, which is running BIND - that server logs:
> 
> " 26-Jul-2012 14:16:34.864 resolver: notice: DNS format error from 
> 206.188.198.53#53 resolving hayoo.com/MX for client 3.3.3.3#7582: 
> invalid response "
> 
> This results in BIND returning 'SERVFAIL'. Fair enough.
> 
> Unbound then tries the second forwarder - which again logs
> 'invalid response' - and sends back SERVFAIL.
> 
> At this point - the original client request returns with 'SERVFAIL'
> (as you'd kind of hope / expect).
> 
> However - 'in background' Unbound keeps trying each forwarder in
> turn at great lengths, trying to get the query resolved e.g.
> running the above -single lookup looking at the log output for
> unbound gives:
> 
> " Jul 26 14:38:46 host unbound: [85689:0] info: response for
> hayoo.com. MX IN Jul 26 14:38:46 host unbound: [85689:0] info:
> reply from <.> 1.1.1.1#53 Jul 26 14:38:46 host unbound: [85689:0]
> info: query response was THROWAWAY Jul 26 14:38:46 host unbound:
> [85689:0] info: response for hayoo.com. MX IN Jul 26 14:38:46 host
> unbound: [85689:0] info: reply from <.> 2.2.2.2#53 Jul 26 14:38:46
> host unbound: [85689:0] info: query response was THROWAWAY Jul 26
> 14:38:46 host unbound: [85689:0] info: response for hayoo.com. MX
> IN Jul 26 14:38:46 host unbound: [85689:0] info: reply from <.>
> 1.1.1.1#53 Jul 26 14:38:46 host unbound: [85689:0] info: query
> response was THROWAWAY ... "
> 
> This goes on for many hundreds of lines (for the example above a
> single 'dig MX hayoo.com' on the host resulted in nearly 1000 lines
> logged - nearly all were logged after the initial dig returned
> indicating 'SERVFAIL').
> 
> Is there any way to stop Unbound from "rattling" around the
> forwarders over and over at great speed in this situation?
> 
> Thanks,
> 
> -Karl _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQF9lSAAoJEJ9vHC1+BF+NRDwP+wT4CkyUTbYb5XRRzo2XMBFd
boCONyUIDztRqm6YMkDcyZ4ebE6dknM/k+QKP+CF8Pw1POMvmekwxUEeor+7f8tO
wVdNfUrlmfUelFz4DEBxa4oDgFii0728Vd4acFxGoO3Bu0IwfvNHO1BQiPMnjpIl
xec/MNxRBV5Fy67xRTKTDuBzJsLTb5ji0BuPV7+EigWjYqrpZZ2ZlqYIJCZSl6Us
5xY/NZKf9VmAUu801g2sJ1cM3fGuvE0LcmgWLd6SOQfrnUkOP45IbqWnyQMZKEEs
HeIiQ3K8tJm2FNmqG/lIma2obgxTjdjYS8pwRop/oRBM9kVOdwqwB1GONY3jvKRO
g9GbOxFm73etnqYHRfwzhlg0t6WPax/7zY0mwtOFNmSscVlF1H7/9PJv+WfH5cvQ
+O/hFGnpKc918/VzCxNHrWwGKysOcn6sC8wcjXB6U5ePcJRbUKIkqHCwjmoPql4f
DCGDbhKyH8ENXVVqBdDRuoLvOc/7uAu5vSeHQwrzIyxRbPIc3v138p2C8PHHDrlV
bXxiZPRuSNNOEX9ckGP4Lrq8QYuhOUGA6StLs6djqU4H4v7Al1sZXHvDWE3JWk9h
CNmYQZ6mtzAgiqad8A7hqq+jFXzhK3639I43d2Ie9M4lMw6SrjrYpRrBJWT/2yT9
z+JFsjl5BULBTxSXOMoA
=oETH
-----END PGP SIGNATURE-----