隨著 IPv6 持續部署，現今網際網路同時存在 IPv4-only、Dual-Stack，以及 IPv6-only 網路。在這樣的混合環境中，DNS 也必須面對不同網路之間的連通性差異。IETF 於 2026 年 8 月發布 RFC 10001「Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments」，列為 BCP 91，並取代 2004 年發布的 RFC 3901。
RFC 10001 的核心原則很明確：權威 DNS 伺服器與遞迴 DNS 解析器都應支援 IPv4 與 IPv6，讓 DNS 資料可以透過兩種 IP 位址家族取得，降低因 IPv4／IPv6 支援差異造成的 DNS 解析問題。
DNS 為什麼會受到 IPv4／IPv6 影響？
DNS 解析通常會從根伺服器開始，依照委派關係逐層找到負責該網域的權威 DNS 伺服器。
如果解析器只能使用 IPv6，但委派過程最後只找到 IPv4 可連線的權威 DNS 伺服器，解析器就無法繼續查詢；反過來，如果解析器只能使用 IPv4，而權威 DNS 伺服器只提供 IPv6，也會發生相同問題。
RFC 10001 將這種情況稱為 Name Space Partitioning（名稱空間分割）。也就是說，同一個網域名稱可能因為使用者所在網路支援的 IP 位址家族不同，而出現「有人可以解析、有人無法解析」的情況。
因此，RFC 10001 認為，讓 DNS 資料同時能透過 IPv4 與 IPv6 取得，是維持 DNS 名稱空間連續性最穩健且具彈性的方式。
權威 DNS 伺服器應同時支援 IPv4 與 IPv6
RFC 10001 對權威 DNS 的要求相當明確。
每一個 DNS Zone：
- 至少要有兩台可透過 IPv4 連線的權威 DNS 伺服器
- 至少要有兩台可透過 IPv6 連線的權威 DNS 伺服器
- IPv4 與 IPv6 所提供的 DNS 資料應保持一致
同一台同時支援 IPv4 與 IPv6 的 DNS 伺服器，可以分別計入 IPv4 與 IPv6 的伺服器數量。
此外，DNS 的 NS 記錄所使用的名稱，建議同時具有 A 與 AAAA 記錄。若只有其中一種記錄，某些只支援另一種 IP 位址家族的解析器，在選擇 DNS 伺服器時就可能需要額外查詢，增加解析過程的負擔。
對於 DNS 委派，也必須注意 Glue Record。如果 NS 名稱位於被委派的 Zone 內，父 Zone 必須提供相對應的 IPv4 與 IPv6 Glue；若父子 Zone 或相關網域的委派鏈缺少其中一種 IP 位址家族，就可能造成該 IP 位址家族無法完成 DNS 解析。
IPv4 與 IPv6 的 DNS 資料要一致
RFC 10001 特別強調，IPv4 與 IPv6 傳輸所提供的 DNS 資料應保持等效。
換句話說，不能只是「DNS 伺服器有 IPv4 和 IPv6 位址」，卻讓兩條路徑實際提供不同的 DNS 資料。
這是為了讓 IPv4-only、IPv6-only 與 Dual-Stack 網路中的使用者，都能得到一致的 DNS 解析結果。
DNS 解析器也應支援雙協定
除了權威 DNS 伺服器之外，RFC 10001 也針對 Recursive DNS Resolver 提出建議。
一般情況下，遞迴 DNS 解析器應採 Dual-Stack，也就是同時支援 IPv4 與 IPv6。
原因在於，目前仍有部分 DNS Zone 只能透過 IPv4 或 IPv6 的其中一種方式完成解析。因此，只有單一 IP 位址家族的遞迴解析器，可能無法解析所有網域。
不過 RFC 10001 也允許例外。例如 IPv6-only 的遞迴解析器，如果透過 NAT64 等轉換機制，可以查詢只有 IPv4 的權威 DNS 伺服器；或者無法完成解析時，將查詢轉送給具備 Dual-Stack 能力的遞迴解析器，就可以維持 DNS 解析能力。
IPv4-only 的遞迴解析器也有類似做法，可以將需要 IPv6 才能完成的查詢轉送給 Dual-Stack 遞迴解析器。
IPv6-only 網路中的 DNS 也需要特別注意
在 IPv6-mostly 或 IPv6-only 網路中，DNS 解析器可能需要透過 NAT64 連接 IPv4-only 的 DNS 伺服器。
RFC 10001 提到，如果解析器知道網路所使用的 PREF64，就可以利用 NAT64 等機制處理這類連線；PREF64 可以透過網路設定或 Router Advertisement 等方式取得。
不過，若使用錯誤的 PREF64，也可能造成問題，因此 RFC 10001 要求相關實作應遵循安全取得 PREF64 的相關指引。
DNS 傳輸也要避免 IP Fragmentation
RFC 10001 另一個重要重點，是 DNS 封包的 IP Fragmentation（IP 分片）。
DNS 回應可能因為 DNSSEC 等資料而變大。如果 UDP 封包超過網路路徑可以傳輸的有效 MTU，就可能需要分片；在某些網路環境中，這些分片封包可能直接被丟棄，而且傳送端未必能立即知道。
因此，RFC 10001 建議 DNS 伺服器依照 RFC 9715 的指引避免 DNS over UDP 發生 IP 分片。
目前許多 DNS 實作使用 1232 octets 作為 EDNS(0) 的上限。這可以讓產生的封包不超過 IPv6 最小 MTU 1280 octets，降低 IPv6 分片問題。
同時，DNS 不能只依賴 UDP。RFC 10001 要求 DNS over TCP 必須能作為 UDP 的替代方案，而不是依賴 UDP 分片來傳送大型 DNS 回應。
對 TCP DNS 連線，RFC 10001 建議 Sender MSS 不超過 1388 octets；也可以使用 1220 octets，以進一步避免封包超過 1280 octets。
DNS Stub Resolver 的處理方式
DNS Stub Resolver 通常運作在使用者端裝置，因此更可能處於 IPv6-mostly 或 IPv4-only 的網路環境。
Stub Resolver 可以從 DHCPv4、DHCPv6 或 Router Advertisement 取得 Recursive DNS Resolver 的位址。當同時取得 IPv4 與 IPv6 的 DNS 解析器位址時，應依照 RFC 6724 的規則進行選擇。
如果 Stub Resolver 能辨識某個 IPv6 位址其實是 IPv4-embedded IPv6 address，例如透過網路取得的 PREF64 判斷，就不應使用這類位址作為 DNS Resolver 位址。
RFC 10001 也注意到部分 Stub Resolver 能設定的 DNS 伺服器數量有限。因此，當網路提供超過三個 Recursive DNS Server 位址時，應注意 IPv4 與 IPv6 位址的配置方式，避免部分 DNS 伺服器被用戶端忽略。
從 IPv4-only 走向 IPv4／IPv6 共存
RFC 10001 是對 RFC 3901 的更新。
過去 RFC 3901 的重點主要是在 IPv6 尚未普遍部署的情況下，維持 IPv4 DNS 名稱空間的連續性。經過二十多年，IPv6 已經廣泛部署，因此 RFC 10001 擴大了原有指引，不再只關注 IPv4，而是同時要求考量 IPv4 與 IPv6。
新版 RFC 特別增加了三個方向：
第一，將 IPv4 與 IPv6 的權威 DNS 支援都納入建議。
第二，除了 IPv4，也應在 DNS Zone 委派時測試 IPv4 與 IPv6 的可解析性。
第三，增加對 IP Fragmentation、Recursive DNS Resolver，以及 Stub Resolver 的運作指引。
結語
RFC 10001 的核心概念，可以簡化為：
DNS 不應只考慮「DNS 資料是否存在」，還必須確保 DNS 可以從 IPv4 與 IPv6 網路正常取得。
因此，權威 DNS 伺服器應同時提供 IPv4 與 IPv6；Recursive DNS Resolver 應具備 Dual-Stack 能力；DNS 委派鏈應避免因 A、AAAA、Glue 或網路連通性問題造成名稱空間分割；同時也應避免 DNS 封包因 IP Fragmentation 而遭到丟棄。
在 IPv4-only、IPv6-mostly、IPv6-only 與 Dual-Stack 網路並存的環境下，這些做法能讓 DNS 名稱空間維持連續，讓不同 IP 位址家族的網路都能取得一致的 DNS 解析結果。
RFC 10001 因此將 DNS 傳輸的運作原則，從過去以 IPv4 為主的環境，進一步更新為適用於 IPv4 與 IPv6 並存的現代網際網路環境。
原始資料來源： https://datatracker.ietf.org/doc/html/rfc10001
RFC 10001, Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments, BCP 91, IETF, August 2026。