系统运维|DNS故障集锦及解决办法(2)

系统运维|DNS故障集锦及解决办法

下面是我知道的方法：

• 在 Linux 系统上，最常见的是通过/etc/resolv.conf来选择 DNS 解析器。但是也有例外，比如浏览器可能会忽略/etc/resolv.conf，而是使用 基于 HTTPS 的 DNSDNS-over-HTTPS 服务。
• 如果你使用的是 UDP DNS，你可以通过sudo tcpdump port 53来查看 DNS 请求被发送到了哪里。但如果你使用的是基于 HTTPS 的 DNS 或 基于 TLS 的 DNSDNS over TLS，这个方法就不行了。

我依稀记得这在 MacOS 系统上会更加令人迷惑，我也不清楚原因。

问题：DNS 服务器返回 NXDOMAIN 而不是 NOERROR

这是我曾经遇到过的一个 Nginx 不能解析域名的问题。

• 我设置 Nginx 使用一个特定的 DNS 服务器来解析 DNS 查询
• 当访问这个域名时，Nginx 做了两次查询，第一次是对A的，第二次是对AAAA的
• 对于A的查询，DNS 服务器返回NXDOMAIN
• Nginx 认为这个域名不存在，然后放弃查询
• 对于AAAA的查询 DNS 服务器返回了成功
• 但 Nginx 忽略了对AAAA返回的查询结果，因为它前面已经放弃查询了

问题出在 DNS 服务器本应该返回NOERROR的——那个域名确实存在，只是没有关于A的记录罢了。我报告了这个问题，然后他们修复了这个问题。

我自己也写出过这个问题，所以我理解为什么会发生这种情况——很容易想当然地认为“没有要查询的记录，就应该返回NXDOMAIN错误码”。

问题：自动生效的 DNS 缓存

如果你在生成一个域名的 DNS 记录之前就访问这个域名，那么这个记录的缺失会被缓存起来。当你第一次遇到这个问题时一定会非常吃惊——我也是去年才知道有这个问题。

缓存的 TTL 就是域名的 起始权限记录Start of Authority（SOA） 记录的 TTL ——比如对于jvns.ca，这个值是一个小时。

问题：Nginx 永久缓存 DNS 记录

如果你在 Nginx 中使用下面的配置：

    location / {
        proxy_pass https://some.domain.com;
    }

Nginx 只会在启动的时候解析一次some.domain.com，以后不会再对其进行解析。这是非常危险的操作，尤其是对于那些 IP 地址经常变动的域名。它可能平安无事地运行几个月，然后突然在某个凌晨两点把你从床上纠起来。

针对这个问题已经有很多众所周知的方法了，但由于本文不是关于 Nginx 的，所以我不打算深入探讨它。但你第一次遇到它时一定会很惊讶。

这是一篇关于这个问题发生在 AWS 负载均衡器上的 博客文章。

问题：Java 永久缓存 DNS 记录

跟上面类似的问题，只是出现在 Java 上：据说这与你 Java 的配置有关。“JVM 的默认 TTL 设置可能会导致只有 JVM 重启时才会刷新 DNS 记录。”