DNS over TLS has stopped working

Support Network
1

Yesterday afternoon, stubby which I’ve been using for about 2 years, all of a sudden stopped working. It reports “Conn closed: TLS - Failure” for every upstream. Thinking it was a system problem, I restored to a point from last week, but the issue remains.

I have a sneaky feeling my ISP is blocking these requests. (The Joys of a Communist country!)

Is there a way to perform a DNS request, using TLS, from the command line? Or are there any other stubby like servers I might try?

Update: Seems the problem is a little deeper than I first thought. I’m unable to update from the AUR

curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused
==> ERROR: Failure while downloading https://github.com/X0rg/AUR-packages/raw/master/files/memtest86-9.0-usb.zip
    Aborting...

DNS poisoning, hence the need for TLS. The IP returned by my default nameserver was 0.0.0.0

2

You can use kdig from the knot package for DoT:

Example:

kdig +tls @dns.digitale-gesellschaft.ch manjaro.org

(It will use the mentioned DoT from Digitale Gesellschaft CH.)

The returned IP of 0.0.0.0 seems like your upstream server is blocking this domain.

3

Thanks for the suggestion, unfortunately I don’t get any results. After a little more research it appears DNS over TLS is being blocked in China. Specifically connections using TLS1.3.

Using unencrypted DNS is problematic as noted above. My ISPs DNS is a no go, and those like google and quad9 are open to man in the middle (which I’ve seen on many occasions).

Since I run my own server, I’m now researching how to install a DNS on it.

4

A public DNS is always a bad idea. Hiding it behind a IPv4 and not telling anybody about it, is not safe.

If you set up a DNS-over-TLS server your own, won’t these connections also be blocked?

5

I already run a VPN on the server which uses HTTPS (though I’m not sure which TLS version). Theoretically, a DNS request to my server should look exactly the same as my regular VPN traffic.

Right now, I’m not sure of what exactly is being blocked. I’ve read that TLS1.3 in combination with ESNI are causing the problems, but at the same time I think the IP/port of the DoH servers are blocked (I can still ping). There’s some deep packet sniffing going on for sure.

6

If you have an HTTPS server anyway, you could use DNS-over-HTTPS.

Then, instead of stubby (Maybe it works also, I don’t know it), you would use dnscrypt-proxy with your own DoH server as upstream.

7

Yeah, that’s the plan. Unfortunately, I don’t have the time right now to set it up. I’ll update this thread after a day or two.

8

I swapped stubby for the dns-over-https package and run its doh-client locally. I built the same dns-over-https on my server, run its dns-server and added a redirect url to my caddy config. Additionally, I added my domain and IP to the /etc/hosts file. I’m up and running securely again.

Oh, and the correct method of testing from the command line is with a url like:
curl -w '\n' 'https://www.example.com/query-dns?name=google.com&type=A'

9

Good, but be aware that you now have a public DNS which can and probably will be part of a DNS amplification attack some time in the future.

10

I’ve actually found that DoT is completely blocked, DNS53 returns wrong results and DoH servers get blocked for 5 minutes after each query. The only working solution I’ve found is to use dnscrypt-proxy with their list of public servers. This software can be configured to send dnscrpyt/DoH requests over a VPN. It’s been running, touch wood, great for over a week now.

1 Like
11

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.