Use DNS over TLS

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

FAQs and Guides

50 Comments

  1. David Yip

    Even Network Solutions doesn’t support DNSSEC DS upload….

  2. 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.

  3. 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.

    • 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.

      $ for i in *; do echo "--- BEGIN $PWD/$i:"; cat $i; echo "--- END $PWD/$i"; echo; done
      --- BEGIN /etc/systemd/network/20-wg0.netdev:
      cat: 20-wg0.netdev: Permission denied
      --- END /etc/systemd/network/20-wg0.netdev
      
      --- BEGIN /etc/systemd/network/25-wg0.network:
      [Match]
      Name=wg0
      
      [Network]
      LinkLocalAddressing=no
      Domains=~siue.edu
      DNSOverTLS=no
      DNSSEC=no
      DNS=146.163.252.126
      DNS=146.163.252.127
      Address=172.26.0.1/16
      Address=172.27.0.1/16
      
      [Route]
      Destination=192.168.0.0/24
      Gateway=172.27.255.254
      
      [Route]
      Destination=146.163.0.0/16
      Gateway=172.26.255.254
      
      --- END /etc/systemd/network/25-wg0.network
      
      --- BEGIN /etc/systemd/network/80-enp2s0.network:
      [Match]
      Name=enp2s0
      
      [Network]
      Address=192.168.1.2/24
      Gateway=192.168.1.1
      Domains=~.
      DNSOverTLS=yes
      DNSSEC=yes
      DNS=8.8.8.8
      DNS=8.8.4.4
      
      [Route]
      Destination=146.163.150.253
      Gateway=192.168.1.1
      
      --- END /etc/systemd/network/80-enp2s0.network
      
      • 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.

        • … 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. …

          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.

          • 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.

        • … assuming you trust Cloudflare …

          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.

  4. Graham King

    This did not work for me on Fedora 32.

    If I follow step 2,

    /etc/resolv.conf

    gets

    nameserver 127.0.0.53

    but I can’t connect (NetworkManager icon stays on question mark).

    If at step 2 I do

    dns=none

    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.

  5. Johannes

    Wont work, thanks anyway though!

  6. John Harris

    It’d be preferable not to suggest using Cloudflare and Google DNS.. They have no respect for your privacy.

  7. Andre

    Works, thanks!
    Is it possible to do a “round robin” with the dns-servers i choose?

  8. 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.

  9. 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?

    • 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:

      dnf search --releasever=28 wireshark

      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.

  10. 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

  11. 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.

  12. Alan Olsen

    This doesn’t work with VPN tunnels. (At least mine.) Also needs more info on IPv6 usage.

  13. james

    Sounds like a really good idea, but it doesn’t work on my workstation f32.

  14. This guide does not work on Fedora Core 32.

    Please remove it.

  15. This guide left me and is likely to leave its followers with a broken DNS resolver.

    Please remove this “guide” from Fedora Magazine.

  16. Michael W

    This is just way too short of a discussion over the value of this, and the issues that this suggestion could cause.

  17. cedzik

    i found a soulution: in /etc/systemd/resolved.conf uncoment #Domains=~. then restart systemd-resolved

    sudo systemctl start systemd-resolved
  18. 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)

    • 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:

      $ ls -al /etc/resolv.conf 
      lrwxrwxrwx. 1 root root 37 Jun  5 08:57 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
      

      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:

        $ resolvectl status  #in here everything seems ok.
        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:

        $ resolvectl status wlp2s0  #but in here dns seems wrong
        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:

        $ dnsleaktest.sh
        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.

        $ dnsleaktest.sh
        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:

        $ cat /etc/systemd/resolved.conf
        [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
        $  cat /etc/NetworkManager/conf.d/10-dns-systemd-resolved.conf
        [main]
        dns=none

        My status:

        # systemctl status systemd-resolved.service
        ● 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.
        # systemctl status NetworkManager
        ● 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
        # resolvectl status
        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

        • Hi Rojen:

          From man nm-settings-ifcfg-rh:

          ·   PEERDNS - initscripts interpret PEERDNS=no to mean "never touch resolv.conf". NetworkManager interprets it to say "never add
              automatic (DHCP, PPP, VPN, etc.) nameservers to resolv.conf".
          

          I would suggest that you try adding the line:

          PEERDNS="no"

          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:

            [root@linux ~]# cat /etc/sysconfig/network-scripts/ifcfg-Amedî | grep -n3 'DNS1'
            18-DEVICE=wlp2s0
            19-ONBOOT=yes
            20-PEERDNS="no"
            21:DNS1=9.9.9.9
            [root@linux ~]# !runuser
            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.
            [root@linux ~]# resolvectl status wlp2s0
            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.)

            • Hi Rogen:

              The Fallback DNS servers should show up in the output of resovectl status:

              # resolvectl status | grep -A 7 "^Fallback DNS Servers:"
              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:

              # cat /etc/systemd/resolved.conf.d/override.conf
              [Resolve]
              FallbackDNS=
              # systemctl restart systemd-resolved.service
              # resolvectl status | grep -A 7 "^Fallback DNS Servers:"
              #
  19. rtghrt

    why not show example in ipv6?

  20. tmp2k

    this is not good because it does not work

    • tmp2k

      ok uncommented domains ~. works 😉

      • 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.

  21. 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

  22. 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.

    • 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..

  23. 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.

    • 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.

  24. 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.

    • 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.

  25. 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.

  26. dxdt

    This post needs an update. You also need to add

    systemd-resolved=false

    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

    • 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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions

%d bloggers like this: