国产欧洲视频欧洲在线观看 ,国产亚洲福利久久久久,a视频在线免费观看

參考報告：亞太地區網絡信息中心對2020年DNS“執行日”影響的測量

點擊：2883 作者：邱實牟承晉來源：昆侖策網【原創】發布時間:2021-10-22 08:21:22

當今時代，數字技術、數字經濟是世界科技革命和產業變革的先機，是新一輪國際競爭重點領域，我們要抓住先機、搶占未來發展制高點。要提高數字技術基礎研發能力，打好關鍵核心技術攻堅戰，盡快實現高水平自立自強，把發展數字經濟自主權牢牢掌握在自己手中。

為此，我們必須及時、深入、廣泛地了解和掌握全球網絡信息領域關鍵重大技術變革演進的事實真相，不斷充實、豐富、提高和激發我們自身的創新與自立自強能力。

2019年2月1日，由行業內主流的DNS服務商和DNS技術提供商發起互聯網（Internet，下同）史上的第一次DNS“執行日”（Flag Day），被稱為是“無縫過渡到下一個30年的DNS時代”。2020年10月1日，實施了第二次DNS“執行日”，強制執行TCP承載DNS的要求和規定。

對此，亞太地區網絡信息中心（APNIC）進行了網絡狀態測量，并于2020年12月14日發表題為《對2020年DNS‘執行日’影響的測量》報告（以下簡稱“報告”）；其中基于測量數據，分析了存在問題，指出了所實施的IETF標準“DNS擴展機制EDNS（0）”的技術缺陷及根源，提出了相關的改進建議。

報告的第一作者，杰夫•休斯頓（Geoff Huston），是亞太地區網絡信息中心的首席科學家，也是從事研究互聯網基礎設施、IP技術和地址分配政策等方面的專家。

報告的第二作者，保羅•威爾遜（Paul Wilson），擁有在互聯網行業30多年的經驗，其中自1998年始，擔任亞太地區互聯網地址注冊機構的負責人。

報告給出的信息量較大，不僅有助于對DNS應用、技術和工程現狀與趨勢的了解、重新認識以及建議采納，而且在對互聯網發展的思維和方法上給出了有意義的參考和啟示。

報告中的相關技術術語，參考定義如下：

●UDP-Lite（Lightweight User Datagram Protocol，精簡版用戶數據報協議），是一種無連接通信的傳輸層協議（RFC 3828，2004-7），允許將有可能被損壞數據載荷發送給接收方，而不會被接收方直接丟棄；允許一些應用層協議（例如：一些視頻編碼傳輸的協議）在知曉部分應用數據受到損壞和影響的情況下，作出控制數據完整性的決定。

●ICMP（Internet Control Message Protocol），互聯網控制報文協議。

●MTU（Maximum Transmission Unit），最大傳輸單元。

●NTP（Network Time Protocol），網絡時間協議，基于UDP，用于網絡時間的同步。

● MSS（Maximum Segment Size），TCP 最大報文段大小。

報告尤其適合網信業界專業從業人員參考、分析和探討。報告來源：

https://blog.apnic.net/2020/12/14/measuring-the-impact-of-dns-flag-day-2020/

以下是參考譯文。

對2020年DNS“執行日”影響的測量

（APNIC，杰夫•休斯頓，保羅•威爾遜）

在廣域通信協議的發展中，互聯網的體系結構曾邁出了非常激進的一步。網絡的大部分功能沒有被置于基礎架構中，也沒有利用網絡功能來模擬可靠的邊緣到邊緣的電路系統（circuitry），而是使用了互聯網協議（IP）作為網絡服務的最小模式；除了不可靠的數據包傳遞之外，什么也沒有；其他的一切都留給被連網的主機。

互聯網的真正主力一直是TCP協議。該協議接受底層不可靠的數據報（datagram）服務，并構建基于連接的、可靠的應用傳輸電路。幾乎所有廣泛使用互聯網所承載的應用都是使用TCP或TCP模式的變體。

IP協議族（suite）還包括IP數據報模式的分離，在IP數據報中添加了應用級的端口地址。這種基于數據報的傳輸服務，即是“用戶數據報協議”（UDP）。UDP協議并沒有被廣泛使用，尤其是關注到濫用地址欺騙的廣泛性和普遍性。如今，在公共網絡中僅有仍在使用UDP傳輸的主流應用，似乎是網絡時間協議（NTP）和域名系統（DNS）。

DNS似乎與UDP是一個理想匹配。在DNS的交互模式中，域名查詢和解析響應都是小的數據包，很適合簡單的數據包交換的網絡模型。一旦發生DNS數據包丟失，無論是域名查詢還是解析響應，都可以通過超時、重新查詢和擴大請求域名服務器的范圍予以恢復。如果數據包丟失的發生率很低，那么在正常情況下，對DNS數據包丟失的檢測和恢復的開銷，會被UDP傳輸的固有效率所抵消。這意味著，UDP承載DNS的制約因素之一，是丟包可能性的最小化。

為了降低UDP承載DNS的數據包丟失的可能性，DNS的應用可以采取一些措施，包括：

Ø 首先，域名查詢方產生UDP數據包的長度（字節數），不應該大于接收方的UDP接收能力。在IPv4中，所有主機將收到的UDP數據包確保不超過576個字節。這就是說，只要被發送的信息量少于576個字節，信息發送方就無須擔心對UDP數據包的大小限制。在DNS的應用中，UDP數據包被限制為最多512個字節。超過512個字節的信息將被截斷，而且被作為一個信號，即該DNS的域名應該使用TCP進行重新查詢。

Ø 其次，為了使基于UDP的協議有效運行，確實應該避免在IP層的數據分片。在IPv4中沒有數據包碎片，是因為通過網絡傳輸的最大數據包是68個字節。DNS沒有嘗試將其交互的數據處理限制在40個字節的載荷內（假設DNS的IP數據包沒有可選項字段）。相反，DNS假設，IP層的數據包分片能力足夠健壯，使UDP得以高效地承載應用，而且最大576個字節的IP數據包被分片是一個非常特殊的情況。

IP的這組能力和約束，歸納如下（表-1）：

【表-1 IP數據包的長度（字節）】

對DNS應用的設計假設是，IP數據包分片（碎片化）被認為是一種不可避免的情況。然而，所有的連網和運營IP協議的主機都需要與DNS通信，這就是說，在IPv4網絡中不能假設所有的主機同時收到大于576個字節的UDP數據包。因此，在使用UDP傳輸時，DNS的有效載荷被限制為512個字節。

自此，IP和DNS都已經被改變了。關于在數據傳輸選項方面的考慮，DNS的主要變化是對域名查詢的解析響應添加了數字簽名。DNS安全擴展（簡稱DNSSEC）的數字簽名，增加了DNS解析響應數據包的字節數。總體上，將大多數的DNS解析響應數據包保持在512個字節的UDP限制之內，越來越具有挑戰性。同時，在將以太網模式作為數據包傳輸的共同標準方面，世界表現出團結一致，并且有一個事實上的規范，即非碎片化的IP數據包上限為1,500個字節。

為保持DNS規范不變，超過512字節的數據包可以被截斷，并切換到TCP以獲取大于512個字節的域名解析響應。如果這種情況發生率很低，是可以接受的方式；但是，如果DNS域名解析響應大于512個字節占很大比例，DNS可能會變得低效。客戶端需要使用UDP進行查詢，接收數據包截斷的解析響應，然后打開TCP會話（session）以重新查詢。姑且忽略復用與TCP 會話的相關嘗試，僅從UDP切換為TCP的兩步過程，將為這樣的域名查詢增加兩次額外的往返（round trip）時延，并將在TCP過程中所產生的開銷強加給域名解析服務器。

對需要提供更多信息的DNS域名解析響應，同時仍然保留UDP作為默認的DNS傳輸協議的方式，是在DNS域名查詢中使用接收方的緩存擴展指標，即EDNS（0）擴展機制（RFC 6891，2013-4）。

請不要忘記，DNS的UDP傳輸最初被限制在512個字節數據包的原因，不是為了避免UDP分片，而是為了保證接收方能夠完全收到DNS響應。在IPv4網絡中，最小的未被分片的IP數據包只有68個字節。對576個字節或更小的IP數據包進行分片是非常正常的。EDNS（0）擴展機制的目的是允許客戶端向服務器發出信號，表明其可以處理通過UDP傳遞的、大于默認512個字節最大有效載荷的DNS域名解析響應，而不是考慮該域名解析響應是否可能被碎片化。

因此，如果EDNS（0）有效載荷參數的主要目的不是為了避免UDP碎片，而是為了避免在沒有確實必要的情況下過早啟動TCP所帶來的額外開銷，那么有效載荷參數就可以設置一個更大的默認值。如果客戶端主機對數據包的字節數有限制，那么就可以在域名查詢中不使用EDNS（0）擴展，或者使用較小的緩存指標。RFC 6891中的EDNS（0）規范中提出，緩存的初始默認值為4,096個字節，其背后似乎就是基于這種思路。

簡而言之，EDNS（0）所隱含的設計似乎是一種權衡：雖然IP碎片化的損失可能很糟糕，但是其嚴重性被認為低于過早從UDP切換到TCP的時延影響。

但是，對于網絡穩固性的細小但重要之處仍需要得到持續關注。數據包分片對網絡性能和安全都有影響，目前遵循的一般性原則是，互聯網的應用和平臺應該切實努力避免依賴于IP分片。在最好的狀況下，應該完全避免觸發IP數據包分片！

按照這種思路，重新調整EDNS（0）參數的作用。除了表示DNS接收方可以接受傳入UDP數據包的最大數據包字節數之外，還添加了進一步的限定條件，即DNS數據包的字節數應小于或等于可以通過網絡傳遞的最大UDP有效負載，而不會觸發IP數據包分片（碎片化）。2020年的DNS“執行日”（Flag Day）的措施正是基于這種想法。

2020 年的DNS“執行日”（Flag Day）：

DNS 是一個高度異構的環境，有許多變動著的組件和許多供應商。事實證明，協調DNS中的變更非常具有挑戰性，“Flag Days”是為協調集體行動的一種方式。

“Flag Days”允許DNS軟件供應商更改他們的代碼庫，但是前提是更改的所有代碼都必須是通用的。這種方法于2019年進行首次嘗試，當時的目的主要是解決DNS解析服務器軟件對實施EDNS的非規范性方式和刪除一些“變通”的行為。

2020年10月1日，實施了第二次“執行日”，主要目的是修改DNS協議的行為，以避免依賴于碎片化的UDP數據包。

第二次“執行日”的主要目的是，DNS客戶端應使用默認載荷（和緩存）為1,232字節的EDNS；并且如果DNS消息大于1,232字節，DNS服務器就不應通過UDP發送DNS域名解析響應。

由此，引發了一些問題，包括：

◣ 為什么選擇1,232個字節？如果是為了避免IP數據包被分片，為什么不選擇更大的指標參數，例如1,452個字節？

◣ DNS中的數據包由于被碎片化丟失的程度有多嚴重？

◣ TCP承載DNS的性能有多“差”？比碎片化的UDP是好還是更差？

DNS 測量（Measurement）：

APNIC實驗室對DNS進行了測量。但是應該指出，我們使用的測量系統和方法存在局限性以及某些問題。

第一個限制，首先面對DNS實際上是一個松散耦合的網元組集合，要全面和完整地觀察DNS交互的集合幾乎是不可能的。在網絡邊緣的末端域名解析器系統，與一個或多個遞歸域名解析服務器之間存在著相互作用的關聯關系，而這些遞歸域名解析服務器又都分別代表這些末端域名解析器執行域名解析任務。

然后面對受權域名服務器系統，包含一組區塊的DNS信息，每個區塊都可以通過若干個這樣的受權服務器來發布。末端域名解析器和遞歸域名解析服務器可以是單獨的系統，或者目前通常使用一組分布式的引擎來實現，這些引擎可以通過服務器“場”（farm）的集群作為域名查詢的分布式前端，或者運用“任播”（anycast）將服務地址分布在互聯網上。

任何測量都必須關注系統的一些受限子集。在我們的DNS測量中，觀察遞歸域名解析服務器與受權域名服務器之間的解析性能受到限制。而且，我們的測量技術也不能直接觀察末端域名解析器與遞歸域名解析服務器之間的相互交互通信。

第二個限制，是我們的DNS測量技術依賴于域名服務器對域名的解析。一些遞歸域名服務器在解析域名時改變了對域名查詢的設置，并使用較小的緩存，甚至根本沒有緩存。

第三個限制，是關于DNS測量的問題，即測量的單位，這個問題在類似的工作中很常見。

“DNS解析器是什么？”這是一個令人意外且難以回答的問題；還有一個因素是，有一些域名解析器比其他域名解析器更為關鍵。總體而言，一個服務于上億個末端客戶的遞歸域名解析器，比個人使用的一個末端域名解析器要顯得更為重要。

在我們的測量工作中，對終端用戶的計數被作為計量單位。這種方法在本質上是通過計量遞歸解析服務器的被測用戶所表現出某種屬性的百分比來測量DNS。如果一個測量顯示有1.8%的被測用戶無法通過TCP完成域名解析，那么這并不能說明有多少域名解析服務器具有這種狀況。基于對用戶的測量是對特定行為影響的測量。

“執行日”后的“正常”（Normal）狀況如何？

為了建立控制測量基線（baseline），我們采集了一臺受權域名服務器生成的DNS域名解析響應，從中隨機選擇了11種大小不同的數據包。結果如表-2 所示。

1.webp (2).jpg

【表-2 控制測量的基線】

每次單獨的測試都要求遞歸域名解析服務器成功解析一個DNS域名響應（175個字節數據包）的控制實例。然后，所呈現的域名響應數據包所含字節是表-2 中所列出的情況之一。

令人驚訝的是，在嘗試解析DNS域名響應數據包為1,230個字節時，并不如預期成功。大約0.5%的測試例（即200分之一），未成功完成域名的解析過程。

對于域名響應數據包從1,230個字節到1,430個字節，域名解析失敗率基本一致。域名響應數據包為1,470個字節，對應的IPv4 UDP數據包為1,498個字節（略低于1,500個字節），對應的IPv6 UDP數據包為1,518個數據包。這就需要將UDP數據包分片，域名解析的失敗率為0.9%，這個結果與IPv4域名響應數據包具有較低的域名解析失敗率和IPv6域名響應數據包具有較高的域名解析失敗率是一致的。

對于超過1,500個字節的DNS域名響應數據包，域名解析的失敗率躍升至2.6%，或大約是40分之一。

TCP（傳輸控制協議）：

為了進一步地了解TCP承載DNS的狀況，有必要通過利用有效載荷參數，了解客戶端域名解析器與受權域名服務器之間的互動通信。

在EDNS（0）規范UDP承載DNS的數據包載荷之前，默認DNS 域名響應的最大UDP數據包為512個字節。這也是可以傳遞回客戶端域名解析器的DNS響應的最大數據包。

如果DNS消息大于512個字節，那么服務器就可以在512個字節的上限內盡可能多地輸入域名解析響應，并在域名解析的響應中設置截斷位。客戶端可以只使用所收到512個字節的域名響應，也可以截斷位作為信號，與服務器建立TCP連接并通過TCP提出域名查詢再請求。在TCP的數據傳輸中沒有信息量的限制，并且假定TCP將成功地傳輸完整的域名解析響應。

EDNS（0）允許客戶端指定DNS的UDP數據包大于512個字節。如果服務器的域名響應信息超過客戶端查詢所指定的字節數，則截斷域名解析響應，并在UDP的數據包中設置截斷標識位。

此外，域名服務器可能有已設置DNS的最大UDP緩存，在這種情況下，客戶端在域名查詢中指定的字節數與服務器所設置的緩存，其中的較小者被用于確定UDP域名解析響應的數據包截斷點。

雖然TCP查詢可以是由客戶端發起，而不是由于觸發UDP的數據包截斷響應，但這種情況很少發生。我們觀察到大多數TCP域名查詢的發起，僅是在UDP截斷響應傳遞回客戶端解析器之后。

在我們測量場景中的TCP狀況，如表-3 所示。

一旦域名響應信息超過1,470個字節，測試例中約有三分之一的實例，即域名響應信息大于DNS服務器設置的UDP緩存，并且截斷的域名解析響應被傳遞回客戶端解析器，以觸發TCP重新查詢（在表-3中的“TCP應用率”）。

DNS的TCP失敗率約為1%。如果域名解析響應大于1,500個字節，則失敗率會進一步增加約0.9%（在表-3中的“失敗率”）。DNS的TCP失敗率被分為三種類型：

1）TCP會話未被建立（在表-3中的“NO TCP”）；

2）TCP會話被建立，域名查詢請求也發出了。但是當域名響應被傳回給客戶端解析器時，TCP會話就會中斷，而沒有對域名響應的ACK。對于較小的DNS域名響應數據包，在失敗案例中這種情況發生約占四分之一；對于較大的DNS域名響應（多個TCP 段），在失敗案例中這種情況上升到略低于二分之一，其最可能的原因是在TCP 路徑上MTU（最大傳輸單元）不匹配，較大的TCP段（segment）無法傳遞到客戶端（在表-3中的“NO ACK”）。

3）TCP會話似乎是正常完成了，但由于某些原因，完整的域名解析過程仍然是失敗的（在表-3中的“TCP OK”）。

【表-3 測試中DNS的TCP應用】

在實驗中，我們使用了1,500個字節的MTU設置，可能會在TCP傳輸路徑上遇到一些問題。

UDP（用戶數據報協議）：

實驗中發現，僅在略多于一半的測試例中，DNS的UDP緩存被設置為4,096個字節。這低于“正常”狀況，因為許多解析器在解析域名服務器的名稱時會改變其行為。而“正常”狀況的指標值是：DNS的UDP緩存被設置為4,096個字節的域名解析器，占比約為82%。這表明，在本實驗中TCP承載DNS的使用率大約是一般預期的兩倍。

在我們測量場景中的UDP域名解析失敗率，如表-4 所示。

【表-4 測試中DNS的UDP應用】

沒有被分片的UDP數據包（字節數小于1,500字節）的域名解析失敗率不到TCP數據包（表-3）失敗率的一半（小于二分之一），即通過UDP傳輸DNS數據包的域名解析失敗率為0.4%。

當UDP域名響應數據包（字節數大于1,500字節）被分片時，域名解析失敗率上升到3.0%，這比通過TCP傳輸DNS數據包的域名解析失敗率更糟糕。盡管有許多解析器會宣稱已為DNS的UDP設置了較大的緩存，但是仍無法接收較大數據包的UDP域名解析響應（被分片）。這很可能是由于路由路徑上的IP數據包過濾器所造成的，其中丟棄數據包碎片是這類過濾器中的常見安全設置。

超過1,500個字節的DNS域名解析響應，其失敗率上升了五倍：

在實驗中觀察到一些個例，一旦DNS域名響應的數據包超過1,500個字節，域名解析的失敗率就會從0.5%上升到2.5%。在這些個例中，由于域名服務器使用碎片化的UDP傳遞域名解析響應占比約75%。換句話說，客戶端解析器為DNS設置了一個較大的緩存并告知了域名服務器，但是基于客戶端設置的較大緩存，域名服務器使用碎片化的UDP傳遞域名解析響應導致域名解析失敗。

從客觀的角度，EDNS（0）的緩存參數設置意在控制域名服務器的行為，以嘗試避免通過UDP傳輸的DNS數據包被碎片化，是基于非常粗糙的猜測（very crude guesses）。因為客戶端無法預知域名服務器的域名解析響應數據包將通過什么網絡路徑路由，并且各種域名服務器到客戶端的數據路由路徑MTU的發現技術，是基于服務器端的探測，而不是客戶端探測。被傳遞的數據包大小是由服務器決定，只有服務器通過ICMP消息獲知某路由路徑上存在MTU不匹配。客戶端永遠無法了解互聯網路由路徑中的MTU特性。因此，客戶端基于EDNS（0）所設置的數據包載荷充其量只是路由路徑中MTU設置的簡單“一廂情愿”（a crude substitute）。

如果EDNS（0）的目的，是在試圖恢復被丟失的UDP數據包時減少無效和延遲，那么DNS解析器的緩存設置小一些（如“執行日”要求設置為1,232個字節）比設置為4,096個字節更有意義。

但是，設置相對較小的緩存具有自身的問題，因為由此會不必要地過早調用TCP，特別是在遞歸域名服務器與授權域名服務器的交互通信中。另一方面，TCP也存在其自身的問題是，即比未分片的UDP數據包的傳輸速度慢得多，當然數據傳輸也不可靠。現實是，并非所有的客戶端解析器都能啟用TCP承載DNS，這可能是由于局部或局域過度地熱衷于數據包過濾規則。

綜上，我們試圖定位DNS，而統籌考慮的三個因素是：

1）沒有被碎片化的UDP傳輸數據是快速、高效和非常可靠的。

2）TCP的數據傳輸速度較慢，效率較低，而且并不可靠；但是通過謹慎管理TCP的MSS（最大報文段大小）設置，以避免TCP黑洞（black holes），可以提升可靠性。

3）分片的UDP數據傳輸是性能最差的，不僅DNS解析的失敗率很高，而且必須依靠本地計時器來檢測數據包是否被丟失（或超時）。

這就意味著，對于DNS的數據傳輸，應該繼續使用UDP；當DNS的信息大而數據包不得不被分片時，再切換到TCP傳輸。

那么，如何實現如此的DNS定位？如果指望運行基于UDP的精簡版（簡稱UDP-Lite），為每一次DNS數據交互而發現傳輸的路由路徑中MTU的操作，是不合理的。這就要求，客戶端和服務器都應該使用保守的數據傳輸參數設置，以避免路由路徑中出現MTU問題。

客戶端DNS 解析器應該做什么？

2020年DNS“執行日”中要求的緩存參數設置是一個好的開端。但我們認為，仍然存在較大的局限性（don't quite catch the entirety of the space）。

在遞歸域名服務器與受權域名服務器的交互場景中，遞歸域名服務器應使用EDNS（0）設置的UDP載荷參數：對于IPv6，等于或僅略小于1,452個字節（考慮到40個字節的IPv6包頭和8個字節的UDP包頭）；對于IPv4，等于或僅略小于1,472個字節（考慮到20個字節的IPv4包頭和8個字節的UDP包頭）。

當啟用TCP時，遞歸域名服務器客戶端應設置載荷參數：對于IPv6，小于1,440個字節的MSS設置（考慮到40個字節IPv6包頭和20個字節TCP包頭）；對于IPv4，小于1,460個字節（考慮到20 個字節IPv4包頭和20字節TCP包頭）。

DNS 服務器應該做什么？

域名服務器應避免所傳遞的數據包被分片，可以通過將最大有效載荷參數設置為：對于UDP的數據傳輸，IPv6不大于1,452個字節，IPv4不大于1,472個字節。此外，還應該對TCP傳輸的數據包（IPv6的1,440個字節和IPv4的1,460個字節），施加一個約束上限。

域名解析器默認緩存1,232個字節顯得太少

鑒于具體情況各不相同，在互聯網邊緣的測量與在網絡基礎設施內側的測量存在差異。測量遞歸域名服務器與授權域名服務器之間在互聯網基礎設施內的行為表明，在IP數據包不超過1,500個字節時，網絡的行為相對統一。

如果我們把自己限制在只是遞歸域名服務器與授權域名服務器之間的交互通信設置上，那么DNS“執行日”（2020年）所設置默認緩存1,232個字節顯得太少了。其結果是，遞歸域名服務器與受權域名服務器之間的交互通信，將過早地調用TCP。在觸發TCP之前，可以通過將UDP數據包字節數的限制上界提高到1,500個字節（包括IP包頭），以實現一個更有效的結果。

同時，設置降低TCP段（segment）的字節數是謹慎的。從DNS交互通信的觀點，使用1,200個字節的MSS參數，提高了性能但所付出的成本是非常小的，而且這樣的設置對于進一步避免TCP 的MTU黑洞問題，可以得到保證。

因此，對DNS客戶端和服務器的數據傳輸參數提出建議，如表-5所示。其目的是：在DNS數據包小于1,500 節，使用UDP傳輸；然后使用更具保守的MSS設置，以提高TCP會話的可靠性。