系统运维|DNS故障集锦及解决办法-不念博客

当我第一次知道 DNS 时，我想它应该不会很复杂。不就是一些存储在服务器上的 DNS 记录罢了。有什么大不了的？

但是教科书上只是介绍了 DNS 的原理，并没有告诉你实际使用中 DNS 可能会以多少种方式破坏你的系统。这可不仅仅是缓存问题！

所以我在 Twitter 上发起了一个提问，征集人们遇到的 DNS 问题，尤其是那些一开始看起来与 DNS 没什么关系的问题。（“总是 DNS 问题”这个梗）

我不打算在这篇文章中讨论如何解决或避免这些问题，但我会放一些讨论这些问题的链接，在那里可以找到解决问题的方法。

问题：网络请求缓慢

如果你的网络比预期的要慢，这是因为某些原因导致 DNS 解析器变慢了。这可能是解析器负载过大或者存在内存泄漏等原因导致的。

我的路由器的 DNS 转发器曾遇到过这个问题，导致我的所有 DNS 请求很慢。我通过重启路由器解决了这个问题。

问题：DNS 超时

一些网友提到由于 DNS 查询超时，他们的网络请求需要耗时 2 秒多甚至 30 秒。这跟“网络请求缓慢”问题类似，但情况要更糟糕，因为 DNS 请求就会消耗掉几秒钟时间。

Sophie Haskins 有一篇关于 Kubernete DNS 超时的博客文章一次 Kube DNS 踩坑经历。

问题：ndots 设置

一些网友提到在 /etc/resolv.conf中设置ndots:5时会出现问题。

下面是从这篇《Kubernetes 容器荚中/etc/resolv.conf里设置ndots:5为什么会拖慢你的程序性能》中引用的/etc/resolv.conf文件。

    nameserver 100.64.0.10
    search namespace.svc.cluster.local svc.cluster.local cluster.local eu-west-1.compute.internal
    options ndots:5

如果你用上面的配置文件，想要查询得域名是 google.com，那么你的程序会调用getaddrinfo函数，而它会依次查询以下域名：

google.com.namespace.svc.cluster.local.
google.com.svc.cluster.local.
google.com.cluster.local.
google.com.eu-west-1.compute.internal.
google.com.

简单来说，它会检查 google.com是不是search这一行中的某个子域名。

所以每发起一次 DNS 查询，你都得先等待前 4 次查询失败后才能获取到最终查询结果。

问题：难以判断系统使用的 DNS 解析器

这本身并不是一个问题，但当你遇到 DNS 问题时，一般都会跟 DNS 解析器有关。我没有一种判断 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 记录。”

我还没有遇到过这个问题，不过我那些经常写 Java 的朋友遇到过这个问题。

当然，任何软件都可能存在永久缓存 DNS 的问题，但据我所知它经常出现在 Nginx 和 Java 上。

问题：被遗忘的 /etc/hosts 记录

这是另一种缓存问题：/etc/hosts中的记录会覆盖你的常规 DNS 设置！

让人迷惑的是 dig命令会忽略/etc/hosts文件。所以当你使用dig whatever.com来查询 DNS 信息时，它会告诉你一切正常。

问题：电子邮件未发送 / 将成为垃圾邮件

电子邮件是通过 DNS（MX 记录, SPF 记录, DKIM 记录）来发送和验证的，所以有些电子邮件问题其实是 DNS 问题。

问题：对国际化域名无效

你可以使用非 ASCII 字符甚至是表情符来注册域名，比如拉屎网 https://💩.la。

DNS 能够处理国际化域名是因为 💩.la会被用 punycode 编码将转换为xn--ls8h.la。

尽管已经有了 DNS 处理国际化域名的标准，很多软件并不能很好地处理国际化域名。Julian Squires 的干掉 Chrome 浏览器的表情符！！就是一个非常有趣的例子。

问题：TCP DNS 被防火墙拦截

有人提到一些防火墙会允许在 53 端口上使用 UDP 协议，但是禁止 TCP 协议。然而很多 DNS 查询需要在 53 端口上使用 TCP，这可能会导致很难排查的间歇性的问题。

问题：musl 不支持 TCP DNS

很多应用程序使用 libc的getaddrinfo来做 DNS 查询。musl是用在 Alpine Docker 容器上的glibc替代品。而它不支持 TCP DNS。如果你的 DNS 查询的响应数据超过 DNS UDP 数据包的大小（512 字节）就会出现问题。

我对此仍然不太清楚，我下面我的理解也可能是错的:

musl的getaddrinfo发起一个 DNS 请求
DNS 服务器发现请求的响应数据太大了，没法放入一个 DNS 数据包中
DNS 服务器返回一个空截断响应empty truncated response，并期望客户端通过 TCP DNS 重新用发起查询
但 musl不支持 TCP DNS，所以根本不会重试

关于这个问题的文章：在 Alpine Linux 上的 DNS 解析问题。

问题：getaddrinfo 不支持轮询 DNS

轮询round robin DNS 是一种负载均衡load balancing 技术，每次 DNS 查询都会获得一个不同的 IP 地址。显然如果你使用 gethostbyname做 DNS 查询不会有任何问题，但是用getaddrinfo就不行了。因为getaddrinfo会对获得的 IP 地址进行排序。

在你从 gethostbyname切换到getaddrinfo时可能完全不会意识到这可能会引起负载均衡问题。

这个问题可能会非常隐蔽，如果你不是用 C 语言编程的话，这些函数调用被隐藏在各种调用库背后，你可能完全意识不到发生了这种改变。所以某次看似人畜无害的升级就可能导致你的 DNS 负载均衡失效。

下面是讨论这个的一些文章：