永远不要使用二级域名作为 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 到恶意攻击者的域名上，也难以窃取你的机密信息。