Opened 6 years ago

Closed 4 months ago

#3056 closed defect (implemented)

surprising dns responses received from hosts that aren't our resolver

Reported by: freeeveryone4ever Owned by: nickm
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version: Tor: 0.2.3.10-alpha
Severity: Normal Keywords: libevent, eventdns, tor-relay, logging, review-group-18
Cc: ln5 Actual Points: 0
Parent ID: Points: 2
Reviewer: Sponsor:

Description

This is my first ticket, so bear with me pls.  On IRC "Sebastian" asked me to file a bug report

I'm using tor 2.2.25-alpha, vidalia 0.2.12
debian squeeze/wheezy, Linux kernel 2.6.38-2-686
I run a relay and allow all exit policies normally.
Run from residential cable modem, timewarner/brighthouse/roadrunner.
iptables and guarddog firewall with many recommended ports open.

this is my torrc:
# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it

ContactInfo xxx
ControlPort 9051
DirPort 9030
HashedControlPassword 16:C87CFFBB8A7A0E6C60762C632961A38C9528FF12E165B8D691F55BE104
Log notice stdout
Nickname freeeveryone4ever
ORPort 9001
RelayBandwidthBurst 393216
RelayBandwidthRate 196608

my error msgs:
"eventdns: Address mismatch on received DNS packet. Apparent source was 10.10.7.2xx:5300"

I also get this msg every 10-30 mins: "[Warning] eventdns: All nameservers have failed" they come backup within a min or 2

also get this, for what it's worth:
"DNS Hijacking Detected - Tor detected that your DNS provider is providing false responses for domains that do not exist. Some ISPs and other DNS providers, such as OpenDNS, are known to do this in order to display their own search or advertising pages."

Tor seems to keep working, I just thought you'd want to know about these messages.

Thanks, freeeveryone4ever (also my relay name)

ps. let me know if you need more info.

Child Tickets

Change History (17)

comment:1 Changed 6 years ago by nickm

Milestone: Tor: unspecified
Status: newneeds_information

Ow; sorry for the delay!

If you're still around, and this is still happening, I *think* it probably has something to do with your network configuration. Your best bet is probably to install a caching name server locally, and use that for your nameserver instead of your ISPs' nameservers -- they seem to be really flaky.

Based on available information, this doesn't currently look like a bug in Tor.

comment:2 Changed 6 years ago by torland

Version: Tor: unspecifiedTor: 0.2.3.10-alpha

I am seeing this message as well although I am running a local DNS cache with 0.2.3.10-alpha. If I could help to shed some light on it I would be happy. My nodes get some traffic and till now the message comes up on two of them. Here is a grep of what came up so far

tor1/notices.log:Dec 19 21:10:08.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:37284
tor1/notices.log:Dec 19 21:10:11.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:37284
tor1/notices.log:Dec 20 00:32:10.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 95.34.158.40:41608
tor1/notices.log:Dec 20 00:32:13.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 95.34.158.40:41608
tor1/notices.log:Dec 20 06:51:24.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:41730
tor1/notices.log:Dec 20 06:51:27.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:41730
tor1/notices.log:Dec 21 12:43:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:34434
tor1/notices.log:Dec 21 12:43:51.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:34434
tor1/notices.log:Dec 22 20:38:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:38017
tor1/notices.log:Dec 22 20:38:51.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:38017
tor1/notices.log:Dec 24 00:35:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:42995
tor1/notices.log:Dec 24 00:35:51.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 68.184.34.91:42995
tor3/notices.log:Dec 17 14:44:14.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 189.164.17.39:10030
tor3/notices.log:Dec 17 15:09:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 186.221.32.139:2055
tor3/notices.log:Dec 17 16:35:14.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 86.145.221.146:1024
tor3/notices.log:Dec 17 16:35:45.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 86.145.221.146:1024
tor3/notices.log:Dec 17 16:43:27.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 24.184.190.153:47928
tor3/notices.log:Dec 17 17:19:22.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 86.145.221.146:1024
tor3/notices.log:Dec 17 17:59:25.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 83.26.139.226:6881
tor3/notices.log:Dec 17 21:49:25.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 188.191.66.10:54811
tor3/notices.log:Dec 17 23:03:20.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 67.139.190.222:64612
tor3/notices.log:Dec 18 13:10:48.000 [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 112.198.147.92:443

comment:3 Changed 5 years ago by nickm

Keywords: tor-relay added

comment:4 Changed 5 years ago by nickm

Component: Tor RelayTor

comment:5 Changed 4 years ago by ln5

Cc: ln5 added

FWIW, I see this a lot on busy exits.

From looking at libevent code it seems to indicate that a packet was received on the socket opened for DNS queries/responses from a host that is not the configured resolver. Looking at the "apparent source" in my logs, as well as torland's above, hints that these are indeed not from configured resolvers.

I guess it might be DNS queries with a spoofed source address. Haven't looked at any content.

Anyhow, seeing lots of IP addresses that are not my own in the log files of an exit makes me cringe. Should we suppress the log message altogether?

comment:6 Changed 3 years ago by arma

Linus: we could suppress the log message altogether. But I wonder if this complaint is actually useful for relay operators who have misconfigured their /etc/resolv.conf lines, or otherwise are going to fail to do dns queries?

comment:7 Changed 3 years ago by ln5

If Tor can provide "Your DNS configuration is broken." without too much false positives that might be helpful. Source address and port of incoming packets shouldn't be necessary.

comment:8 Changed 5 months ago by nickm

Keywords: logging added
Points: 2
Severity: Normal

Our solution here should probably be to rate-limit the message and scrub the IP, while making it clear that the actual problem is "these are indeed not from configured resolvers"

comment:9 Changed 5 months ago by nickm

Actual Points: 0
Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Status: needs_informationneeds_review

See my branch bug3056. It just rate-limits the message, rewrites it, and tries to apply SafeLogging.

I'm not sure SafeLogging is correct here -- these are the IP addresses of our apparent DNS spoofers, not of our clients

comment:10 Changed 5 months ago by arma

Summary: tor/vidalia, debian libevent-2.0-5 eventdns: Address mismatch? etc.surprising dns responses received from hosts that aren't our resolver

comment:11 Changed 4 months ago by nickm

Keywords: review-group-18 added

comment:12 Changed 4 months ago by nickm

Owner: set to nickm
Status: needs_reviewassigned

setting owner

comment:13 Changed 4 months ago by nickm

Status: assignedneeds_review

comment:14 Changed 4 months ago by ahf

Status: needs_reviewneeds_revision

Looks like the return value m from rate_limit_log() is never deallocated after the call to tor_log(). Otherwise looks good!

comment:15 Changed 4 months ago by nickm

Status: needs_revisionneeds_review

I've added a fixup commit. Better now?

comment:16 Changed 4 months ago by ahf

Status: needs_reviewmerge_ready

Yes! LGTM.

comment:17 Changed 4 months ago by nickm

Resolution: implemented
Status: merge_readyclosed

squashed and merging; thanks!

Note: See TracTickets for help on using tickets.