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

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

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

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

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

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

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

問題：DNS 超時(shí)

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

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

問題：ndots 設(shè)置

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

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

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.

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

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

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

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

下面是我知道的方法：

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

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

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

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

• 我設(shè)置 Nginx 使用一個(gè)特定的 DNS 服務(wù)器來解析 DNS 查詢
• 當(dāng)訪問這個(gè)域名時(shí)，Nginx 做了兩次查詢，第一次是對(duì) A 的，第二次是對(duì) AAAA 的
• 對(duì)于 A 的查詢，DNS 服務(wù)器返回 NXDOMAIN
• Nginx 認(rèn)為這個(gè)域名不存在，然后放棄查詢
• 對(duì)于 AAAA 的查詢 DNS 服務(wù)器返回了成功
• 但 Nginx 忽略了對(duì) AAAA 返回的查詢結(jié)果，因?yàn)樗懊嬉呀?jīng)放棄查詢了

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

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

問題：自動(dòng)生效的 DNS 緩存

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

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

問題：Nginx 永久緩存 DNS 記錄

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

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

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

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

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

問題：Java 永久緩存 DNS 記錄

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

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

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

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

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

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

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

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

問題：對(duì)國際化域名無效

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

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

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

問題：TCP DNS 被防火墻攔截

有人提到一些防火墻會(huì)允許在 53 端口上使用 UDP 協(xié)議，但是禁止 TCP 協(xié)議。然而很多 DNS 查詢需要在 53 端口上使用 TCP，這可能會(huì)導(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é)）就會(huì)出現(xiàn)問題。

我對(duì)此仍然不太清楚，我下面我的理解也可能是錯(cuò)的:

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

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

問題：getaddrinfo 不支持輪詢 DNS

輪詢r(jià)ound robin DNS 是一種 負(fù)載均衡load balancing 技術(shù)，每次 DNS 查詢都會(huì)獲得一個(gè)不同的 IP 地址。顯然如果你使用 gethostbyname 做 DNS 查詢不會(huì)有任何問題，但是用 getaddrinfo 就不行了。因?yàn)?nbsp;getaddrinfo 會(huì)對(duì)獲得的 IP 地址進(jìn)行排序。

在你從 gethostbyname 切換到 getaddrinfo 時(shí)可能完全不會(huì)意識(shí)到這可能會(huì)引起負(fù)載均衡問題。

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

下面是討論這個(gè)的一些文章：

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

問題：啟動(dòng)服務(wù)時(shí)的競爭條件

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

寫在最后

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