☰

systemd 的 127.0.0.53 处的 DNS 忽略了一些查找

tag-icon • tag-icon networking 18.04 dns
systemd 的 127.0.0.53 处的 DNS 忽略了一些查找

除了我按名称查询本地机器时，systemd 的 DNS 127.0.0.53 似乎可以正常工作。但如果我查询它们并明确指定本地 DNS 服务器（我的路由器），那么我会得到正确的答复。但配置文件说它也使用路由器作为搜索地址。有什么想法吗？

我在我的戴尔笔记本电脑上运行着 Ubuntu 18.04。

错误结果：

$ nslookup web1

Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find web1: SERVFAIL

也失败了

$ nslookup -i wlp3s0 web1
nslookup: couldn't get address for 'web1': not found

正确结果：

$ nslookup web1 192.168.1.1

Server:     192.168.1.1
Address:    192.168.1.1#53

Name:   web1
Address: 192.168.1.107

配置信息 systemd-resolve

$ systemd-resolve --status

Global
          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 3 (wlp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
          DNS Domain: wp.comcast.net

Link 2 (enp2s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

配置信息 NetworkManager

$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

那么我该如何让 nslookup 返回正确的答案？链接 3 似乎是正确的信息（我的 wifi 连接），路由器上的 DNS 也返回了正确的答案，但本地缓存从未尝试查找地址（或看起来如此）。

答案1

我找到了对我有用的修复方法。

我的 resolv.conf 文件指向了错误的位置。这似乎是 Ubuntu 中的一个错误，因为它发生在我的笔记本电脑上（我第一次注意到这个问题的机器）和全新安装的 Ubuntu 18.04 Server 上。

默认

$ ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 39 Apr 26 12:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

我删除了它并指向正确的文件。重启后，我的问题就解决了。我甚至可以在笔记本电脑上切换网络，DNS 切换正确。当然，在外部网络上时，我无法解析任何本地机器，但这是意料之中的。一旦我切换回本地网络，所有本地机器都会正确解析，因为我的路由器就是 DNS。

修复

$ sudo unlink /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 32 May 29 08:48 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

$ sudo reboot

此后，一切都按我预期的那样工作，并且 127.0.0.53 不再被使用。

正确的结果

$ nslookup web1

Server:     192.168.1.1
Address:    192.168.1.1#53

Name:   web1
Address: 192.168.1.107

$ nslookup google.com

Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.7.174
Name:   google.com
Address: 2607:f8b0:4004:80e::200e

答案2

你的 resolv.conf 文件没有指向错误的位置——../run/systemd/resolve/stub-resolv.conf 是它默认应该指向哪里。

问题是它systemd-resolved不会将非点名称传递到 DNS。显然，这是“按设计”工作的。请参阅这个 github 问题其声明“已解析的内容永远不会允许单标签查找泄漏到单播 DNS 上”。

无论你是否同意 github 问题中的理由，是解决这个问题的方法。它甚至不需要对 Ubuntu 机器上的默认设置进行任何更改：

  1. 首先你的局域网的DNS必须有一个域名。

    /etc/dnsmasq.conf如果您使用 dnsmasq，请在 DNS 服务器上添加以下内容：

    expand-hosts
domain=your-domain # replace "your-domain" with domain of your choice

    如果您添加域，您现在应该能够解析 LAN 主机名：

    nslookup web1.your-domain

  2. 其次，如果 LAN 域名与 DNS 服务器不同，请确保 DHCP 服务器中也设置了 LAN 域名。在我的 DHCP 服务器（我的路由器）上，此设置称为“域名”。

    如果您随后在 Ubuntu 机器上更新 DHCP 租约，您应该会看到一个搜索指令出现在/run/systemd/resolve/stub-resolv.conf：

    nameserver 127.0.0.53
search your-domain

现在查找web1将其扩展为web1.your-domain，然后使用 DNS 进行解析。

$ nslookup web1
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   web1.your-domain
Address: 192.168.1.107

请注意，如果您使用dig而不是nslookup，dig则默认不使用搜索路径——请使用其+search选项来启用该功能。

答案3

有时删除符号链接/etc/resolv.conf是正确的要做的事。

我最近将我们的权威 DNS 服务器迁移到了新建的主机上，该主机（与之前的主机不同）安装了 systemd。

结果是糟糕的。

尽管世界其他地方会看到正确的结果，但 systemd 解析器会向本地服务提供过时的结果，这会扰乱其他服务，尤其是内部邮件转发器。

dig @127.0.0.53会显示它不时地将 TTL 重新增加，因此它的缓存永远不会过期；我怀疑它实际上是在查询自身，因为 NS 指向该主机。

跑步systemd-resolve --flush-caches没有任何作用。

编辑/etc/systemd/resolved.conf和设置DNSStubListener=no最终停止了解析器的运行，尽管它似乎时不时地弹出几秒钟。

至少现在传统服务实际上可以得到正确的答案，但通过 DBUS 执行名称查找的服务却无法挽回地崩溃了。

现在我明白了为什么这么多人讨厌 systemd；它会干扰它本不该接触的其他子系统，而且没有有效的方法阻止它这样做。即使 NIS 也没有这么严重；为什么 systemd 需要改变它并让它变得更糟？

相关内容