Opened 6 years ago

Closed 2 years ago

#11600 closed defect (duplicate)

Strange nameserver fail warning in Tor log

Reported by: s7r Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.6.10
Severity: Normal Keywords: eventdns, libevent
Cc: sysfu Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I am running an exit relay on Linux, my Tor version is 0.2.4.21

I checked the log and found this strange warnings:
Apr 24 15:14:07.000 [notice] Circuit handshake stats since last time: 91698/91698 TAP, 15988/15988 NTor.
Apr 24 17:40:45.000 [warn] eventdns: All nameservers have failed
Apr 24 17:40:45.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:01:51.000 [warn] eventdns: All nameservers have failed
Apr 24 18:01:51.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 18:01:52.000 [warn] eventdns: All nameservers have failed
Apr 24 18:01:53.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:02:00.000 [warn] eventdns: All nameservers have failed
Apr 24 18:02:01.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:02:01.000 [warn] eventdns: All nameservers have failed
Apr 24 18:02:01.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 19:46:22.000 [warn] eventdns: All nameservers have failed
Apr 24 19:46:22.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 20:46:25.000 [warn] eventdns: All nameservers have failed
Apr 24 20:46:25.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 21:14:07.000 [notice] Heartbeat: Tor's uptime is 8 days 12:00 hours, with 13940 circuits open. I've sent 549.49 GB and received 543.20 GB.

So I thought it's the fault of the nameservers provided by the ISP. Fair enough, I have configured my own resolver on localhost (where the relay is running) using BIND 9.10 (latest stable) with dnssec-validation and everything. I thought I fixed it. After some time, I checked the logs again and:
Apr 24 23:26:03.000 [warn] eventdns: All nameservers have failed
Apr 24 23:26:03.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:02.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:02.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:03.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:04.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:04.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:05.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:06.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:06.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:08.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:08.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up

Looks like its something Tor related. Why do I get this warning? Does this have any penalty on the performance or over the users who are using this node as an exit point? Should I just leave it alone as it works fine? From what I see nameservers fail and get back online immediately, fail and back on have same timestamp. Advices? Thanks in advance.

Child Tickets

Change History (11)

comment:1 Changed 6 years ago by s7r

Sorry, rectification - the operating system is FreeBSD 10.0 running Tor 0.2.4.21.

comment:2 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.???

comment:3 Changed 5 years ago by sysfu

Cc: sysfu added

comment:4 Changed 5 years ago by sysfu

Experience this issue regularly in the logs of an exit node as well.

Environment:
OpenBSD 5.6 - all patches
Tor 0.2.5.10
Libevent 1.4.14b-stable
Zlib 1.2.3
LibreSSL 2.1.4
Unbound 1.4.22

comment:5 Changed 5 years ago by sysfu

Keywords: eventdns libevent added

comment:6 Changed 4 years ago by hdqdak8v32aor

Version: Tor: 0.2.4.21Tor: 0.2.6.10

traced and nailed it down: the leading "dot" character is not valid

Sep 14 02:08:11.275 [info] launch_resolve(): Launching eventdns request for ".quikr.com"
Sep 14 02:08:11.275 [info] evdns_log_cb(): eventdns: Resolve requested.
Sep 14 02:08:11.275 [info] eventdns: Setting timeout for request 0x7fcf5c2cd4d0, sent to nameserver 0x7fcf5a1ce460
Sep 14 02:08:11.275 [info] eventdns: Nameserver 127.0.0.1:53 has failed: Bad response 5 (refused)
Sep 14 02:08:11.275 [warn] eventdns: All nameservers have failed
Sep 14 02:08:11.275 [info] eventdns: Removing timeout for request 0x7fcf5c2cd4d0
Sep 14 02:08:11.275 [info] launch_resolve(): Launching eventdns request for "cdn.syndication.twitter.com"
Sep 14 02:08:11.275 [info] evdns_log_cb(): eventdns: Resolve requested.
Sep 14 02:08:11.275 [info] eventdns: Setting timeout for request 0x7fcf5cbdcc80, sent to nameserver 0x7fcf5a1ce460
Sep 14 02:08:11.278 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Sep 14 02:08:11.278 [info] eventdns: Removing timeout for request 0x7fcf5cbdcc80
$ dig +short ".quikr.com"
dig: '.quikr.com' is not a legal name (unexpected end of input)
$ dig +short "quikr.com"
80.157.151.19
80.157.151.57

comment:7 Changed 4 years ago by hdqdak8v32aor

Severity: Normal

Became concerned awhile back that even the brief time in state

All nameservers have failed

is harmful. Reviewed the code and determined that when only one nameserver is configured nothing happens as a consequence of the state. Outstanding requests complete successfully and the only effect is /var/log/messages noise.

In the case where multiple nameservers are active, outstanding resolver requests on the path where the Bad response 5 appears are cancelled / ignored and resubmitted to a different name server. Somewhat disruptive, especially when resolvers are remote instead of local.

In the case where a local copy of unbound is running, stick with one /etc/resolve.conf entry as configuring a second will degrade performance.

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Resolution: duplicate
Status: newclosed

Duplicate of #1936

Note: See TracTickets for help on using tickets.