Simple Relay: random unknown UDP port in listen mode

changed milestone to %Tor: unspecified

added component::core tor/tor dns milestone::Tor: unspecified priority::medium reporter::elgo resolution::not a bug severity::normal status::closed tor-relay type::enhancement labels

That looks like a DNS client port. (Tor relays test their DNS-resolution configuration, even though they shouldn't be willing to perform DNS queries for clients.)

Sure, I thought that too, but if I do in my config file: DNSPort 0.0.0.0:8891

A random UDP port still spawns additionnaly.

I still don't really get the "client" part of you point. I mean, it's a listening socket intended for clients, ok, but... it should then honor DNSPort directive, shouldn't it?

Trac:
Username: elgo

Hi,

No one can explain this listening UDP socket?

Trac:
Username: elgo

No one can explain this listening UDP socket?

rransom could explain it! ;) And he did:

That looks like a DNS client port. (Tor relays test their DNS-resolution configuration, even though they shouldn't be willing to perform DNS queries for clients.)

Seriously, it probably is a DNS client port. Servers use it so that they can make DNS requests if they decide to.

The missing factor to understand is that a DNS client port is not the same as a DNSPort. One of them (the one you have, the one rransom is talking about) is for making DNS requests -- the other (configured by DNSPort) is for accepting DNS requests and relaying them onto the Tor network.

If this is still unclear, please feel free to ask more questions, here or on on help@rt.torproject.org

Trac:
Resolution: N/A to not a bug
Keywords: N/A deleted, tor-relay added
Milestone: N/A to Tor: unspecified
Status: new to closed

Ok, now I understand what is said (I wasn't sure at first), but I really, really, don't get it. Why on earth a software would need to open a listening ("server") socket to make a DNS request?? Seriously? Don't tell me this is not simpler to actually directly call the "callback function" behind this listening socket than open 2 sockets (the listening one and the one to communicate with it) to do a DNS request...

It seems pretty insane to me. :/

Don't get me wrong, I'm first trying to understand how Tor works, abd I'm not telling you what to do "your work" ;) But basically, I can't run a piece of software 24/24 on a 100Mbps node if I can't trust it.

Trac:
Username: elgo

My mistake if previous comment sounds "harsh", I didn't mean it this way. (plus many typos in it, sorry).

Trac:
Username: elgo

Someone set this Ticket as "closed", without further discussion on whether or not things could be done differently? Or if I'm wrong?

Meanwhile, reopened it as "enhancement", then.

Trac:
Username: elgo
Status: closed to reopened
Resolution: not a bug to N/A
Type: defect to enhancement

So here's how DNS and UDP work together here.

I want to make a DNS request. I'm going to send a DNS request in a UDP packet to a DNS server. That server is going to send me a response in another UDP packet.

But UDP isn't like TCP: UDP deals with datagrams, not streams. If I am going to receive any UDP response from the server, I need to have an open socket waiting for the UDP datagram to come back.

That socket will show up as listening: That's to be expected. It's willing to accept replies from multiple DNS servers, because it's willing to send requests to them.

I'm attaching a simple demonstration program in C. It makes a DNS request to one or two of Google's public nameservers, waits for an answer, then sleeps for a while so you can run netstat or lsof before it exits. If you run it as-is, then it uses "connect" to say that it only wants to talk to one nameserver. If you add "#define TWO_REQUESTS" at the top of the file, then it'll use the same socket to send a request to two nameservers, and wait for replies from both. In the first case, the program will show up as "connected"; in the second case, it will show up as "listening". But it's the same code in both cases: Send a UDP request, wait for a reply.

Trac:
udp-demo.c

Waaaw, that is quite an awesome answer :) Really many thanks for taking time to explain this to me. That is crystal clear now on the "how". Now, I have some questions about "why", but new ones ;)

So, in the "multiple_requests" scenario of Tor, you designed your DNS client like a sort of "deamon" and then never close this client DNS socket? Is it really worthy rather than opening 1:1 UDP socket to DNS servers? I mean, 1:1 UDP socket have the advantage of not accepting data from any source (which could not be a previously requested DNS server), compared to a "listening" UDP socket (I'm not considering the case of having a stateful FW in protecting Tor running box, I'm considering security matter of Tor itself). This random "listening UDP DNS client socket" has the disadvantage of being persistent through the whole "life" of Tor process, and is a new potential entry point to Tor (beyond ORPort and DirPort for a simple relay).

Trac:
Username: elgo

This raises four questions for me:

Why does Tor do its own DNS lookups, instead of using the system's resolver?
Why does a Tor relay need to do DNS lookups at all?
If Tor actually needs to do its own DNS lookups, shouldn't it be using a randomized source port for every query? (Otherwise it is relatively trivial to send it spoofed answers, no?)
Is it bad that my Tor relay where I just noticed this port (leading me to find this ticket) can only make TCP connections? It seems to be relaying traffic nonetheless, but now I'm worried perhaps I'm failing circuits to relays which only have DNS names in their descriptors? (Do such relays exist?)

Trac:
Keywords: tor-relay deleted, tor-relay dns added

Replying to cypherpunks:

Why does Tor do its own DNS lookups, instead of using the system's resolver?

The system's resolver, typically accessed through gethostbyname(), typically blocks while getting its answer. To use it without itself blocking, Tor would have to spawn separate threads, each of which blocks while getting its answer, and then queue up requests for the farm of dnsworkers so it doesn't launch hundreds or even thousands of threads in parallel. (Also, on systems where gethostbyname is not reentrant, it needs to spawn separate processes, not just threads.)

Tor actually used to do exactly this. It was no fun, so when Adam Langley wrote up some great asynchronous dns client code, we used it.

Why does a Tor relay need to do DNS lookups at all?

If a Tor client wants to visit cnn.com, she can't very well do the dns resolve herself -- otherwise anybody watching her network would know where she will soon anonymously go. So she sends "cnn.com" to the exit relay, which resolves it and connects.

If Tor actually needs to do its own DNS lookups, shouldn't it be using a randomized source port for every query? (Otherwise it is relatively trivial to send it spoofed answers, no?)

I hope it does. Please check.

Is it bad that my Tor relay where I just noticed this port (leading me to find this ticket) can only make TCP connections? It seems to be relaying traffic nonetheless, but now I'm worried perhaps I'm failing circuits to relays which only have DNS names in their descriptors? (Do such relays exist?)

If you're a non-exit relay, it's ok because typically clients will never ask you to do dns resolves for them. If you're an exit relay, yes it's bad.

Replying to arma: [...]

Why does a Tor relay need to do DNS lookups at all?

If a Tor client wants to visit cnn.com, she can't very well do the dns resolve herself -- otherwise anybody watching her network would know where she will soon anonymously go. So she sends "cnn.com" to the exit relay, which resolves it and connects.

Cypherpunks might be asking "why does a [non-exit] relay need to do DNS lookups". The answer is that they don't need to do DNS lookups for users at all -- and they refuse any requests that users make. The only lookups that were still happening were self-testing lookups, which we just fixed with the patch to bug #965 (moved).

I wonder if the #965 (moved) fix (which will go into 0.2.5.3-alpha) is sufficient to make us stop opening the UDP ports entirely. If not, another fix is in order.

If Tor actually needs to do its own DNS lookups, shouldn't it be using a randomized source port for every query? (Otherwise it is relatively trivial to send it spoofed answers, no?)

I hope it does. Please check.

I don't think we do; we use a hypervigilant version of the 0x20 trick instead. (We randomize case in outgoing requests, and treat a reply with correct port and trans_id but mismatched case as indicating an error, and cancel the request.)

I tried getting the randomized source port trick to work once, but the usual way of doing it would run exit nodes out of sockets pretty fast on hosts like OSX that are slow to release ports.

I'd be glad to take a patch for evdns in libevent, if we can limit the number of sockets to something less than "an unbounded number".

Is it bad that my Tor relay where I just noticed this port (leading me to find this ticket) can only make TCP connections? It seems to be relaying traffic nonetheless, but now I'm worried perhaps I'm failing circuits to relays which only have DNS names in their descriptors? (Do such relays exist?)

If you're a non-exit relay, it's ok because typically clients will never ask you to do dns resolves for them. If you're an exit relay, yes it's bad.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Resolution: N/A to not a bug
Status: reopened to closed
Reviewer: N/A to N/A

closed

moved to tpo/core/tor#8215 (closed)

Simple Relay: random unknown UDP port in listen mode

netstat -lpnut | grep tor

netstat -lpnut | grep tor

Child items ...

Activity