當(dāng)我第一次知道 DNS 時，我想它應(yīng)該不會很復(fù)雜。不就是一些存儲在服務(wù)器上的 DNS 記錄罷了。有什么大不了的？

但是教科書上只是介紹了 DNS 的原理，并沒有告訴你實際使用中 DNS 可能會以多少種方式破壞你的系統(tǒng)。這可不僅僅是緩存問題！

所以我 在 Twitter 上發(fā)起了一個提問，征集人們遇到的 DNS 問題，尤其是那些一開始看起來與 DNS 沒什么關(guān)系的問題。（“總是 DNS 問題”這個梗）

我不打算在這篇文章中討論如何解決或避免這些問題，但我會放一些討論這些問題的鏈接，在那里可以找到解決問題的方法。

問題：網(wǎng)絡(luò)請求緩慢

如果你的網(wǎng)絡(luò)比預(yù)期的要慢，這是因為某些原因?qū)е?DNS 解析器變慢了。這可能是解析器負載過大或者存在內(nèi)存泄漏等原因?qū)е碌摹?/p>

我的路由器的 DNS 轉(zhuǎn)發(fā)器曾遇到過這個問題，導(dǎo)致我的所有 DNS 請求很慢。我通過重啟路由器解決了這個問題。

問題：DNS 超時

一些網(wǎng)友提到由于 DNS 查詢超時，他們的網(wǎng)絡(luò)請求需要耗時 2 秒多甚至 30 秒。這跟“網(wǎng)絡(luò)請求緩慢”問題類似，但情況要更糟糕，因為 DNS 請求就會消耗掉幾秒鐘時間。

Sophie Haskins 有一篇關(guān)于 Kubernete DNS 超時的博客文章 一次 Kube DNS 踩坑經(jīng)歷。

問題：ndots 設(shè)置

一些網(wǎng)友提到在 /etc/resolv.conf 中設(shè)置 ndots:5 時會出現(xiàn)問題。

下面是從 這篇《Kubernetes 容器莢中 /etc/resolv.conf 里設(shè)置 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，那么你的程序會調(diào)用 getaddrinfo 函數(shù)，而它會依次查詢以下域名：

1. google.com.namespace.svc.cluster.local.
2. google.com.svc.cluster.local.
3. google.com.cluster.local.
4. google.com.eu-west-1.compute.internal.
5. google.com.

簡單來說，它會檢查 google.com 是不是 search 這一行中的某個子域名。

所以每發(fā)起一次 DNS 查詢，你都得先等待前 4 次查詢失敗后才能獲取到最終查詢結(jié)果。

問題：難以判斷系統(tǒng)使用的 DNS 解析器

這本身并不是一個問題，但當(dāng)你遇到 DNS 問題時，一般都會跟 DNS 解析器有關(guān)。我沒有一種判斷 DNS 解析器的萬能方法。

下面是我知道的方法：

• 在 Linux 系統(tǒng)上，最常見的是通過 /etc/resolv.conf 來選擇 DNS 解析器。但是也有例外，比如瀏覽器可能會忽略 /etc/resolv.conf，而是使用 基于 HTTPS 的 DNSDNS-over-HTTPS
• 如果你使用的是 UDP DNS，你可以通過 sudo tcpdump port 53 來查看 DNS 請求被發(fā)送到了哪里。但如果你使用的是基于 HTTPS 的 DNS 或 基于 TLS 的 DNSDNS over TLS，這個方法就不行了。

我依稀記得這在 MacOS 系統(tǒng)上會更加令人迷惑，我也不清楚原因。

問題：DNS 服務(wù)器返回 NXDOMAIN 而不是 NOERROR

這是我曾經(jīng)遇到過的一個 Nginx 不能解析域名的問題。

• 我設(shè)置 Nginx 使用一個特定的 DNS 服務(wù)器來解析 DNS 查詢
• 當(dāng)訪問這個域名時，Nginx 做了兩次查詢，第一次是對 A 的，第二次是對 AAAA 的
• 對于 A 的查詢，DNS 服務(wù)器返回 NXDOMAIN
• Nginx 認為這個域名不存在，然后放棄查詢
• 對于 AAAA 的查詢 DNS 服務(wù)器返回了成功
• 但 Nginx 忽略了對 AAAA 返回的查詢結(jié)果，因為它前面已經(jīng)放棄查詢了

問題出在 DNS 服務(wù)器本應(yīng)該返回 NOERROR 的——那個域名確實存在，只是沒有關(guān)于 A 的記錄罷了。我報告了這個問題，然后他們修復(fù)了這個問題。

我自己也寫出過這個問題，所以我理解為什么會發(fā)生這種情況——很容易想當(dāng)然地認為“沒有要查詢的記錄，就應(yīng)該返回 NXDOMAIN 錯誤碼”。

問題：自動生效的 DNS 緩存

如果你在生成一個域名的 DNS 記錄之前就訪問這個域名，那么這個記錄的缺失會被緩存起來。當(dāng)你第一次遇到這個問題時一定會非常吃驚——我也是去年才知道有這個問題。

緩存的 TTL 就是域名的 起始權(quán)限記錄Start of Authority（SOA） 記錄的 TTL ——比如對于 jvns.ca ，這個值是一個小時。

問題：Nginx 永久緩存 DNS 記錄

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

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

Nginx 只會在啟動的時候解析一次 some.domain.com，以后不會再對其進行解析。這是非常危險的操作，尤其是對于那些 IP 地址經(jīng)常變動的域名。它可能平安無事地運行幾個月，然后突然在某個凌晨兩點把你從床上糾起來。

針對這個問題已經(jīng)有很多眾所周知的方法了，但由于本文不是關(guān)于 Nginx 的，所以我不打算深入探討它。但你第一次遇到它時一定會很驚訝。

這是一篇關(guān)于這個問題發(fā)生在 AWS 負載均衡器上的 博客文章。

問題：Java 永久緩存 DNS 記錄

跟上面類似的問題，只是出現(xiàn)在 Java 上：據(jù)說 這與你 Java 的配置有關(guān)。“JVM 的默認 TTL 設(shè)置可能會導(dǎo)致只有 JVM 重啟時才會刷新 DNS 記錄?！?/p>

我還沒有遇到過這個問題，不過我那些經(jīng)常寫 Java 的朋友遇到過這個問題。

當(dāng)然，任何軟件都可能存在永久緩存 DNS 的問題，但據(jù)我所知它經(jīng)常出現(xiàn)在 Nginx 和 Java 上。

問題：被遺忘的 /etc/hosts 記錄

這是另一種緩存問題：/etc/hosts 中的記錄會覆蓋你的常規(guī) DNS 設(shè)置！

讓人迷惑的是 dig 命令會忽略 /etc/hosts 文件。所以當(dāng)你使用 dig whatever.com 來查詢 DNS 信息時，它會告訴你一切正常。

問題：電子郵件未發(fā)送 / 將成為垃圾郵件

電子郵件是通過 DNS（MX 記錄, SPF 記錄, DKIM 記錄）來發(fā)送和驗證的，所以有些電子郵件問題其實是 DNS 問題。

問題：對國際化域名無效

你可以使用非 ASCII 字符甚至是表情符來注冊域名，比如 拉屎網(wǎng) https://??.la。

DNS 能夠處理國際化域名是因為 ??.la 會被用 punycode 編碼將轉(zhuǎn)換為 xn--ls8h.la。

盡管已經(jīng)有了 DNS 處理國際化域名的標(biāo)準(zhǔn)，很多軟件并不能很好地處理國際化域名。Julian Squires 的 干掉 Chrome 瀏覽器的表情符??！ 就是一個非常有趣的例子。

問題：TCP DNS 被防火墻攔截

有人提到一些防火墻會允許在 53 端口上使用 UDP 協(xié)議，但是禁止 TCP 協(xié)議。然而很多 DNS 查詢需要在 53 端口上使用 TCP，這可能會導(dǎo)致很難排查的間歇性的問題。

問題：musl 不支持 TCP DNS

很多應(yīng)用程序使用 libc 的 getaddrinfo 來做 DNS 查詢。musl 是用在 Alpine Docker 容器上的 glibc 替代品。而它不支持 TCP DNS。如果你的 DNS 查詢的響應(yīng)數(shù)據(jù)超過 DNS UDP 數(shù)據(jù)包的大?。?12 字節(jié)）就會出現(xiàn)問題。

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

1. musl 的 getaddrinfo 發(fā)起一個 DNS 請求
2. DNS 服務(wù)器發(fā)現(xiàn)請求的響應(yīng)數(shù)據(jù)太大了，沒法放入一個 DNS 數(shù)據(jù)包中
3. DNS 服務(wù)器返回一個空截斷響應(yīng)empty truncated response，并期望客戶端通過 TCP DNS 重新用發(fā)起查詢
4. 但 musl 不支持 TCP DNS，所以根本不會重試

關(guān)于這個問題的文章：在 Alpine Linux 上的 DNS 解析問題。

問題：getaddrinfo 不支持輪詢 DNS

輪詢round robin DNS 是一種 負載均衡load balancing 技術(shù)，每次 DNS 查詢都會獲得一個不同的 IP 地址。顯然如果你使用 gethostbyname 做 DNS 查詢不會有任何問題，但是用 getaddrinfo 就不行了。因為 getaddrinfo 會對獲得的 IP 地址進行排序。

在你從 gethostbyname 切換到 getaddrinfo 時可能完全不會意識到這可能會引起負載均衡問題。

這個問題可能會非常隱蔽，如果你不是用 C 語言編程的話，這些函數(shù)調(diào)用被隱藏在各種調(diào)用庫背后，你可能完全意識不到發(fā)生了這種改變。所以某次看似人畜無害的升級就可能導(dǎo)致你的 DNS 負載均衡失效。

下面是討論這個的一些文章：

• getaddrinfo 導(dǎo)致輪詢 DNS 失效
• getaddrinfo，輪詢 DNS 和 happy eyeballs 算法

問題：啟動服務(wù)時的競爭條件

有人 提到 使用 Kubernete DNS 時遇到的問題：他們有兩個同時啟動的容器，一旦啟動就會立即嘗試解析對方的地址。由于 Kubernete DNS 還沒有改變，所以 DNS 查詢會失敗。這個失敗會被緩存起來，所以后續(xù)的查詢會一直失敗。

寫在最后

我所列舉的不過是 DNS 問題的冰山一角，期待大家告訴我那些我沒有提到的問題和相關(guān)鏈接。我希望了解這些問題在實際中是如何發(fā)生的以及如何被解決的。