本APNIC文摘原標題為IPv6, the DNS and Happy Eyeballs，由Geoff Huston撰文。
APNIC首席科學家Geoff Huston最近參與網際網路工程任務組（Internet Engineering Task Force，IETF）118屆會議時，注意到一項關於RFC 3901的提案。RFC 3901建議為確保域名空間延續，（1）所有遞迴域名伺服器應該（should）僅適用IPv4或適用雙協定（dual stack，意即適用IPv4及IPv6）、（2）所有DNS區（DNS zone）應該至少有一個可連至IPv4的權威域名伺服器。
Huston說的提案建議的（1）1個區中至少應有2個域名伺服器是雙協定，（2）所有權威DNS區應該有一個可連至IPv6的權威域名伺服器。他認為此建議更新RFC 3901的提案，遠不及原RFC簡潔扼要。
Huston也認為此提案措辭過於強烈，也疑惑提案中的建議是否符合時宜。他想知道自2004年RFC 3901公告後，除了IPv6信奉者的熱情益發高漲外，有什麼其他變化足以成全此提案，尤其這是否可提升遞迴及權威伺服器的IPv6支援比例。
「SHOULD」和「RECOMMEND」
Huston首先從本提案的用字談起。IETF最常被引用的文件之一是RFC 2119，其中定義所有RFC中常見用字，包括「MUST、MUST NOT、SHOULD、SHOULD NOT和MAY」。根據RFC 2119，這些字不能任意彼此互換。「MUST」只能在真的為了互通運作或避免導致危害時使用，「SHOULD」或形容詞「RECOMMENDED」，則代表行為人必須徹底了解潛在後果並謹慎評估後，得以在特殊情境下，選擇不依建議行事
Huston認為，這代表若建議行為可能導致危害時，提案作者就不應該使用「應該」（SHOULD）或「建議」（RECOMMENDED）等字眼。而在DNS中，將IPv6作為使用者資料包通訊協定（User Datagram Protocol，UDP）基體執行DNS回應，因而導致不必要的再傳輸（retransmission）、提高解析失敗機率，就是一種危害。
IPv6、UDP與大尺寸DNS回應
之所以會導致上述危害，是因為透過IPv6不容許「事先切割」（forward fragmentation），導致傳輸大尺寸DNS回應時，常造成效率不佳及不可靠等問題。
簡單來說，如果IPv6封包太大，協定本身並不容許其分割後傳送。尤其由於UDP不像傳輸控制協定（Transmission Control Protocol，TCP）會自動觸發再傳輸以找回封包，傳送失敗的封包很可能就此丟失。
除此之外，IPv6利用放在IP表頭及UDP表頭之間的「延伸表頭」，這表示UDP表頭會被推到封包更深處。理論上路由不需檢視UDP表頭，但實作上並非如此。當代網路常用負載分散技術將訊務分散至多條不同傳輸路徑，而為了確保同一封包流的封包依順序經同一路徑傳遞，這些技術需要確認UDP或TCP表頭。很多網路因為無法馬上找到IPv6封包的UDP表頭，有的選擇擱置，更甚者可能直接捨棄具延伸表頭的封包。
基於以上2點，DNS大負載、UDP和IPv6的組合，效率遠不及IPv4。
大尺寸回應及IPv6
很明顯，如果我們希望總有一天達到僅使用IPv6的DNS，現在的DNS必須改變，確保未來大型DNS回應可以順利簡單經IPv6傳送。
到底是什麼造成大型DNS回應？答案是域名系統安全擴充（Domain Name System Security Extensions，DNSSEC）。
為了改進DNSSEC導致回應尺寸過大的缺點，DNSSEC圈內呼籲更換演算法的呼聲日漸升高。雖然現在考慮的演算法還沒考慮到後量子電腦時代。
總結而言，我們面臨兩個選項：捨棄DNSSEC以確保在IPv6之上順暢使用UDP；或保留DNSSEC，這代表IPv4運作上仍然較佳，而IPv6只是額外選項，就像RFC 3901說的一樣。
下篇Geoff Huston檢視當前DNS行為，以資料說明為何RFC 3901仍是目前最佳解方。
| 本文內容純屬筆者個人意見，並不代表TWNIC立場 |
*台灣網路資訊中心（TWNIC）與亞太網路資訊中心（APNIC）合作，定期精選APNIC Blog文章翻譯摘要，提供中心部落格讀者了解目前亞太地區網路發展之最新趨勢。原文標題為IPv6, the DNS and Happy Eyeballs。
圖片來源： APNIC Blog
