"All nameservers have failed" eventdns message

[varnav]

The symptom is messages appearing in the log after some uptime, usually several days:

Sep 11 10:42:30.665 [warn] eventdns: All nameservers have failed
Sep 11 10:42:39.684 [notice] eventdns: Nameserver 4.2.2.1 is back up
Sep 13 08:56:58.089 [warn] eventdns: All nameservers have failed
Sep 13 08:57:01.788 [notice] eventdns: Nameserver 4.2.2.1 is back up
Sep 13 08:57:03.089 [warn] eventdns: All nameservers have failed
Sep 13 08:57:12.396 [notice] eventdns: Nameserver 4.2.2.2 is back up

After that tor process usually terminates without warning.

There are numerous reports about this issue on the net, just if you try to google that log message.

[nickm]

This happens less with more recent eventdns versions, as included with recent 0.2.2.x-alpha versions, though I don't know whether we've got it completely solved in 0.2.2.x or not. I'm putting this one in "unspecified"; if it recurs with recent 0.2.2.x (or worse, with 02.3.x using Libevent 2.0.9's eventdns code) and we can track down what's going on, we should up the priority, call it a libevent bug, or both.

[arma]

Replying to varnav:

After that tor process usually terminates without warning.

I don't know of any crash or assert bugs associated with these log messages. My guess is that's something different.

Does it still happen on Tor 0.2.1.27?

[cypherpunks]

HI,

Running Tor v0.2.1.30. I got the same problem today.
Warning eventdns: All nameservers have failed
Warning eventdns: Nameserver 198.168.0.1is backup.

Tor works fine for me.

[pem10777]

Whats Up Varnav. I too get the Warning eventdns: All nameservers have failed and my network is running fine but I managed to pinpoint the problem to a few things. It's either an overload of the system. My router is cross connecting and can't handle the load, one of my network files is configure wrong or my ISP is kicking me off do to the increase of traffic to their network. Don't know yet? These are just my theories. I don't know what operating system you are running on but I'm on Ubuntu 10.10. Linux version 2.6.35-28-generic I'm also running the latest Tor Bundle for Linux. Anyways, here is the link I used to get an idea of what my network is doing.
​http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch04_:_Simple_Network_Troubleshooting
Hope it helps. Once I solved this problem I will post it.
Peace out
Pem10777

[pem10777]

What up Varnav. Still working on this problem and getting a bit closer every day. Here is a tool that you might find helpful. Go to the bottom of this site ​http://www.atagar.com/arm/ download it and run it. It will ask you for a password. Its the password you set up when you started your relay. If you are running vidalia go to settings advanced section and un-click the Randomly Generate. Authentication should be set to password and then make up your password. Click ok and you are done. Go to terminal type in arm and then the password and you are money.

[torland]

I am seeing these annoying messages too. They come up every 1-2 minutes and are filling up my logs.

I am running the latest dev version on Debian Squeeze. Binaries are self compiled with libevent 2.0 and openssl 1.0.0. As local DNS cache is ubound running which forwards DNS to google public DNS. ubound is configured with 16 threads. I don't think that DNS is screwed up in my case.

[torland]

One more thing: the message comes always as

13:10:25 [WARN] eventdns: All nameservers have failed
13:10:25 [NOTICE] eventdns: Nameserver 127.0.0.1:53 is back up

between the failure and recover are only a couple of milliseconds

[alt255]

I've encountered this bug, but I've "resolved" it by changing DNS.
On Linux it is /etc/resolv.conf but in my case I installed my own DNS "cache" using DJBDNS ​http://cr.yp.to/djbdns.html

The message has since disappeared from the logs. If others can confirm, I guess this could be perhaps pointed at in the FAQs...?

I think it happens when your DNS is either:

• too slow (if you're using a home router that can't keep up), or
• has some form of rate-limiting

[hdqdak8v32aor]

The issue could be as described above or alternately could be the result of malformed DNS requests as described in bug #11600 comment 6.

[nickm]

We've done a lot of work to clean this up over the years; whatever's going on here, it is different now than it was 3 years ago.