永远不要使用二级域名作为 Linux Hostname

最近发现了使用二级域名作为 Linux Hostname 会有坑，甚至还会造成潜在的信息安全问题。因此写了一篇博客，总结如下，全文可以在 https://josephcz.xyz/technology/linux/never-use-2ld-as-hostname/ 阅读

如果我们使用二级域名作为 Hostname

倘若我们将服务器的 Hostname 切换为二级域名，例如 example[.]com 时，会发生什么呢？在这里我们假设一个没有被任何人注册的域名，例如 some-not-registered-domain[.]com；并假设 com[.]com 这一域名被恶意人士注册。

接下来，我们使用 ping 命令，加上需要解析的域名，看看实际访问的域名时哪一个：

是的，在使用二级域名作为 Hostname 的情况下，当 ping 一个尚未注册的域名 some-not-registered-domain[.]com 时，由于 Hostname 和 Search Domain 的配置，会自动 fallback 到 some-not-registered-domain[.]com[.]com 上！遗憾的是，不管是否使用 Search Domain ，这个问题都存在——而将 Hostanme 设置为 FQDN 让这个问题更加隐蔽了。

这个问题不仅影响了 ping 、curl ，也影响了几乎所有使用 glibc 的程序：OpenSSL 、MySQL 、Nginx 、Apache……等等。如果它们的某个功能需要解析域名，则都会有同样的问题。

未被注册的域名值得警惕，但是这一问题如果发生在你自己的域名上呢？

如果我们使用已经被注册的域名作为 Hostname

回到我遇到的问题上来。我刚刚设置了 api-v2023[.]josephcz[.]xyz 这一域名的解析。而 DNS 解析的生效需要时间，在递归 DNS 未获取到生效的记录的情况下，会返回一个空记录。而空记录和 NXDOMAIN 错误一样，会触发 Search Domain 的 fallback 机制。因此，服务器上对 api-v2023[.]josephcz[.]xyz 全部被发送到了 api-v2023[.]josephcz[.]xyz[.]xyz。

使用 tcpdump -i ens3 -nt -s 500 port domain 命令可以清楚地看到这一过程：

IP 10.0.0.12.57943 > 1.1.1.1.53: 27244+ A? api-v2023[.]josephcz[.]xyz. (35)
IP 10.0.0.12.57943 > 1.1.1.1.53: 19043+ AAAA? api-v2023[.]josephcz[.]xyz. (35)
IP 1.1.1.1.53 > 10.0.0.12.57943: 19043 0/1/0 (106)
IP 1.1.1.1.53 > 10.0.0.12.57943: 27244 0/1/0 (106)
IP 10.0.0.12.46092 > 1.1.1.1.53: 51629+ A? api-v2023[.]josephcz[.]xyz[.]xyz. (39)
IP 10.0.0.12.46092 > 1.1.1.1.53: 61104+ AAAA? api-v2023[.]josephcz[.]xyz[.]xyz. (39)
IP 1.1.1.1.53 > 10.0.0.12.46092: 51629 3/0/0 CNAME xyz[.]xyz., A 52.9.36.254, A 54.241.183.58 (85)

好在 XYZ 域名的注册局保留了 XYZ[.]XYZ。但是如果换成解析其他域名，例如 some-api-host[.]aws 或者 pki[.]goog，而相关域名的注册局又忘记保留了 aws、goog 之类的域名呢？

结论

在设置 Linux 的 Hostname 时，永远不要使用一个二级域名——无论是将 Hostname 设置为 FQDN 还是配置 Search Domain 。永远使用一个三级或以上的、受你自己控制的域名作为 Hostname 。

此外，启用强制性的 TLS 并正确部署证书信任也可以在一定程度上缓解这一问题——由于对方无法获得正确的 TLS 证书，即使解析被 fallback 到恶意攻击者的域名上，也难以窃取你的机密信息。