[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

MX / SRV / DNSSEC / any DNS requests over Tor / DNSCrypt

Cam across some workarounf for SRV requests over Tor:

Outbound connections are possible with the use of the --tor.socks and --tor.dns arguments. The --tor.socks argument should point to the interface that the Tor daemon is listening on to proxy connections. The --tor.dns flag is required in order to be able to properly automatically bootstrap a set of peer connections. The tor daemon doesn’t currently support proxying SRV queries over Tor. So instead, we need to connect directly to the authoritative DNS server over TCP, in order query for SRV records that we can use to bootstrap our connections.

Any idea if it can work inside WS with stacked Tor?

Certainty: low

That would be which interface? In case of non-Whonix, plain Debian for example that would probably be localhost or eth0.

Meaning, directly using clearnet, not using Tor?

Probably not what you mean?

Related:
Support all kinds of DNS over Tor

On the other hand…

–tor.dns=
The DNS server as host:port that Tor will use for SRV queries - NOTE must have TCP resolution enabled (default: soa.nodes.lightning.directory:53)

I don’t understand the source code. Look for tor.dns, defaultTorDNSHost, dnsHost if anyone wants to check.

Looks like an application specific implementation which is not trivially refactored for use by arbitrary applications.

Feel free to ask upstream about it.

defaultTorDNSHost = “soa.nodes.lightning.directory”

Looks like it needs special(?), specific DNS servers providing this service. Thereby DNS related non-stream isolation, identity correlation.

Since…

Looks like it needs special(?), specific DNS servers providing this service. Thereby DNS related non-stream isolation, identity correlation.

If that’s not a concern, another option would be to use DNSCrypt. Looks like nowadays DNSCrypt can do both encrypted DNS as well as DNSSEC (authentication). I haven’t look into it for years. See:

Reminding me about this gave me the idea that “hardened debian” (rename required) (Hardened Debian - Security Focused Linux Distribution based on Debian - In Development - Feedback Wanted!) might come with preconfigured with DNSCrypt + DNSSEC by default, but that is best discussed in a separate thread.

1 Like

No of course not. I mean connecting to a DNS server over Tor rather than asking the exit to broker the request on its behalf.

Dug in the code and found a dedicated package whose purpose is to interact with Tor for SRV requests among others. Looks geenric

https://github.com/lightningnetwork/lnd/tree/c1c4b84757dd5b1e1fcb285b4a1fa6a56b35432c/tor

I’ll ask

Feel free to this part of the comment. Summary DNSSEC is extremely hierarchical and relies on trusting central authorities that its ultimately useless in providing real/strong security , Not worth the deployment effort IMO

https://moxie.org/blog/ssl-and-the-future-of-authenticity/

1 Like
1 Like

An interesting reply by a TPO dev on resolving all types of DNS records.

https://lists.torproject.org/pipermail/tor-dev/2019-July/013938.html

A few exits allow connections to TCP port 53, so you can do arbitrary DNS queries to any DNS server using those exits.

1 Like

Just found out that DNS isn;t redirected over openvpn by default. Needs adding routes and other hackery. Not a great solution for widespread use anyway but explains why it didn’t work.

1 Like

HulaHoop via Whonix Forum:

An interesting reply by a TPO dev on resolving all types of DNS records.

https://lists.torproject.org/pipermail/tor-dev/2019-July/013938.html

A few exits allow connections to TCP port 53, so you can do arbitrary DNS queries to any DNS server using those exits.

Can you translate this into user documentation (even non-Whonix)?

HulaHoop via Whonix Forum:

Just found out that DNS isn;t redirected over openvpn by default. Needs adding routes and other hackery. Not a great solution for widespread use anyway but explains why it didn’t work.

https://www.whonix.org/wiki/Tunnels/Introduction covers DNS.

The best I could do is follow cloudflare’s guide for their onion resolver since the probability of running into an exit with TCP 53 permitted is low.

Problem is cloudflare requires running their binary daemon cloudflared which is not free software

Then we would need to redirect the DNS queries to their server with socat or systemd but in a way compatible with how Whonix works.

1 Like

Reply from the lightning network devs. One would query their server to find DNS nodes.

dig nodes.lightning.directory

https://pastebin.com/XDRHL3Et

The best option we have is to use their Tor DNS code with the servers their package supports and somehow wrap it around just dino-im.

1 Like

HulaHoop via Whonix Forum:>

I mean connecting to a DNS server over Tor rather than asking the exit to broker the request on its behalf.

Use DNSCrypt.

probability of running into an exit with TCP 53 permitted is low.

Why is that?

probability of running into an exit with TCP 53 permitted is low.

Doesn’t Tor pick an exit relay depending on the one which supports the port the Tor client wants to use?

Then we would need to redirect the DNS queries to their server with socat or systemd but in a way compatible with how Whonix works.

Sounds like:

Use DNSCrypt.

The best option we have is to use their Tor DNS code with the servers their package supports and somehow wrap it around just dino-im.

When taking their code the outcome could be:

  • application specific code for dino-im (or similar)
  • a standalone command line tool similar to tor-resolve. I.e. too-to-resolve-dns-from-command-line domain-name outputs IP address. - Not too helpful since iptables cannot redirect to a command line tool. For that, we’d need a tool that provides a listener.

What’s not easy:

[1] Redirecting DNS (or any) traffic to such code. For that, a listener port which accepts traffic similar to Tor’s DnsPort would be required. Non-trivial.

But, if we want [1], that sounds like:

Use DNSCrypt.

While lnd’s approach is interesting, I don’t see any reason to cling on their code when there is DNSCrypt which is packaged in Debian already for years, which can do [1].

DNSCrypt is Open Source, supports TCP, can use outgoing port 443, therefore works over Tor, supports DNSSEC, encrypts communications between client and DNS server, therefore Tor exit relays cannot forge the DNS requests, is packaged in Debian already for years, was tested and documented in Whonix years ago, although documentation needs a revision.

DNSCrypt documentation: Already added some guesses. Was written when installed form source (complicated). Nowadays sudo apt install dnscrypt-proxy could suffice.

I could be wrong about some things about DNSCrypt and I happy to be corrected but for now it looks like it is doing all that is required.

Therefore, I’d suggest:

Step 1) get DNSCrypt working in a separate Whonix-Workstation as global (fallback, system default networking) DNS.

Step 2) try specific use case (dino-im)

Step 3) use linux user account or linux network namespaces (preferably) (similar to orjail. ( https://github.com/orjail/orjail / Managing programs without Tor DNS Support / orjail )) so it only applies to dino-im and not globally.

1 Like

Teor said so, but on the other hand even the reduced exit policy allows TCP 53

https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

OK sounds perfect. What steps do I need to do to make it a fallback? Will it be automatically used for a program that can’t resolve through Tor?

starting dnscrypt wth tcp gives this:

user@host:~$ sudo dnscrypt-proxy --tcp-only
flag provided but not defined: 

Testing site report with systemctl reporting it as enabled (which it would be with any daemon on Debian) I get this:

You aren't using OpenDNS yet. Let's fix that
If you haven't restarted your computer yet, please do that now

That’s kinda already an alternative step 3.
Not sure. Perhaps leaving /etc/resolv.conf as is but only appending it.

Instructions as is would replace system Tor DNS with DNScrypt.

That’s not how it is supposed to be used nowadays anymore since packaged for Debian there is also a systemd unit file. See: apt-file list dnscrypt-proxy

Interesting files to look at:

  • /etc/dnscrypt-proxy/dnscrypt-proxy.toml
  • /lib/systemd/system/dnscrypt-proxy.service
  • /lib/systemd/system/dnscrypt-proxy.socket
  • and the example configs in folder /usr/share/doc/dnscrypt-proxy/examples/

Add to /etc/dnscrypt-proxy/dnscrypt-proxy.toml at the very top most likely (since this is “general” and not a [section]).

force_tcp = true

DNSCrypt documentation for Whonix and the whole page was revised. DNSCrypt are now good enough to make it work.

Note: don’t skip the introduction chapter warning.

Note that most applications, such as Tor Browser, will not automatically profit from setting up an alternative DNS resolver.

  • This is because applications in Whonix ™ are configured to use SocksPort instead of Trans - or DnsPort , see Stream Isolation for details.
  • Another reason is, that most applications do not yet make use of authenticated DNS (DNSSEC).

However, you could use alternative DNS revolvers with these applications when deconfiguring socks proxy settings.

Users can now set up encrypted DNS over Tor using any DNS server from DNSCrypt list https://dnscrypt.info/public-servers/. Any type of DNS (such as MX, tested) should be possible to resolve. Bonus: DNSSEC also working.


They way Tor implemented DnsPort is seems it will not be possible to use DNSCrypt as a fallback only. dig MX google.com will answer and claim there is no MX DNS entries for that domain. Therefore, no other DNS server from /etc/resolv.conf will be tried out. This might be a good default for Tor connectivity since applications might re-try other types of DNS, hopefully Tor supported ones. Might be the reason it is acting in that way. Any change by upstream might be bad for Tor connectivity form their point of view. A configuration option would change the web fingerprint (actually any "use another DNS resolver other than Tor as a fallback would change the web fingerprint).

For now it is either the whole system default networking (i.e. not Tor Browser etc. by default since these are configured to use SocksPort) Whonix-Workstation uses Tor DnsPort OR DNSCrypt.

1 Like

libresolv-wrapper does not work with curl but perhaps with dino-im?

If that was to work, then an alternative resolv.conf elsewhere could be used by dino-im and thereby could use TCP and DNS (through DNSCrypt) through Tor’s TransPort.

1 Like

Thanks for documenting. Great job. There are some quirks I’m seeing that need some troubleshooting before it works on my end and I can test.


OK so dnscrypt daemon is running but it is complaining about tcp sockets

 dnscrypt-proxy.socket - dnscrypt-proxy listening socket
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.socket; enabled; vendor preset: enabled)
   Active: active (listening) since Wed 2019-07-17 18:13:24 UTC; 7min ago
     Docs: https://github.com/jedisct1/dnscrypt-proxy/wiki
   Listen: 127.0.2.1:53 (Stream)
           127.0.2.1:53 (Datagram)
    Tasks: 0 (limit: 2355)
   Memory: 0B
   CGroup: /system.slice/dnscrypt-proxy.socket

Jul 17 18:13:24 host systemd[1]: dnscrypt-proxy.socket: TCP_DEFER_ACCEPT failed: Protocol not available
Jul 17 18:13:24 host systemd[1]: dnscrypt-proxy.socket: TCP_NODELAY failed: Protocol not available
Jul 17 18:13:24 host systemd[1]: Listening on dnscrypt-proxy listening socket.

Its probably non-functional with the output:

; <<>> DiG 9.11.5-P4-3-Debian <<>> +multiline . DNSKEY
;; global options: +cmd
;; connection timed out; no servers could be reached
1 Like

I saw these before. Dunno how I fixed those. Can’t reproduce. Even though I am using a fresh VM (Qubes DispVM), reapplying my own instructions copy/paste.

Forgot the restart commands most likely. Now added.

sudo systemctl restart dnscrypt-proxy.service
sudo systemctl restart dnscrypt-proxy.socket

But not sure in which order.
Maybe that helps.

https://github.com/jedisct1/dnscrypt-proxy/wiki/systemd says TCP_DEFER_ACCEPT and TCP_NODELAY don’t matter. Not sure it mattered for me.

Also, copy/paste FTW. Added another hint for a likely mistake to be made.

It is not 127.0.0.1 . It really is 127.0.2.1.

Did you comment out the cloudflare default server?

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]