要求 DNS 伺服器響應未知域請求的 RFC
我的域名註冊商和 DNS 提供目前忽略對未知域的 DNS 請求。忽略我的意思是黑洞並且從不響應，這會導致我的 DNS 客戶端和解析器庫重試、退出並最終超時。
dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org ... ;; connection timed out; no servers could be reached在調查其他流行的域名服務時，我發現這種行為非常獨特，因為其他提供商返回的 RCODE 為 5（REFUSED）：
dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org全部返回如下內容：
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732或者
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219恕我直言，返回
REFUSED或NXDOMAIN立即返回是合適的，而不是僅僅將請求放在伺服器機房地板上。當我向我的提供商抱怨他們的伺服器沒有響應時，他們要求我引用他們的伺服器違反的 RFC。我知道他們要求我證明他們的伺服器應該響應所有請求很奇怪，但就這樣吧。
問題：
- 我的規定是，除非有重複的請求 ID 或某種 DOS 響應，否則伺服器應始終響應請求。它是否正確？
- 我應該引用什麼 RFC 和特定部分來支持我的規定？
對我來說，不響應 DNS 查詢是不好的。大多數客戶端會後退，然後將相同的查詢重新傳輸到同一 DNS 伺服器或另一台伺服器。它們不僅會減慢客戶端速度，還會導致它們自己或其他伺服器再次執行相同的查詢，具體取決於權威名稱伺服器和 NS 條目。
在RFC 1536和2308中，出於性能原因和停止重新傳輸同一查詢，我看到了很多關於負記憶體的資訊。在4074中，我看到有關返回 RCODE 為 0 的空答案的資訊，因此客戶端知道沒有 ipv6 資訊，這應該導致客戶端詢問 A RR，這是空響應的另一個範例。
但是我找不到說 DNS 伺服器應該響應請求的 RFC，可能是因為它是隱含的。
當我將我的域（和相關的 DNS 記錄）遷移到他們的伺服器時或在我向他們的服務註冊新域後的前 X 分鐘時，就會出現特定問題。權威名稱伺服器更改的時間（這幾天非常快）和他們的伺服器開始為我的 DNS 記錄提供服務之間存在延遲。在這段延遲時間內，DNS 客戶端認為他們的伺服器是權威的，但他們從不響應請求——即使是
REFUSED. 我理解延遲很好，但我不同意不響應 DNS 請求的決定。作為記錄，我了解如何在他們的系統中解決這些限制，但我仍在與他們合作以改進他們的服務以更符合 DNS 協議。謝謝您的幫助。
編輯：
在發布此內容並跟進我的提供商的幾個月內，他們更改了伺服器以返回
NXDOMAIN未知域。
Shane的建議是正確的。在啟動切換之前未能將數據從一個權威伺服器遷移到另一個權威伺服器會導致中斷。無論從那時起發生什麼，這都是由揮動 NS 記錄的人發起的中斷。這解釋了為什麼沒有更多人向您的提供者投訴。
也就是說，這仍然是一個有趣的問題要回答，所以我要好好研究一下。
DNS 伺服器的基本功能包含在文件RFC 1034和RFC 1035中，它們共同構成STD 13。答案必須要麼來自這兩個 RFC，要麼由稍後更新它的 RFC 澄清。
在我們繼續之前，需要指出 DNS 範圍之外的一個巨大缺陷：這兩個 RFC 都早於BCP 14 (1997)，該文件闡明了 MAY、MUST、SHOULD 等語言。
- 在這種語言正式化之前製定的標準可能使用了清晰的語言，但在某些情況下沒有。這導致了軟體的不同實現、大規模混亂等。
- 不幸的是，STD 13 在幾個方面都具有解釋性。如果操作領域的語言不明確，則經常需要找到一個澄清的 RFC。
有了這個，讓我們從RFC 1034 §4.3.1的內容開始：
- 伺服器最簡單的模式是非遞歸的，因為它可以僅使用本地資訊來回答查詢：響應包含錯誤、答案或對“更接近”答案的其他伺服器的引用。所有名稱伺服器都必須實現非遞歸查詢。
…
如果遞歸服務未被請求或不可用，則非遞歸響應將是以下之一：
- 指示名稱不存在的權威名稱錯誤。
- 臨時錯誤指示。
- 一些組合：
回答問題的 RR，以及數據是來自區域還是被記憶體的指示。
對名稱伺服器的引用，該名稱伺服器的區域比發送回复的伺服器更接近名稱的祖先。
- 名稱伺服器認為對請求者有用的 RR。
這裡的語言相當堅定。沒有“應該”，只有“將”。這意味著最終結果必須是 1) 在上面的列表中定義的，或 2) 由標準軌道上的稍後文件允許，該文件修改了功能。我不知道存在任何忽略該請求的措辭，我會說開發人員有責任找到反駁研究的語言。
鑑於 DNS 在網路濫用場景中的頻繁作用，更不要說 DNS 伺服器軟體不提供旋鈕來選擇性地丟棄現場流量，這在技術上違反了這一點。也就是說，這些要麼不是預設行為，要麼是非常保守的預設行為；兩者的例子是使用者要求軟體刪除一個特定的名稱 (
rpz-drop.)，或者超出了某些數字門檻值 (BIND’smax-clients-per-query)。根據我的經驗，軟體以違反標準的方式完全改變所有數據包的預設行為幾乎是聞所未聞的，除非該選項可以增加對違反標準的舊產品的容忍度。這裡情況不同。簡而言之，這個 RFC 可以而且確實會在運營商的判斷下被違反，但通常這是以某種精確的方式完成的。為方便起見而完全忽略標準的某些部分是極為罕見的，尤其是當專業共識（例如： BCP 16 §3.3）傾向於不希望在整個 DNS 系統上產生不必要的負載時。考慮到這一點，不必要的重試丟棄所有不存在權威數據的請求是不可取的。
更新：
關於理所當然地放棄查詢是不可取的，@Alnitak 與我們分享，目前有一個BCP 草案詳細涵蓋了這個主題。將其用作引用有點為時過早，但它確實有助於加強社區共識與此處表達的內容一致。尤其：
除非名稱伺服器受到攻擊，否則它應該響應由於以下委託而指向它的所有查詢。此外，程式碼不應假定沒有對伺服器的委託，即使它未配置為為區域提供服務。委派中斷在 DNS 中很常見，並且接收到對未配置伺服器的區域的查詢並不一定表明伺服器受到攻擊。父區域操作員應該定期檢查委託的 NS 記錄是否與委託區域的記錄一致，並在不一致時進行更正
$$ RFC1034 $$. 如果定期這樣做，破壞委派的情況會少得多。
此答案將在本文件狀態更改時更新。