使用 DNS over TLS
DNS TLS
![](/data/attachment/album/202008/03/200139ufsvfoucavors3fr.jpg)


现代计算机用来在互联网种查找资源的 [域名系统（DNS）](https://en.wikipedia.org/wiki/Domain_Name_System) 是在 [35 年前](https://tools.ietf.org/html/rfc1035)设计的，没有考虑用户隐私。它会面临安全风险和攻击，例如 [DNS 劫持](https://en.wikipedia.org/wiki/DNS_hijacking)。它还能让 [ISP](https://en.wikipedia.org/wiki/Internet_service_provider) 拦截查询。


幸运的是，现在有 [DNS over TLS](https://en.wikipedia.org/wiki/DNS_over_TLS) 和 [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) 两种技术。DNS over TLS 和 DNSSEC 允许创建从计算机到它配置的 DNS 服务器之间的安全且加密的端到端隧道。在 Fedora 上，部署这些技术的步骤很容易，并且所有必要的工具也很容易获得。


本指南将演示如何使用 `systemd-resolved` 在 Fedora 上配置 DNS over TLS。有关 `systemd-resolved` 服务的更多信息，请参见[文档](https://www.freedesktop.org/wiki/Software/systemd/resolved/)。


### 步骤 1：设置 systemd-resolved


类似于下面所示修改 `/etc/systemd/resolved.conf`。确保启用 DNS over TLS 并配置要使用的 DNS 服务器的 IP 地址。



```
$ 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

```

关于选项的简要说明：


* `DNS`：以空格分隔的 IPv4 和 IPv6 地址列表，用作系统 DNS 服务器。
* `FallbackDNS`：以空格分隔的 IPv4 和 IPv6 地址列表，用作后备 DNS 服务器。
* `Domains`：在解析单标签主机名时，这些域名用于搜索后缀。 `~.` 代表对于所有域名，优先使用 `DNS=` 定义的系统 DNS 服务器。
* `DNSOverTLS`：如果启用，那么将加密与服务器的所有连接。请注意，此模式要求 DNS 服务器支持 DNS-over-TLS，并具有其 IP 的有效证书。



> 
> 注意：上面示例中列出的 DNS 服务器是我个人的选择。你要确定要使用的 DNS 服务器。要注意你要向谁请求 IP。
> 
> 
> 


### 步骤 2：告诉 NetworkManager 将信息推给 systemd-resolved


在 `/etc/NetworkManager/conf.d` 中创建一个名为 `10-dns-systemd-resolved.conf` 的文件。



```
$ cat /etc/NetworkManager/conf.d/10-dns-systemd-resolved.conf
[main]
dns=systemd-resolved

```

上面的设置（`dns=systemd-resolved`）让 `NetworkManager` 将从 DHCP 获得的 DNS 信息推送到 `systemd-resolved` 服务。这将覆盖*步骤 1* 中配置的 DNS 设置。这在受信任的网络中没问题，但是也可以设置为 `dns=none` 从而使用 `/etc/systemd/resolved.conf` 中配置的 DNS 服务器。


### 步骤 3： 启动和重启服务


若要使上述步骤中的配置生效，请启动并启用 `systemd-resolved` 服务。然后重启 `NetworkManager` 服务。


注意：在 `NetworkManager` 重启时，连接会中断几秒钟。



```
$ sudo systemctl start systemd-resolved
$ sudo systemctl enable systemd-resolved
$ sudo systemctl restart NetworkManager

```


> 
> 注意：目前，systemd-resolved 服务默认处于禁用状态，是可选使用的。[有计划][33]在 Fedora 33 中默认启用systemd-resolved。
> 
> 
> 


### 步骤 4：检查是否一切正常


现在，你应该在使用 DNS over TLS。检查 DNS 解析状态来确认这一点：



```
$ 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` 应该指向 `127.0.0.53`。



```
$ cat /etc/resolv.conf
# Generated by NetworkManager
search lan
nameserver 127.0.0.53

```

若要查看 `systemd-resolved` 发送和接收安全查询的地址和端口，请运行：



```
$ 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))

```

若要进行安全查询，请运行：



```
$ 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

```

### 额外步骤 5：使用 Wireshark 验证配置


首先，安装并运行 [Wireshark](https://www.wireshark.org/)：



```
$ sudo dnf install wireshark
$ sudo wireshark

```

它会询问你在哪个设备上捕获数据包。在我这里，因为我使用无线接口，我用的是 `wlp58s0`。在 Wireshark 中设置筛选器，`tcp.port == 853`（853 是 DNS over TLS 协议端口）。在捕获 DNS 查询之前，你需要刷新本地 DNS 缓存：



```
$ sudo resolvectl flush-caches

```

现在运行：



```
$ nslookup fedoramagazine.org

```

你应该会看到你的计算机和配置的 DNS 服务器之间的 TLS 加密交换：


![](/data/attachment/album/202008/03/200141wlbeo9m0e1m9loml.png)




---


via: <https://fedoramagazine.org/use-dns-over-tls/>


作者：[Thomas Bianchi](https://fedoramagazine.org/author/thobianchi/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
The [Domain Name System (DNS)](https://en.wikipedia.org/wiki/Domain_Name_System) that modern computers use to find resources on the internet was designed [35 years ago](https://tools.ietf.org/html/rfc1035) without consideration for user privacy. It is exposed to security risks and attacks like [DNS Hijacking](https://en.wikipedia.org/wiki/DNS_hijacking). It also allows [ISPs](https://en.wikipedia.org/wiki/Internet_service_provider) to intercept the queries.

Luckily, [DNS over TLS](https://en.wikipedia.org/wiki/DNS_over_TLS) and [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) 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](https://www.freedesktop.org/wiki/Software/systemd/resolved/) 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 statusMulticastDNS 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.orgfedoraproject.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](https://www.wireshark.org/):

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

![](https://fedoramagazine.org/wp-content/uploads/2020/06/1-1024x651.png)

— *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’tbe 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?