The Domain Name System (DNS) that modern computers use to find resources on the internet was designed 35 years ago without consideration for user privacy. It is exposed to security risks and attacks like DNS Hijacking. It also allows ISPs to intercept the queries.
Luckily, DNS over TLS and DNSSEC are available. DNS over TLS and DNSSEC allow safe and encrypted end-to-end tunnels to be created from a computer to its configured DNS servers. On Fedora, the steps to implement these technologies are easy and all the necessary tools are readily available.
This guide will demonstrate how to configure DNS over TLS on Fedora using systemd-resolved. Refer to the documentation for further information about the systemd-resolved service.
Step 1 : Set-up systemd-resolved
Modify /etc/systemd/resolved.conf so that it is similar to what is shown below. Be sure to enable DNS over TLS and to configure the IP addresses of the DNS servers you want to use.
$ cat /etc/systemd/resolved.conf [Resolve] DNS=1.1.1.1 9.9.9.9 DNSOverTLS=yes DNSSEC=yes FallbackDNS=8.8.8.8 1.0.0.1 8.8.4.4 #Domains=~. #LLMNR=yes #MulticastDNS=yes #Cache=yes #DNSStubListener=yes #ReadEtcHosts=yes
A quick note about the options:
- DNS: A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers
- FallbackDNS: A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers.
- Domains: These domains are used as search suffixes when resolving single-label host names, ~. stand for use the system DNS server defined with DNS= preferably for all domains.
- DNSOverTLS: If true all connections to the server will be encrypted. Note that this mode requires a DNS server that supports DNS-over-TLS and has a valid certificate for it’s IP.
NOTE: The DNS servers listed in the above example are my personal choices. You should decide which DNS servers you want to use; being mindful of whom you are asking IPs for internet navigation.
Step 2 : Tell NetworkManager to push info to systemd-resolved
Create a file in /etc/NetworkManager/conf.d named 10-dns-systemd-resolved.conf.
$ cat /etc/NetworkManager/conf.d/10-dns-systemd-resolved.conf [main] dns=systemd-resolved systemd-resolved=false
The setting shown above (dns=systemd-resolved) will cause NetworkManager to push DNS information acquired from DHCP to the systemd-resolved service. This will override the DNS settings configured in Step 1. This is fine on a trusted network, but feel free to set dns=none instead to use the DNS servers configured in /etc/systemd/resolved.conf.
Step 3 : start & restart services
To make the settings configured in the previous steps take effect, start and enable systemd-resolved. Then restart NetworkManager.
CAUTION: This will lead to a loss of connection for a few seconds while NetworkManager is restarting.
$ sudo systemctl start systemd-resolved $ sudo systemctl enable systemd-resolved $ sudo systemctl restart NetworkManager
NOTE: Currently, the systemd-resolved service is disabled by default and its use is opt-in. There are plans to enable systemd-resolved by default in Fedora 33.
Step 4 : Check if everything is fine
Now you should be using DNS over TLS. Confirm this by checking DNS resolution status with:
$ resolvectl status MulticastDNS setting: yes DNSOverTLS setting: yes DNSSEC setting: yes DNSSEC supported: yes Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 9.9.9.9 Fallback DNS Servers: 8.8.8.8 1.0.0.1 8.8.4.4
/etc/resolv.conf should point to 127.0.0.53
$ cat /etc/resolv.conf # Generated by NetworkManager search lan nameserver 127.0.0.53
To see the address and port that systemd-resolved is sending and receiving secure queries on, run:
$ sudo ss -lntp | grep '\(State\|:53 \)' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=10410,fd=18))
To make a secure query, run:
$ resolvectl query fedoraproject.org fedoraproject.org: 8.43.85.67 -- link: wlp58s0 8.43.85.73 -- link: wlp58s0 [..] -- Information acquired via protocol DNS in 36.3ms. -- Data is authenticated: yes
BONUS Step 5 : Use Wireshark to verify the configuration
First, install and run Wireshark:
$ sudo dnf install wireshark $ sudo wireshark
It will ask you which link device it have to begin capturing packets on. In my case, because I use a wireless interface, I will go ahead with wlp58s0. Set up a filter in Wireshark like tcp.port == 853 (853 is the DNS over TLS protocol port). You need to flush the local DNS caches before you can capture a DNS query:
$ sudo resolvectl flush-caches
Now run:
$ nslookup fedoramagazine.org
You should see a TLS-encryped exchange between your computer and your configured DNS server:
— Poster in Cover Image Approved for Release by NSA on 04-17-2018, FOIA Case # 83661 —
David Yip
Even Network Solutions doesn’t support DNSSEC DS upload….
Geoffrey Gordon Ashbrook
Thank you very much. From listening to Steve Gibson’s Security Now on Twit (not twitch) and GRC I have been aware of the importance of DNS. It is wonderful that the topic is be written about.
However, following your instructions above disabled by network completely and I had use the backups I made of everything (just in case) to roll back and get my computer un-bricked.
Please check your article’s instructions and perhaps advise people on what to do if they need to roll back the changes (e.g. back up any changed files before hand).
I very, very much look forward to a version of this article that works. Thank you very much.
Vernon Van Steenkist
Does this bypass the DNS servers obtained from DHCP? If so, it seems this would cause problems accessing servers at workplaces, etc that run their own local DNS services behind firewalls.
Gregory Bartholomew
Hi Vernon:
It is possible to set up separate DNS servers for separate networks (domains). I do exactly that on my home system. I disable NetworkManager and use systemd-netword instead though. That topic would need an article of its own, but below are my systemd-networkd config files as an example to get you started.
Vernon Van Steenkist
Thanks for your response. Looks pretty complicated for someone who takes their laptop to different companies. I think we need to take a look at the issue we are trying to solve which I assume is DNS poisoning. Note that DNS poisoning is not always malicious. Many large companies have local DNS servers purposely DNS poison to keep their users away from questionable sites. The above configurations prevents this behavior and worse, breaks the ability to connect to machines behind a firewall.
If you are worried about DNS poisoning on a public WiFi network for web browsing, Firefox allows you to easily enable DNS over HTTPS (Preferences->Network Settings->DNS of HTTPS) assuming you trust Cloudflare. This can easily be disabled through the same settings when you are behind a company firewall.
I am not sure what benefit DNS over TLS provides inside your home network. Many home WiFi routers ship with dnsmask which acts as both a DNS and DHCP server. dnsmask automatically updates its DNS with the computer name whenever a new host gets connected (search Dynamic DNS for more details). The above configurations breaks this convenience.
If your goal in anonymity, then you can use openvpn to connect to many vpn providers. https://freevpn.me is a good, free, anonymous choice that doesn’t restrict any kind of traffic. Be sure to modify their .ovpn files to include using their DNS servers instead of yours. You can verify that you are not leaking DNS information by going to https://www.dnsleaktest.com/
Please don’t hesitate to provide corrections or comments.
Gregory Bartholomew
Are you sure about that? I think it is the DHCP that triggers the Dynamic DNS update, not the DNS query. It doesn’t seem like DNS over TLS should interfere with Dynamic DNS.
Gregory Bartholomew
Nevermind, I see what you are saying. At first I thought you were referring to the public dynamic dns service that some routers support. If you are talking about running your own local dns server, then yes, you would have to configure an exception for your “.local” domain (or whatever you name it) so that dns searches in that domain would would still be routed to your local dnsmask server rather than to your DNS over TLS server.
Gregory Bartholomew
I think that is the key question — “who do you trust”. What DNS over TLS does is to provide the user a way to decide for themselves who they want to trust rather than having to rely on whoever is running the network that they are currently plugged into.
Unfortunately, I think some ISPs block users from making this choice and require all queries to be routed through their servers. As you say, it isn’t always malicious, but I suspect that may be why this setup is failing for several users.
Vernon Van Steenkist
Personally, the only DNS servers I trust is my own. If I remember correctly, Fedora allows you to install a fully functioning, fully configured DNS server by simply issuing the commands
dnf install bind
systemctl start named
as root.
Then all you have to do is tell your DHCP server to specify the Fedora DNS.
These are my rules.
At home, I use my local Fedora DNS server. If I desire anonymity, I use my VPN provider DNS. I never do any banking transactions, or anything that requires a username/password through my VPN provider since they could DNS poison or man in the middle.
Remotely, I don’t care about DNS poisoning unless I want to do banking or something that requires username/password access. Then, I openvpn into my home VPN server. Note that my .ovpn file ensures that I am using my home DNS server.
Comments welcome.
Graham King
This did not work for me on Fedora 32.
If I follow step 2,
gets
but I can’t connect (NetworkManager icon stays on question mark).
If at step 2 I do
then /etc/resolv.conf has it’s previous value (from DHCP) and everything works, but I’m probably not using TLS.
What am I missing?
Brian
I got exactly the same response NetworkManager failed to restart– error . I had to back track and restore my old settings to get NetworkManager to restart. I guess I’ll wait for Fedora 33.
Johannes
Wont work, thanks anyway though!
John Harris
It’d be preferable not to suggest using Cloudflare and Google DNS.. They have no respect for your privacy.
Resynth
Agreed. I would prefer using other alternatives, such as the ones listed here: https://www.privacytools.io/providers/dns/
hilltothesouth
Cloudflare is listed as one of those alternatives. You guys sure they don’t respect our privacy?
Andre
Works, thanks!
Is it possible to do a “round robin” with the dns-servers i choose?
Mark
It does prevent access to existing local dns servers if used.
As noted by Graham King above it overwrites resolv.conf with “nameserver 127.0.0.53” which may be valid if the service systemd-resolved hooks in there somewhere; but not just internal but also external dns lookups failed after making the changes in the article.
I suppose theoretically if all internal dns servers were upgraded to ipsec they could just be prepended to the dns= list and internal/local-network lookups would work ?… although as with the examples used in this article even external lookups do not work possibly not.
So I can just hope the quoted section in the article that included “There are plans to enable systemd-resolved by default in Fedora 33” is enthusiasm rather than fact. While Fedora are used to having to google for solutions after upgrades that would be a bit difficult to do if systemd-resolvd started and nobody had any working dns lookup facility to get them to google.
Matti
Two questions;
1. Does this work with a VPN (in my case, Mullvad using the WireGuard protocol) active?
2. Is there an GUI alternative to Wireshark that doesn’t need qt/kde dependencies?
Gregory Bartholomew
It should work with anything that doesn’t need to see your DNS queries. I suspect that would include the typical VPN, but I don’t know that much about them. I would say the only way to really know is to try it and see.
Interesting … It looks like there used to be a gtk version of wireshark, but it is no longer available:
In the good old days, you used to be able to get away with installing an older package (or newer one from rawhide) once in a while, but since modularity, I’m not sure that that works any more. I guess you could try to install it, but if it wants to pull in more than a handful of packages, I’d abort the install.
Stan Sykes
I have exactly the same issue as G.King above.
After step 2 ( “Tell NetworkManager to push info to systemd-resolved”) I lose the internet connection (can’t resolve host names).
If I remove the file 10-dns-systemd-resolved.conf all works as before.
We’re missing something …
Linux Z380-10F.localdomain 5.7.7-200.fc32.x86_64
Eric L.
It must be clear that the solution described overwrites the DNS server(s) normally configured through DHCP. The approach might break a lot of things, depending on the setup of the IT provider (home or office).
I would personally be more interested in still using the default DNS server(s) but checking if they support those security features, and accordingly enforce them.
Alan Olsen
This doesn’t work with VPN tunnels. (At least mine.) Also needs more info on IPv6 usage.
james
Sounds like a really good idea, but it doesn’t work on my workstation f32.
Ole Aamot
This guide does not work on Fedora Core 32.
Please remove it.
Ole Aamot
This guide left me and is likely to leave its followers with a broken DNS resolver.
Please remove this “guide” from Fedora Magazine.
Michael W
This is just way too short of a discussion over the value of this, and the issues that this suggestion could cause.
Gregory Bartholomew
It is indeed a HUGE topic. I tried to google for something that tries to explain and illustrate some of the concepts in a simple way. I like the following article because it has some nice diagrams and even includes a small section on encrypted DNS:
https://schub.wtf/blog/2019/04/08/very-precarious-narrative.html
cedzik
i found a soulution: in /etc/systemd/resolved.conf uncoment #Domains=~. then restart systemd-resolved
Rojen
Although I apply the settings, it is based on the DNS address of the device ‘wlp2s0’, what should I do to prevent this from happening?
(let’s not forget that the global dns name server appears in the settings I made but not in wlp2s0)
Gregory Bartholomew
Hi Rojen:
According to the article, you should be able to accomplish that by setting “dns=none” in /etc/NetworkManager/conf.d/10-dns-systemd-resolved.conf.
You might also want to verify that /etc/resolv.conf is a symlink pointing to the right systemd-resolved file:
Unfortunately, my setup is a little different (I use systemd-networkd instead of NetworkManager), so I am not easily able to confirm that this works.
Rojen
Hi, firstly thanks for respond.
But also i try it whatever you said but not worked.
My problems that:
1) My ISP Service use Cloudflare DNS server.
2) I want use NIX DNS server.
I do makes whole configuration as complete. not have a error.
My outputs,
Global Output:
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 104.244.78.231
DNS Servers: 104.244.78.231
Fallback DNS Servers: 198.251.90.91
wlp2s0 Device Output:
Link 3 (wlp2s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 1.1.1.1
DNS Servers: 192.168.1.1
1.1.1.1
DNS Domain: ~.
The device ‘wlp2s0’ uses the wrong DNS server as it appears here. I need to fix this.
DNS Leak Test:
Your IP:
X.X.X.X [Turkey ASTURKNET]
You use 1 DNS server:
172.69.117.143 [Turkey AS13335 CLOUDFLARENET]
Conclusion:
DNS may be leaking.
ALSO
When I hardly put ‘104.244.78.231’ dns server in the /etc/resolv.conf file
I get correct output but as you know DoT not have.
Your IP:
X.X.X.X [Turkey ASTURKNET]
You use 1 DNS server:
104.244.78.231 [Luxembourg AS53667 PONYNET]
Conclusion:
DNS may be leaking.
What should I do?
My configurations:
[Resolve]
DNS=104.244.78.231
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=198.251.90.91
#Domains=~.
#LLMNR=yes
#MulticastDNS=yes
#Cache=yes
#DNSStubListener=yes
ReadEtcHosts=yes
[main]
dns=none
My status:
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2020-07-13 00:58:19 +03; 28min ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 8906 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4539)
Memory: 9.4M
CPU: 784ms
CGroup: /system.slice/systemd-resolved.service
└─8906 /usr/lib/systemd/systemd-resolved
Jul 13 00:58:19 linux systemd[1]: Starting Network Name Resolution...
Jul 13 00:58:19 linux systemd-resolved[8906]: Positive Trust Anchors:
Jul 13 00:58:19 linux systemd-resolved[8906]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jul 13 00:58:19 linux systemd-resolved[8906]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.17>
Jul 13 00:58:19 linux systemd-resolved[8906]: Using system hostname 'linux'.
Jul 13 00:58:19 linux systemd[1]: Started Network Name Resolution.
● NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2020-07-13 00:58:22 +03; 30min ago
Docs: man:NetworkManager(8)
Main PID: 8912 (NetworkManager)
Tasks: 3 (limit: 4539)
Memory: 5.4M
CPU: 705ms
CGroup: /system.slice/NetworkManager.service
└─8912 /usr/sbin/NetworkManager --no-daemon
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0180] dhcp4 (wlp2s0): state changed unknown -> bound
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0460] device (wlp2s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0486] device (wlp2s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0490] device (wlp2s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0498] manager: NetworkManager state is now CONNECTED_LOCAL
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0519] manager: NetworkManager state is now CONNECTED_SITE
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0521] policy: set 'Amedî' (wlp2s0) as default for IPv4 routing and DNS
Jul 13 00:58:26 linux NetworkManager[8912]: <info> [1594591106.0532] device (wlp2s0): Activation: successful, device activated.
Jul 13 00:58:27 linux NetworkManager[8912]: <info> [1594591107.1187] manager: NetworkManager state is now CONNECTED_GLOBAL
Jul 13 00:58:28 linux NetworkManager[8912]: <info> [1594591108.8328] manager: startup complete
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 104.244.78.231
DNS Servers: 104.244.78.231
Fallback DNS Servers: 198.251.90.91
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 5 (virbr0-nic)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Link 4 (virbr0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Link 3 (wlp2s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 1.1.1.1
DNS Servers: 192.168.1.1
1.1.1.1
DNS Domain: ~.
Link 2 (enp10s0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
thanks.. I wait your response
Gregory Bartholomew
Hi Rojen:
From man nm-settings-ifcfg-rh:
I would suggest that you try adding the line:
to /etc/sysconfig/network-scripts/ifcfg-wlp2s0
My environment is just too different for me to be able to say for sure what will work. It is possible that your ISP is blocking DNS over TLS and that this simply will not work for you.
Good luck!
Rojen
Hi, yep.
I understond the my ISP Service blocking different DNS server. Not only that, it is does hijacking and changing the DNS. This was already known in our geography, DNS does hijacking. We need to use VPN. However, this is not always fast, I just wanted to use a different DNS in my normal work…
anyway:
It’s have DNS1=”bla.bla” line at /etc/sysconfig/network-scripts/ifcfg-wlp2s0 file.
When I added a diffrent DNS “except 1.1.1.1, 8.8.8.8, 9.9.9.9” to this, ISP blocking my input DNS and so internet not working. (I have a question at en of line)
Hijacking example:
18-DEVICE=wlp2s0
19-ONBOOT=yes
20-PEERDNS="no"
21:DNS1=9.9.9.9
runuser -l work -c 'dnsleaktest.sh'
Your IP:
X.X.X.X [Turkey ASTURKNET]
You use 1 DNS server: #?! wtf
213.74.50.82 [Turkey AS34984 TELLCOM-AS]
Conclusion:
DNS may be leaking.
Link 3 (wlp2s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: yes
DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 9.9.9.9
DNS Servers: 9.9.9.9
DNS Domain: ~.
I have a last question to you. So what I do to set the Fallback DNS in to /etc/sysconfig/network-scripts/ifcfg-wlp2s0 file? Apparently FALLBACK DNS is not seems in the resolvectl status. (I look the documents but not find anything so i want.
as: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_ifcg_files document. maybe you know the this.)
Gregory Bartholomew
Hi Rogen:
The Fallback DNS servers should show up in the output of resovectl status:
Fallback DNS Servers: 1.1.1.1
8.8.8.8
1.0.0.1
8.8.4.4
2606:4700:4700::1111
2001:4860:4860::8888
2606:4700:4700::1001
2001:4860:4860::8844
Personally, I like to disable them completely:
[Resolve]
FallbackDNS=
# systemctl restart systemd-resolved.service
# resolvectl status | grep -A 7 "^Fallback DNS Servers:"
#
rtghrt
why not show example in ipv6?
tmp2k
this is not good because it does not work
tmp2k
ok uncommented domains ~. works 😉
Gregory Bartholomew
Interesting. That setting should only be necessary when you want to setup per-domain DNS routing. The idea is that you can configure different domains to use different DNS servers (e.g. ~example.com -> 8.8.8.8, ~demo.net -> 1.1.1.1, etc.). You would then set ~. -> 1.0.0.1 or something like that as a “catch all” for any domain that didn’t have a more-specific specification. ~. shouldn’t be necessary if you don’t have the more-specific sub-domains defined. It sounds like there is an interoperability problem between systemd-reloved and NetworkManager. Maybe it depends on the versions used or maybe the author had something non-standard in his NetworkManager configuration (e.g. “PEERDNS=no” in /etc/sysconfig/network) and forgot about it.
I could edit the article, but I’m weary of doing that without the author’s permission and without knowing for sure what is going on.
anonymous
I haven’t verified this, so it might have been another issue, but I think I had to set Domains=~. when DNS is set to automatic in the Gnome Control Center.
fds
You may also just use your own internal dns server, this is cheap and much easy to use because you won’t depend of anybody.
Furthermore you can add your own localdomain to map your internal network
taufik.bonaedy
The instruction above doesn’t work at all on Fedora 32. I’ve tried with DHCP or static IP, non of them work. Please check again your instruction.
Gregory Bartholomew
Taufik:
Some people have reported that it works, so I don’t thing the guide is too far off. I think this is something that ISPs are known to block (I think it runs on a different port than standard DNS), so if it isn’t working for you, it isn’t necessarily a problem with the guide or the OS. It could be a “problem” with your internet connection.
Vernon Van Steenkist
If you want to know if your ISP is blocking DNS over TLS, issue the following commands.
sudo dnf install nmap
nmap -p 853 1.1.1.1
If your ISP is allowing DNS over TLS, you should see the following output
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-14 17:34 PDT
Nmap scan report for one.one.one.one (1.1.1.1)
Host is up (0.036s latency).
PORT STATE SERVICE
853/tcp open domain-s
The key output line is
853/tcp open domain-s
You can repeat the above nmap command for each IP address in the tutorial.
If your ISP is blocking DNS over TLS, the simplest solution is to enable Firefox DNS over HTTPS which can be set at Preferences->Network Settings->DNS over HTTPS. In fact, if you are going to follow the tutorial which uses Cloudflare’s and Google’s DNS servers, Firefox’s DNS over HTTPS it the simplest solution for web browsing, gives you at least as much security as DNS over TLS and affords you more privacy than DNS over TLS..
pgbross
I followed the steps in the article on my Fedora 32 workstation shortly after it was posted and it worked flawlessly.
Yesterday (Jul 23rd) for unrelated reasons I installed a fresh copy of Fedora 32 from scratch (deleting partitions etc). Now when following the steps I see the same behaviour that others have reported, namely that name resolution is not working when DNSOverTLS=yes.
So I wonder if previously on my system that had upgraded through earlier versions of Fedora over the last couple of years had some other setting or configuration that is required but is not present in a clean F32 setup.
I can’t find any obvious faults in the system logs or audits so am also stumped for now.
Gregory Bartholomew
If you figure it out, please do let us know what needs to be changed in the article. Thanks.
pgbross
Ok, so I think I know what was going wrong for me, even if I am not 100% sure of the exact reason/sequence that makes it behave in an undesirable way (ie.it breaks).
I used Wireshark to look at the network traffic after following the instructions in the article and discovered it was correctly using the DNSOverTLS protocol but it was not using the specified DNS servers. It was actually still trying to use the DHCP acquired local router address. Then I remembered in my previous setup I was using a static address (so my earlier theory about something from earlier versions of Fedora were not right, though led me in the right direction). So with that information and a recollection of another article here in Fedora Magazine from about a year ago on Dnsmasq that talked about per-connection DNS overrides I wondered if there was some cached information or something keeping the DHCP server DNS server address.
So I went into Gnome Settings -> Networks and changed my connection to (temporarily) use a specified DNS server (1.1.1.1) and for good measure disabled IP6. Restarted NetworkManager and I could then resolve IP addresses (as that server understands DNS over TLS). The best part though is I have now reset my connection to use the automatic DHCP DNS, reanabled IP6, restarted NetworkManager, and it is correctly using the servers from the resolved.conf.
How many of those steps were actually needed – not sure. Is there another service that could have been restarted or a cached file/config that could have been edited/deleted maybe, but I don’t know enough about the interactions between the different components to answer that.
I am however happy it is now working and works across reboots. Perhaps someone with more knowledge can use this information to work out the optimal solution/steps and if course just because this fixed my system doesn’t mean it is the same root cause for everyone who has observed similar problems, but at least just poking the connection settings in Gnome Settings is relatively safe.
Hope this helps some others.
pgbross
Doh!
So when a connection is getting a dynamic IP address via DHCP it will almost certainly receive the address of the DNS server to use, and likely it is you local router. So if you switch on DNSOverTLS and the local router doesn’t support it, then addresses resolution will fail.
To use the new settings specified in the resolved.conf as per the original article there are two options:
1) Enter the desired DNS server addresses in the Settings->Network tool (or editing the interface config in /etc/NetworkManager/network-scripts if one exists). E.g. 1.1.1.1,9.9.9.9
2) Enter the local systemd-resolved address 127.0.0.53 in the Settings->Network UI at which point the connection will ultimately use the local systemd resolver and pick its DNS and fallback from the settings in /etc/systemd/resolved.conf.
Once the change is made restart the NetworkManager and DNS resolution should work.
Gregory Bartholomew
Thanks for troubleshooting this for us pgbross.
So are you saying that it is the “dns=none” option documented in Step 2 that does not work?
P.S. The “dns=none” option is documented in “man NetworkManager.conf” and appears correct according to the documentation. I do note, however, that there is some strange wording about behaviors being dependent on what /etc/resolv.conf happens to be symlinked to. Considering the complexity of the documentation for the “dns” option, I’m not too surprised that people are having trouble with NetworkManager.
smeagol
Hi,
Thanks for the post.
Can the same be done when only using ifupdown? I don’t use Network Manager for several reasons, and ifupdown is much simpler.
dxdt
This post needs an update. You also need to add
as NetworkManager pushes DNS servers from DHCP servers by default. This post is the top result on Google, so..
https://unix.stackexchange.com/questions/602314/how-to-properly-enable-dnsovertls-on-systemd
Gregory Bartholomew
Done.
The resulting config file looks a little counter-intuitive, but it does appear to be what is suggested in the documentation (man NetworkManager.conf). I’m not able to verify this change personally as I do not use NetworkManager (I use systemd-networkd). Someone please let me know if the change in incorrect.
Thanks.
Marcelo
Not working for me. Can’t use Internet using those settings.
Any advice?