最近有一台机器开启路由转发后，突然发现本机的DNS解析失效了。一般情况下新的Ubuntu通过netplan设置网络参数后不用再额外担心DNS的问题，但手动修改/etc/resolv.conf的话确实能够临时恢复网络访问。于是细究一下Ubuntu 18.04 的DNS管理方式。

/etc/resolv.conf

  这个配置文件由systemd-resolved服务管理，一般不推荐手动修改。实际上它本身是一个软链接：

root@test:~# ls -shal /etc/resolv.conf 
0 lrwxrwxrwx 1 root root 39 May  2 18:14 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
root@test:~# 

  当然，这个配置文件的注释部分给出了手动管理该文件的方式，就是将该文件由软链接替换为一个独立的静态文件。我们可以看到这个配置文件主要的参数有3行：

nameserver 127.0.0.53
options edns0
search localdomain

  其中，nameserver是最核心的参数，指定了本机进行DNS查询的域名服务器地址（另外两个无关紧要的参数options后的edns0是RFC2671提出的DNS扩展功能，search则指定了用于主机名解析使用的服务器）。系统默认的参数MAXNS允许我们配置最多三个DNS服务器（当然可以通过自建DNS服务解决这个问题）。

systemd-resolved

  systemd-resolved.service是管理DNS配置文件/etc/resolv.conf的系统服务。该服务自身提供了一个API可以在系统总线上被发起DNS请求的应用访问。就算本地应用是使用另一个更为常见的接口getaddrinfo进行DNS解析，也会最终被systemd-resolved所接管（通过一个叫nss-resolve的glibc组件实现）。除此之外，systemd-resolved服务在本地环回地址127.0.0.53上提供了一个监听服务，从而使那些不使用系统API进行DNS解析的应用也可以被systemd-resolved捕获到DNS请求。综上，一般情况下，只要这个服务是开着的，那么本地应用发起的DNS请求基本上就会被他接管。

  那么，怎样实现自定义的DNS服务器呢，那就是改变/etc/resolv.conf的文件格式。为了确保兼容性，当systemd-resolved发现/etc/resolv.conf不再是软链接的时候，就会额外选择从这个配置文件中读取DNS列表（当然默认的那些位置也会生效）。

为什么会失效

  我们继续分析，当systemd-resolved服务正常工作的时候，默认会从以下地方获取DNS服务器列表：

• 1.专门的解析配置文件：

/etc/systemd/resolved.conf
/etc/systemd/resolved.conf.d/*.conf
/run/systemd/resolved.conf.d/*.conf
/usr/lib/systemd/resolved.conf.d/*.conf

• 2.网络配置：

来自systemd.networkd服务接管的网络参数中的DNS部分

• 3.其他本地服务提供的DNS列表

默认情况下，我们不会特意开启这样的服务。

  上面3种途径中，真正生效的是来自网络配置中的DNS参数，因为那些默认的resolve解析配置文件并没有有效的DNS地址。而我们知道，最新的Ubuntu已经把网络服务托管给了netplan。那么理论上netplan就是决定了DNS的最终服务。

  可以通过下述命令查看当前DSN实际生效的情况：

root@DSY-SYYDK-NDH01:~# systemd-resolve --status
Global
         DNS Servers: 114.114.114.114
          DNSSEC NTA: 10.in-addr.arpa
···
Link 2 (eno1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 114.114.114.114
                      8.8.8.8

  注意，这是出现问题的主机回显。该主机实际上下方Link下的DNS配置（来自netplan网卡配置）并没有生效，实际生效的是Global下的DNS配置（来自被我们手动修改了的/etc/resolv.conf）。对比正常机器，发现正常机器的Link下的DNS配置是可以被正常读取的，所以，问题就集中在了为什么会网卡上的DNS配置会失效。

  折腾了半天，DNS工作原理倒是清楚了，但是为什么会失效，留到下次分析吧。