Ubuntu 18.04 systemd 解决的错误 NXDOMAIN

Question

我已经安装了 Ubuntu 18.04，系统日志显示以下错误：

systemd-resolved: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

这是什么意思，我该如何解决这些错误消息？

Answer 1

最短和最简单的答案是这样的：

系统日志中的这些“错误”是DVE-2018-0001 中确定的解决方法的结果，表明系统正在尝试通过重试没有 EDNS 扩展的相同请求来缓解 DVE-2018-0001 违规的进一步情况。这并不表示您可以自行修复错误，也不意味着在这种情况下需要修复任何问题。

它只是表明该systemd-resolved服务正在尝试重试相同的查询，以尝试防止 DVE-2018-0001 的进一步问题，这可能是由不支持 EDNS0 扩展的强制门户引起的。

在这种情况下，您无需采取进一步行动，这是由 提供给系统日志的更多“信息性”信息systemd-resolved。

但是……如果您想更多地了解这里发生的事情，请继续阅读，我提供了此摘要和一些示例数据，以向您展示这些消息背后到底发生了什么。

详细信息（如果您愿意阅读）：

您看到的错误实际上并不是您必须采取行动的错误消息，并且“服务器返回错误”的声明具有误导性。相反，这是一个通知，表明我们正在遵循DNS Violation DVE-2018-0001 中定义的解决方法。

这是我的计算机上的日志本身的示例：

Feb  5 13:29:17 overlord systemd-resolved[857]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

根据 DVE-2018-0001，发现在 Ubuntu 17.10 及更高版本中：

当尝试连接到 securelogin.arubanetworks.com 上的强制门户并对其进行授权时，在某些时候无法正确解析，因此用户无法通过强制门户授权并访问互联网。

此外，这继续解释问题：

最初这是关于 Ubuntu 错误跟踪器的报告，网址为https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237

这可能是 Ubuntu/systemd-resolved 和/或 securelogin.arubanetworks.com DNS 欺骗/囚禁和/或两者中的错误。

从数据包捕获看来，EDNS0 DO（DNSSEC OK）位设置为零的 DNS 查询是用 NXDOMAIN 响应的。

没有 EDNS0 的请求将使用正确的门户 IP 地址进行响应。

这意味着这里的强制门户有某些响应不能正确支持 EDNS0 查询；并且这需要由制造商进行调整。

当前systemd-resolved在 Ubuntu 中实施的解决方法是生成您看到的信息性消息。这与 DVE 中建议的解决方法结合使用（粗体文本强调和命令名称和代码/响应的纯文本格式是我的）：

在 中systemd-resolved，在查找包含“secure”的域名并收到响应时NXDOMAIN，请在不使用 EDNS0 的情况下重试。

因此，这就是您的消息所陈述的内容，但覆盖范围更广。也就是说，当提交 DNS 请求并且您NXDOMAIN从 DNS 查找中得到响应时，我们要确保我们没有遇到这个 EDNS0 问题；因此，systemd-resolved正在再次尝试 DNS 查找，但没有 EDNS0 扩展 - 我们可以在我的 Bind9 名称服务器中看到这一点，它也通过一个示例处理我机器上的所有请求（尽管这是查询非域的主要示例，并且反过来，这是当“缓解”实际上无法解决令人头疼的问题时，这种缓解如何表现出来的主要示例）：

05-Feb-2019 13:29:17.976 queries: info: client @0x7f6cd400aee0 127.0.0.1#41213 (favicon.png): query: favicon.png IN A +E(0) (127.0.2.1)
05-Feb-2019 13:29:17.976 queries: info: client @0x7f6cd400aee0 127.0.0.1#41213 (favicon.png): query: favicon.png IN A + (127.0.2.1)

如您所见，请求不是 +E(0)，而是在没有扩展名的情况下重试；这是“降低功能级别的 UDP”请求行为。

Answer 2

尽管这不是实际错误，但如果您希望这些消息停止，您可以更改/etc/resolv.conf符号链接指向的目标。默认情况下，它指向/run/systemd/resolve/stub-resolv.conf。通过将其更改为指向/run/systemd/resolve/resolv.conf问题就消失了。

执行此操作的命令是 sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf