Maintained by: NLnet Labs

[Unbound-users] error: tcp connect: No route to host

W.C.A. Wijngaards
Thu Jan 13 12:04:21 CET 2011


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

Hi Dotfish,

It would be interesting to hear from others, as I do not have experience
with connection failures.

On 01/10/2011 06:00 AM, Babu C wrote:
> I am  running unbound for a year and found its very useful to speedup
> browsing for my network and its users. 

Thanks :-)

> I have recently upgraded my OS and Unbound, since then I am facing a
> particular problem, when the ADSL connection goes down and come back
> Unbound refuses to resolve the queries till I restart Unbound. I never
> faced this issue with previous unbound version. I tried googling
> and couldn't find any thing to mitigate my problem.
> 
> OS - FreeBSD 8.1
> Unbound :  Unbound 1.4.7

Since unbound 1.4.7 there is a change in the timout code, blog here:
http://www.unbound.net/documentation/info_timeout.html

It means that if the issue was longer than a couple of minutes, unbound
will start to probe once every 15 minutes.  You would have to wait for
(up to) 15 minutes (per domain) before unbound notices the link coming
up again.  You likely did not want to wait and the restart cleared the
timers.  (there is also the flush_infra all command in 1.4.7 if you do
not want to lose the other cache contents).

If you experience these issues more frequently ( :-( ), you could
consider the config option:  infra-host-ttl: 60
(or another value lower than the default 900 seconds).  This makes
unbound forget the connection problem, or retry a destination sooner.
It would likely cause unbound to come back up after a minute or so, if
you experience another outage.

> When I started noticing this issue, I increased the verbosity to 3 in
> unbound.conf and found the following error logged 
> unbound: [847:1] error: tcp connect: No route to host
> Kindly help me to resolve this issue

FreeBSD tells unbound that the connect(2) syscall gets the errno: No
route to host, when it (in desperation?) tries to connect over TCP to a
remote nameserver.  Look at the route table (netstat -r).  Likely your
connection is down and the upstream route is withdrawn?  Or is this a
different problem?

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0u3DUACgkQkDLqNwOhpPjoogCfaQ0PTHTO9C4HgX5b/AolTCLc
JwEAn25mYSL6ktmJfp9pZIse6p4Wz3Jj
=Bs7/
-----END PGP SIGNATURE-----