系统运维|DNS故障集锦及解决办法。小编来告诉你更多相关信息。
系统运维|DNS故障集锦及解决办法
小编为大家解答系统运维|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 解析器的万能方法。
系统运维|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 记录。”
系统运维|DNS故障集锦及解决办法。小编来告诉你更多相关信息。
系统运维|DNS故障集锦及解决办法
我还没有遇到过这个问题，不过我那些经常写 Java 的朋友遇到过这个问题。
当然，任何软件都可能存在永久缓存 DNS 的问题，但据我所知它经常出现在 Nginx 和 Java 上。
问题：被遗忘的 /etc/hosts 记录
这是另一种缓存问题：/etc/hosts中的记录会覆盖你的常规 DNS 设置！
让人迷惑的是dig命令会忽略/etc/hosts文件。所以当你使用dig whatever.com来查询 DNS 信息时，它会告诉你一切正常。
问题：电子邮件未发送 / 将成为垃圾邮件
电子邮件是通过 DNS（MX 记录, SPF 记录, DKIM 记录）来发送和验证的，所以有些电子邮件问题其实是 DNS 问题。
问题：对国际化域名无效
你可以使用非 ASCII 字符甚至是表情符来注册域名，比如 拉屎网 https://
