如何防止與 IPv6 AAAA 記錄相關的延遲？

July 19, 2020

AAAA我們的 Windows 伺服器正在向我們的 Windows DNS 伺服器註冊 IPv6記錄。但是，我們的網路上沒有啟用 IPv6 路由，因此這經常會導致停頓行為。
Microsoft RDP 是最嚴重的違規者。當連接到在 DNS 中有AAAA記錄的伺服器時，遠端桌面客戶端將首先嘗試 IPv6，並且在連接超時之前不會回退到 IPv4。高級使用者可以通過直接連接到 IP 地址來解決此問題。ping -4 hostname.foo使用總是立即解析 IPv4 地址。
我能做些什麼來避免這種延遲？
在客戶端上禁用 IPv6？
不，微軟表示IPv6 是 Windows 作業系統的必需部分。
太多的客戶無法確保在任何地方都始終如一地設置。
當我們最終實現 IPv6 時，會引起更多的問題。
在伺服器上禁用 IPv6？
不，微軟表示IPv6 是 Windows 作業系統的必需部分。
需要一個不方便的系統資料庫黑客來禁用整個 IPv6 堆棧。
確保在所有伺服器上都正確設置是不方便的。
當我們最終實現 IPv6 時，會引起更多的問題。
屏蔽使用者 facnig DNS 遞歸器上的 IPv6 記錄？
不，我們使用的是 NLNet Unbound，它不支持。
阻止在 Microsoft DNS 伺服器上註冊 IPv6 AAAA 記錄？
我認為這甚至是不可能的。
此時，我正在考慮編寫一個腳本，從我們的 DNS 區域中清除所有 AAAA 記錄。請幫助我找到更好的方法。
更新： DNS 解析不是問題。正如@joeqwerty 在他的回答中指出的那樣，DNS 記錄會立即返回。A和記錄都AAAA立即可用。問題是某些客戶端 ( mstsc.exe) 會優先嘗試通過 IPv6 進行連接，並且需要一段時間才能回退到 IPv4。
這似乎是一個路由問題。由於目標地址不可路由，該ping命令會生成“一般故障”錯誤消息。
C:\Windows\system32&gt;ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
我無法擷取此行為的數據包。執行此（失敗的）ping 命令不會在 Microsoft 網路監視器中生成任何數據包。同樣，嘗試mstsc.exe與具有AAAA記錄的主機建立連接不會產生流量，直到它回退到 IPv4。
**更新：**我們的主機都使用可公開路由的 IPv4 地址。我認為這個問題可能歸結為損壞的 6to4 配置。6to4 在具有公共 IP 地址和 RFC1918 地址的主機上表現不同。
**更新：**我的網路上的 6to4 肯定有問題。當我在 Windows 客戶端上禁用 6to4 時，連接會立即解決。
netsh int ipv6 6to4 set state disabled
但正如@joeqwerty 所說，這只會掩蓋問題。我仍在試圖找出為什麼我們網路上的 IPv6 通信完全不起作用。

稱為 6to4 的 IPv6 過渡技術因引發此類問題而臭名昭著。有幾個因素在起作用。單獨它們是無害的，但綜合效果是最終使用者可能會遇到連接延遲。
下面列出了促成因素及其緩解措施的想法。
Windows 預設啟用 6to4
如果您的主機執行的是最新版本的 Windows（Vista 或更高版本），Windows 將在可公開路由的 IPv4 地址可用時適時啟用 6to4 隧道。至關重要的是，這適用於伺服器和客戶端。
要確定係統是否使用 6to4，請執行ipconfig並查找以 6to4 前綴開頭的 IPv6 地址2002:。它看起來像這樣。
C:\&gt; ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222
如果您的端點連接到 Active Directory，您可以使用組策略禁用 6to4 和 Teredo 等轉換協議。這在KB929852中有詳細記錄。（將其應用於您的客戶端或伺服器就足夠了，但如果您正在採取此步驟，那麼在客戶端和伺服器上到處禁用它可能是有意義的。）
如果您只管理幾台主機，您可以根據具體情況禁用 6to4。這比完全禁用 IPv6 要好得多。netsh int ipv6 6to4 set state disabled
使用不同的客戶端作業系統。例如，Mac OS X 預設沒有啟用 6to4。
正在使用可公開路由的 IPv4 地址
6to4 僅適用於具有可公開路由的 IPv4 地址的主機，因此此問題永遠不會影響 NAT 防火牆後面的主機。
您可以將客戶端和/或伺服器移到 NAT 防火牆後面並開始使用 RFC1918 定址。但在某些情況下，公共可路由地址實際上是首選。更改整個網路的地址也可能是一個不切實際的選擇。
6to4 在網路上無法正常執行
在任播模式下對 6to4 進行故障排除是出了名的困難。麻煩的是，IETF 正式要求將6to4 重新歸類為歷史性的。在作者看來，6to4 已被棄用。
簡而言之，6to4 的工作原理是使用稱為 6in4（IP 協議=41）的協議將 IPv6 數據包封裝成 IPv4 數據包。IPv4 數據包被定址到任播地址192.88.99.1，希望它能夠到達 Internet 上某個工作的 6to4 中繼。如果幸運的話，它甚至可能在地理位置上就在附近。
在實踐中，一些 6to4 中繼設置不正確，很多網路甚至不允許 6in4 流量穿過防火牆。通常，當防火牆允許所有出站流量，但未明確允許 IP 協議 41 數據包通過防火牆返回時，就會發生這種情況。（TODO 請注意相關的 RFC 以進行故障排除。）此故障（“入站黑洞”）和許多其他故障在RFC 6343中進行了描述。
設置防火牆以在從內部主機發送到網路時大聲拒絕 IP 協議 41（帶有 TCP 重置）。這應該會導致比非確定性連接延遲更有意義的“快速失敗”行為。這已被證明可以在有限的測試環境中工作。
要求您的 ISP 或第一跳傳輸提供商設置一個有效的 6to4 中繼。如果做得對，將為最終使用者帶來最佳體驗。任何擁有可公開路由的 IPv4 地址的最終使用者都可以參與 IPv6 網際網路。
動態 DNS 註冊
在典型的 Active Directory 環境中，每台電腦都可以向 DNS 伺服器註冊自己的地址。當主機是多宿主時，它將註冊其所有地址，甚至來自 6to4 隧道。
大多數網際網路服務不使用動態 DNS，因此此問題通常僅限於客戶端和伺服器都在同一網路“內部”的企業站點。
您可以選擇禁用動態 DNS 更新。然後，如果您不將任何 AAAA 資源記錄放入區域文件中，它們將永遠不會被提供。但是，內部 DNS 伺服器通常需要動態 DNS。（如果您這樣做，請確保同時刪除任何可能已經存在的 AAAA 記錄。）
將 DNS 伺服器設置為不為 AAAA 資源記錄提供答案。但是不要這樣做，因為當你想開始實施 IPv6 時，它真的會給你帶來麻煩。（有人知道免費/開源的 DNS 防火牆嗎？）
客戶端應用程序不會正常失敗
Microsoft 的 RDP 客戶端是不能優雅地處理 IPv6 路由問題的客戶端應用程序的一個範例。大多數網路瀏覽器都更擅長處理像這樣的 IPv6 邊緣情況，因此它們不傾向於顯示這種行為。
嘗試使用不同的客戶端。也許你會走運。

這個問題很有趣，我必須承認我從未見過這種行為。在進行一些嘗試以更好地理解它時，我從另一個 W2K8R2 伺服器獲取了一段 nslookup 查詢來查詢我的一個 W2K8R2 RDS 伺服器，並且我還從同一個測試伺服器擷取了一個到同一 RDS 伺服器的 RDP 會話的片段. Nslookup 顯示返回 IPv6 記錄沒有延遲，並且 nslookup 顯示我的測試伺服器在查詢 IPv6 記錄之前查詢 IPv4 記錄。擷取中的時間增量在任何一個查詢中都沒有顯示出明顯的延遲（我可以確定）。
編輯
現在你正在做某事。
確保您正在擷取 Microsoft 6To4 適配器的流量，否則您將看不到 IPv6：
這是我的 RDS 伺服器的 nslookup 結果。記下 IPv6 地址：
現在這是我擷取的片段：
最後，這是 netstat 中顯示連接的片段：
很明顯，正如您所確認的，DNS 解析不是問題。問題是 RDP 連接更喜歡 IPv6 而不是 IPv4（這是 Windows 的預設設置 - Windows 更喜歡 IPv6 而不是 IPv4），並且由於 IPv6 無法正常執行，它會導致延遲（如您所述）從 IPv6 回退到IPv4。您可以通過將客戶端配置為首選 IPv4 而不是 IPv6 來解決此問題，但我認為這只會掩蓋問題。更好的解決方案是找出 IPv6 不起作用的原因並修復它。我對 IPv6 了解不多，無法提供幫助，但我的猜測是 DNS 返回的 IPv6 記錄是“本地”地址，僅在 RDS 主機所在的子網上有效，並且由於客戶端位於不同的子網中，因此它們可以t 到達那些 IPv6 地址。