Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:47:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32315Can't perform reverse DNS lookup for a (binary) IPv6 address2020-06-13T15:47:35ZTracCan't perform reverse DNS lookup for a (binary) IPv6 addressTor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument ...Tor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument which can either be a binary IPv4 or IPv6 address, or an ASCII string.
Somewhat contrary to ticket #32314, this command works for IPv6 addresses only if the address is specified as an ASCII string (address type 3) with no brackets. If the address is specified in binary (address type 4), or as a string enclosed in brackets, Tor will reject it.
**Trac**:
**Username**: liberatTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28772DNS resolver at DNSPort stops working after some time, while tor is working. ...2020-06-13T15:35:20ZTracDNS resolver at DNSPort stops working after some time, while tor is working. Only restart helps.Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort o...Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort option and route all my DNS traffic to it. After tor is connected, it is working well, but after some time (2-5-10 hours), it stop to work and return no IP address to any DNS request, while the tor itself continue working, log don't show anything relevant. DNS requests resolve only internally through socks port.
This happens many years to me, and only restarting tor helps to get my DNS back.
I even tried to open multiple DNSresolvers, like
DNSPort 127.0.0.2:53
DNSPort 127.0.0.3:53
DNSPort 127.0.0.4:53
and put them all to /etc/resolv.conf, and it helped to keep it running more long, but anyway after some time they all stops resolving.
On android I have the same issue. I rerouted all DNS traffic to it, and after some hours only restarting to service works. I even thought to write some script, if domain fails to resolve, restart to service...
Please help! DNSPort resolver must recreate it's circuits if they fails. and don't wait for hard reset.
Thank you!
**Trac**:
**Username**: toruser787Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23113Manage DNS state better when "All nameservers have failed"2020-06-13T15:12:26ZteorManage DNS state better when "All nameservers have failed"We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server ch...We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server choices: for example, avoiding using a local cache in favour of remote resolvers.
Sometimes changing the local resolver makes a difference:
https://trac.torproject.org/projects/tor/ticket/1936#comment:12
Sometimes it happens in response to malformed requests:
https://trac.torproject.org/projects/tor/ticket/11600#comment:6
Sometimes it's harmless:
https://trac.torproject.org/projects/tor/ticket/11600#comment:7
Because it's followed by:
```
[notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21989Should we tell Exits to reject all traffic if DNS fails?2020-06-13T15:08:00ZteorShould we tell Exits to reject all traffic if DNS fails?Tor Exits with broken DNS still allow Exit traffic.
But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)
Perhaps we should make Exits refuse traffic until th...Tor Exits with broken DNS still allow Exit traffic.
But this slows down initial connections for clients, because the Exit will refuse all DNS requests. (Clients no longer cache DNS.)
Perhaps we should make Exits refuse traffic until their DNS is working?
(Unless a non-default option is set?)
This would also fix #21900, where a broken DNS config really does stop all Exit traffic.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21902evdns adds default DNS servers, but chutney wants a consistent environment2020-06-13T15:07:45Zteorevdns adds default DNS servers, but chutney wants a consistent environmentWhen we test tor exits using chutney, we want a consistent network environment, so that tests pass or fail reliably.
This means that we want to be able to configure exits with no DNS servers, and have them only connect to IP addresses.
...When we test tor exits using chutney, we want a consistent network environment, so that tests pass or fail reliably.
This means that we want to be able to configure exits with no DNS servers, and have them only connect to IP addresses.
But evdns adds default name server(s) in some circumstances (for example, 127.0.0.1:53.)
This default could also be an issue on an IPv6-only system, where we'd want [::1]:53. (Yes, some IPv6-only systems don't even have an IPv4 localhost!)
This is also broken because of the empty/missing resolv.conf behaviour in #21900.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21900evdns fails when resolv.conf is missing, but succeeds when resolv.conf is empty2020-06-13T15:07:44Zteorevdns fails when resolv.conf is missing, but succeeds when resolv.conf is emptyWhen tor's ServerDNSResolvConfFile (default /etc/resolv.conf) is missing, evdns does not add any name servers, and therefore Exits do not allow any exit traffic (not even IP-based traffic):
```
[debug] configure_nameservers: stat()ing /e...When tor's ServerDNSResolvConfFile (default /etc/resolv.conf) is missing, evdns does not add any name servers, and therefore Exits do not allow any exit traffic (not even IP-based traffic):
```
[debug] configure_nameservers: stat()ing /etc/resolv.conf
[warn] Unable to stat resolver configuration in '/etc/resolv.conf': No such file or directory
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
```
This happens on macOS when the network is down. On macOS, /etc/resolv.conf is symlinked to /var/run/resolv.conf. When the network is down, macOS deletes /var/run/resolv.conf, so the stat() call on /etc/resolv.conf fails.
But when tor's ServerDNSResolvConfFile is empty, evdns adds a default name server (127.0.0.1:53 on my macOS), and therefore Exits allow exit traffic:
```
[info] eventdns: Parsing resolv.conf file /dev/null
[info] eventdns: Added nameserver 127.0.0.1:53 as 0x615000009e00
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
[info] eventdns: Parsing resolv.conf file /dev/null
...
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers back
```
We should also stop the extra descriptor upload:
```
[info] mark_my_descriptor_dirty: Decided to publish new relay descriptor: dns resolvers failed
```Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/21499client_dns_incr_failures while passing not hostname but only IP2020-06-13T15:06:28ZTracclient_dns_incr_failures while passing not hostname but only IPI frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [...I frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:22.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:30.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:45.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:47.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
**Trac**:
**Username**: acceleraTorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20555Stream isolation for DNS2020-06-13T15:02:52ZadrelanosStream isolation for DNSSeems like Tor's DNS cache (`CacheIPv4DNS`, `CacheIPv6DNS`) and caching of hidden service descriptors is cached globally.
The first connection in stream one resolves all DNS or hidden service descriptors. But follow up connections in se...Seems like Tor's DNS cache (`CacheIPv4DNS`, `CacheIPv6DNS`) and caching of hidden service descriptors is cached globally.
The first connection in stream one resolves all DNS or hidden service descriptors. But follow up connections in separate streams to the same website do not resolve and use Tor's cache.
So webservers could provide a slightly unique version of their website per visitor. Each visitors browser could be instructed to load additional content from varying hostnames. Due to caching vs non-caching it might be possible to make visitors pseudonymous rather than anonymous.
The problem is that Tor's cache is global and not stream isolated.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19859Expose stream isolation information to controllers2020-06-13T14:59:57ZNick MathewsonExpose stream isolation information to controllersSee the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming...See the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming streams so they know which streams need to be isolated from which other streams.
Semantically, this is a little tricky. The underlying rule that Tor implements is that each stream has a tuple of attributes (A_1, A_2... A_n), and a bit field (b_1, b_2... b_n). Two streams S_a and S_b may share the same circuit iff, for every i such that the OR of their b_i values is true, they have the same A_i value.
Note that this is not transitive: Stream S_a may be able to share a circuit with S_b or S_c, even if S_b cannot share with S_c. Worse
Should we (1) expose these attribute tuples and bitfields and require controllers to manipulate them correctly? That seems obnoxious and error-prone.
Or should we (2) allow controllers to ask questions like "may stream A share a circuit with stream B?" Or "what streams may A share a circuit with?" This might lead to O(n) queries, and it will still be error-prone because of the non-transitivity issue.
Or would it be better to (3) oversimplify the system above and provide each stream a 'cookie' such that any two streams with the same cookie may definitely share the same circuit? But this is problematic, and will overestimate how much isolation we need.
My current best idea is that (4) we should provide an operation of the form "make stream A have the same isolation properties as stream B". And possibly "make circuit C have isolation properties as if it had been used by stream A". So we don't expose isolation information, we just expose a way to manipulate it.
Or maybe there's a further clever way I'm not even thinking about just now.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19853ServerDNSAllowNonRFC953Hostnames affects clients, and AllowNonRFC953Hostnames...2020-06-13T14:59:55ZteorServerDNSAllowNonRFC953Hostnames affects clients, and AllowNonRFC953Hostnames affects serversIt looks like the code and man page entry for ServerDNSAllowNonRFC953Hostnames was copied straight from AllowNonRFC953Hostnames, which is the equivalent client option.
I think this is ok as-is, because even though both options affect bo...It looks like the code and man page entry for ServerDNSAllowNonRFC953Hostnames was copied straight from AllowNonRFC953Hostnames, which is the equivalent client option.
I think this is ok as-is, because even though both options affect both client and server, tor instances typically only run as clients or servers, not both.
However, the manual page entries could be updated to clarify that the options are synonyms, and affect both clients and exits.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19769Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)2020-06-13T14:59:48ZteorRound down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)In #19025, we fix a bug that prevented exits sending DNS TTLs to clients for IPv4 and IPv6 addresses.
But we don't want to have too many potential values for these TTLs, to avoid tagging attacks.
So I propose
* Exits round down (trunca...In #19025, we fix a bug that prevented exits sending DNS TTLs to clients for IPv4 and IPv6 addresses.
But we don't want to have too many potential values for these TTLs, to avoid tagging attacks.
So I propose
* Exits round down (truncate) the TTL received from the DNS server, and
* Clients round down the TTL received from the Exit,
to the nearest of:
* MIN_DNS_TTL (1 minute), or
* DEFAULT_DNS_TTL (30, 60, 90, 120, 150, 180 minutes)
MAX_DNS_TTL is 3 hours, so there are only 7 possible values for the TTL.
I chose to round down because that way, Tor DNS TTLs are only ever shorter than the lifetime specified by the DNS server.
I don't think we need to add noise to the TTL received from either the DNS server or Exit. I can't see the value in randomising it, and allowing randomisation could hide a tagging attack.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19025Exit relays always return DNS TTL 60 to tor clients2020-06-13T14:59:48ZPhilipp Winterphw@torproject.orgExit relays always return DNS TTL 60 to tor clientsWhen tor clients resolve a domain name, exit relays are supposed to [return the DNS TTL as part of their response](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1345).
At the moment, it looks like exit relays always retur...When tor clients resolve a domain name, exit relays are supposed to [return the DNS TTL as part of their response](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1345).
At the moment, it looks like exit relays always return TTL 0 for both A and AAAA records. Only PTR records seem to come with a TTL > 0. The relevant variables on the exit side are `ttl_ipv4` and `ttl_ipv6` in [src/or/dns_structs.h](https://gitweb.torproject.org/tor.git/tree/src/or/dns_structs.h#n80). The variables should be initialised in the function [cached_resolve_add_answer](https://gitweb.torproject.org/tor.git/tree/src/or/dns.c#n324). The variable `ttl_hostname` for PTR records is assigned `ttl`:
```
resolve->ttl_hostname = ttl;
```
The variables `ttl_ipv4` and `ttl_ipv6`, however, are not. Therefore, exit relays always send back TTL 60 to clients (60 instead of 0 because the function [dns_clip_ttl](https://gitweb.torproject.org/tor.git/tree/src/or/dns.c#n262) turns it into `MIN_DNS_TTL`, i.e., 60).
Commit [2889bd264](https://gitweb.torproject.org/tor.git/commit/?id=2889bd2642ada3a2aa55fa4909825dfb7e90812e) added the code to tor. It added `ttl_hostname`, `ttl_ipv4` and `ttl_ipv6`, but never initialised the latter two. I wonder if this is an oversight? Commit [c660a0f6](https://gitweb.torproject.org/tor.git/commit/?id=c660a0f6a2875a8b9b612f28a7f752b3ca8eb5da) talks about potential attacks, but I don't think that explains this issue.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18710dnsserv.c asserts when no supported questions are requested2020-06-13T14:55:59ZTracdnsserv.c asserts when no supported questions are requestedThe patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questio...The patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questions[i];" to the for loop ensures that "q" is always set to the first question, even if it's unsupported. In which case, the "if (!q)" check for NOTIMPL is dead code. Ultimately, you will eventually hit the "tor_assert" that was added to the "else" branch. Additionally, the "switch" block switches on "req->questions[i]->type", but the assignment to "supported_q" is "q" (which is always the first question) instead of "req->questions[i]", so it doesn't actually pick the first supported question -- it always picks the first question.
**Trac**:
**Username**: geekmugTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18642Teach the OOM handler about the DNS cache2020-06-13T14:55:40ZNick MathewsonTeach the OOM handler about the DNS cacheTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18580exit relay fails with 'unbound' DNS resolver when lots of requests time-out2020-06-13T17:34:27ZDhalgrenexit relay fails with 'unbound' DNS resolver when lots of requests time-outper
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/piperma...per
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/pipermail/tor-relays/2016-March/008918.html
Relay daemon ceases to service Tor Browser requests, timing out, when a local instance of 'unbound' is the DNS resolver and large numbers of DNS requests time-out.
Works fine when 'named' is swapped in place of 'unbound'.
GoDaddy DNS stops responding when large numbers of queries are submitted and this was observed as the particular trigger.
To reproduce, configure the SOA+NS records for several thousand dummy domains to point to a non-responding IP, then generate large numbers of requests against them.
The commands
unbound-control dump_requestlist
unbound-control dump_infra
are helpful for identifying the state.
Have debug-level daemon trace taken when relay was in the unresponsive condition described.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18037Should the user be allowed to specify FQDNs for HS TARGETs?2020-06-13T14:53:22ZYawning AngelShould the user be allowed to specify FQDNs for HS TARGETs?Spinoff of #18029.
The current behavior is to accept any of a raw port, IP address + port, or FQDN + port. We also will accept oddball (historic) `inet_aton()` style IP addresses (raw hex) depending on if the system implements `getaddr...Spinoff of #18029.
The current behavior is to accept any of a raw port, IP address + port, or FQDN + port. We also will accept oddball (historic) `inet_aton()` style IP addresses (raw hex) depending on if the system implements `getaddrinfo()` correctly or not.
I'm inclined to leave this as is, and if users care that the HS will hit up the system resolver at initialization time, it should be obvious that they need to specify the target by IP. That said, documentation clarification that an FQDN is acceptable would be ideal.
Since both torrc and ADD_ONION style HSes call into common code, changing the behavior to never hit up the resolver is trivial as well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17495Unit-test launch_resolve() in dns.c2020-06-13T14:50:43Zrl1987Unit-test launch_resolve() in dns.cTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16971Testing tor networks use external DNS for dns checks2020-06-13T14:48:45ZteorTesting tor networks use external DNS for dns checksWhen I launch a test network using `make test-network` / chutney on OS X, and leave it running for about a minute, one of the tor processes makes DNS calls.
I discovered this because LittleSnitch told me tor was trying to connect to the...When I launch a test network using `make test-network` / chutney on OS X, and leave it running for about a minute, one of the tor processes makes DNS calls.
I discovered this because LittleSnitch told me tor was trying to connect to the local network's DNS server. I don't know where this happens in the tor code.
Marking this as major / Post027Freeze as it could be an information leak. Alternately, it could be an attempt to look up an address that chutney is (mis)configuring for tor.
I'm not quite sure how to tell the difference between an information leak and a misconfiguration, it may take me some time.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15421Relay crash when reloading and resolv.conf is empty2020-06-13T14:44:32ZTvdWRelay crash when reloading and resolv.conf is empty```
Mar 21 00:11:06 hostnaem Tor[1907]: Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Mar 21 00:11:06 hostnaem Tor[1907]: set_options(): Bug: Acting on config options left us in a broken state. Dying.
``...```
Mar 21 00:11:06 hostnaem Tor[1907]: Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Mar 21 00:11:06 hostnaem Tor[1907]: set_options(): Bug: Acting on config options left us in a broken state. Dying.
```
This just happened on my 0.2.7.0-alpha-dev build. resolv.conf contains only a "search" parameter, but no nameservers.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14197Reverse lookup on automapped addresses doesn't work2020-06-13T14:41:48ZNick MathewsonReverse lookup on automapped addresses doesn't workPossibly, arguably, when we get a request to do a PTR lookup on an address that AutomapHostsOnResolve gave us, we should return the original address.
There's a disabled test for this in my bug7555_v2 branch.Possibly, arguably, when we get a request to do a PTR lookup on an address that AutomapHostsOnResolve gave us, we should return the original address.
There's a disabled test for this in my bug7555_v2 branch.Tor: unspecified