You are not logged in.
Hey friends, I've been trying to set up dnsmasq with stubby and NetworkManager to enforce DNS over TLS. When visiting https://tenta.com/test/?utm_source=blog I notice that my DNS resolvers are reported to /not/ have TLS enabled, which is surprising to me.
I'm not sure I know of any other way to really test this. *shrug*
My uncommented lines in `/etc/dnsmasq.conf`:
no-resolv
proxy-dnssec
server=::1#53000
server=127.0.0.1#53000
listen-address=::1,127.0.0.1
My uncommented lines in `/etc/stubby/stubby.yml`:
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
listen_addresses:
- 127.0.0.1@53000
- 0::1@53000
appdata_dir: "/var/cache/stubby"
upstream_recursive_servers:
- address_data: 145.100.185.15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 145.100.185.16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
- address_data: 185.49.141.37
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
- address_data: 2001:610:1:40ba:145:100:185:15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 2001:610:1:40ba:145:100:185:16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
- address_data: 2a04:b900:0:100::38
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 8.8.8.8
tls_auth_name: "dns.google"
- address_data: 8.8.4.4
tls_auth_name: "dns.google"
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
- address_data: 2001:4860:4860::8888
tls_auth_name: "dns.google"
- address_data: 2001:4860:4860::8844
tls_auth_name: "dns.google"
Also my `/etc/resolv.conf`:
nameserver ::1
nameserver 127.0.0.1
options trust-ad
Note that `/etc/resolv.conf` has been protected with `chattr +i` so that it cannot be overwritten. Even still, here's my `/etc/NetworkManager/conf.d/dns.conf`:
[main]
dns=none
If I use `netstat` to see what's listening to any of the ports defined here, this is the output:
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1140/dnsmasq
tcp 0 0 127.0.0.1:53000 0.0.0.0:* LISTEN 1287/stubby
tcp6 0 0 :::53 :::* LISTEN 1140/dnsmasq
tcp6 0 0 ::1:53000 :::* LISTEN 1287/stubby
udp 0 0 127.0.0.1:53000 0.0.0.0:* 1287/stubby
udp 0 0 0.0.0.0:53 0.0.0.0:* 1140/dnsmasq
udp6 0 0 ::1:53000 :::* 1287/stubby
udp6 0 0 :::53 :::* 1140/dnsmasq
So...everything to me seems to be configured correctly yet the website listed in the opening to this post reports that I do not have DNS over TLS. Any help appreciated...I don't assume there's any real benefit here (tangibly) yet I am stumped to why this configuration is failing. Thanks!
Last edited by cloverskull (2021-09-02 15:44:56)
Offline
I believe this site only tests whether the dns server you connect to uses TLS to connect to the dns server that is authoritative for tenta.com. It doesn't say anything about how you connect to your upstream dns server.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
Ah, got it. Thanks. Is there a way to confirm that I'm actually using DNS over TLS, just to sanity check my configs?
Offline
Maybe just block port 53 tcp and udp on your network interface?
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
Try wireshark-cli, this looks like a fallback to normal DNS if DnsOverTLS not success.
# pacamn -S wireshark-cli
...
# tshark -F pcapng -i $interface -W n -w $outfile
# tshark -r $infile -V
...
Source Address: 192.168.0.7
Destination Address: 1.1.1.1
User Datagram Protocol, Src Port: 58828, Dst Port: 53
Source Port: 58828
Destination Port: 53
Length: 36
Checksum: 0xeae6 [unverified]
[Checksum Status: Unverified]
[Stream index: 2]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
UDP payload (28 bytes)
Domain Name System (query)
Transaction ID: 0x13eb
Flags: 0x0100 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
debian.org: type A, class IN
Name: archlinux.org
[Name Length: 10]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
Offline
Thanks for the tip. I did a capture, now to teach myself how to understand it haha.
Offline
The port and protocol in use is different indeed. Normal DNS is on port 53 and using UDP and DNSoverTLS on port 583 and using TCP
# pacman -S dog
# tshark -F pcapng -i $interface -W n -w $outfile
...
# dog archlinux.org --tls @9.9.9.9
...
# tshark -r $infile -V
...
Internet Protocol Version 4, Src: 192.168.0.7, Dst: 9.9.9.9
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 60
Identification: 0xfa1c (64028)
Flags: 0x40, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment Offset: 0
Time to Live: 64
Protocol: TCP (6)
Header Checksum: 0x2420 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.0.7
Destination Address: 9.9.9.9
Transmission Control Protocol, Src Port: 52360, Dst Port: 853, Seq: 0, Len: 0
Source Port: 52360
Destination Port: 853
Last edited by solskog (2021-09-05 06:16:22)
Offline
Posting (slight necro-bump, alas...) just to update folks curious to try similar.
This configuration didn't allow me to connect to the internet via things like hotel wifi. It also broke a lot of VM networking. So...I disabled it and everything is now working fine. I'm not sure the juice is worth the squeeze here, but it was fun to tinker with nevertheless.
Offline
Support for DNSoverTLS in everyday life is restricted yes. you can try dnscrypt. But, the best solution for privacy is vpn.
Offline