Opened 9 years ago

Last modified 3 years ago

#2455 needs_revision enhancement

Log IP of wrongly replying DNS-Server(s)

Reported by: bastik Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: DNS-Hijacking DNS-Provider dns tor-relay needs-libevent-patch
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Tor checks for DNS-Hijacking and reports that the DNS-Provider gave a result for a host that probably does not exist. The only change I request is that Tor is reporting the IP of the DNS-Provider.

Then Vidalia can add that information to the log file.

I got messages that Tor detected DNS-Hijacking and tried to confirm that by browsing to the host and trying to ping it. All that failed so I believed there would be a bug in Tor. As I looked for help on IRC, it turned out that there where multiple DNS-Providers and one was actually hijacking DNS-failures. The reason why the self-test did not show any hijack was that my system could reach the first DNS-Server all the time. Tor checks all DNS-Providers, which is absolutely correct, but it doesn't return which DNS-Providers hijack.

Child Tickets

Change History (11)

comment:1 Changed 9 years ago by nickm

Keywords: dns added
Milestone: Tor: 0.2.3.x-final

Our DNS backend doesn't currently let us know which server answered which request, so it might be a decent bit of work to implement this. Still, sounds like a decent idea. Assigning it to the 0.2.3.x milestone.

comment:2 Changed 9 years ago by arma

Summary: Report IP of replying DNS-Server(s) so that Vadalia can display them in the logReport IP of replying DNS-Server(s) so that Vidalia can display them in the log

comment:3 Changed 9 years ago by mikey

Status: newneeds_review

I based it on the 'master' branch of tor.
The DNS server IP is now logged for Hijacked attempts only and as such is never 'scrubbed'. That and additional logging can be adjusted now that the nameserver is available within the tor code. I don't quite understand the escaped() method, but it appeared unnecessary here since it's only the peer IP that is being added.

If acceptable -- how should this be propagated to the libevent API itself?

comment:4 Changed 9 years ago by nickm

Hm. There's some stuff about this that's going to be problematic.

First off, it *can't* get propagated into the Libevent API: It breaks the API. That is to say, every existing program that has been written to use the old Libevent evdns API would need to change. That's a non-starter: libevent doesn't take patches like that.

Second, it exposes a previously private type: the "struct nameserver" type is an implemenation detail of eventdns/evdns.c, and isn't supposed to be user-visible or user-modifiable.

The second issue is much easier to solve than the first: the right info to pass back would just be a "struct sockaddr *", which ought to be sufficient to identify the nameserver uniquely.

The first one is harder. All I can think of there is a new set of APIs. The alternatives (breaking backward compatibility, adding a flag that makes the callback signature secretly different) seem either undoable or too hackish. To avoid doing the new set of APIs of this type more than once, it might be a good idea to design them to be more extensible and future-proof.

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

Throwing this into tor: unspecified. It's too big to make it in for 0.2.3.x at this point. It's a good idea for a feature, but it will need revision as noted above for inclusion in any version of tor.

comment:6 Changed 8 years ago by nickm

Status: needs_reviewneeds_revision

comment:7 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:8 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:9 Changed 4 years ago by bastik

Severity: Normal
Summary: Report IP of replying DNS-Server(s) so that Vidalia can display them in the logLog IP of wrongly replying DNS-Server(s)

(Took Vidalia out of the Summary)

comment:10 Changed 3 years ago by nickm

Keywords: needs-libevent-patch added

comment:11 Changed 3 years ago by nickm

We can't do this with evdns as it stands; we'd have to replace it with something else, or extend it and do this as people upgrade their libevents.

Note: See TracTickets for help on using tickets.