我很好奇L根伺服器的實際效果如何今天出版 DURZ將。在nanog郵件清單中，有人說即使不使用 DNSSEC，評估根名稱伺服器發布簽章區域的系統影響也很重要。同時，RIPE 自己發布的有關 K 根伺服器變更的資訊稱：如果您的解析器不使用 DNSSEC 則沒有問題。有人可以澄清一下嗎？ DNSSEC 似乎是一個混亂、錯綜複雜的網路。
如果未在我的解析器上啟用 DNSSEC，我是否需要擔心根伺服器即將發生的變更？
答案1
你可能看到一些東西，但在某種程度上這取決於您運行的 DNS 軟體。
DO特別是，即使沒有專門請求 DNSSEC 記錄或執行 DNSSEC 驗證，BIND 也會在上游查詢上設定「DNSSEC OK」（又稱）位元。
在這些情況下，根伺服器可能會發回額外的 DNSSEC 記錄，這些記錄可能萬一您的網路設備損壞和/或路徑中的防火牆配置錯誤（這種情況不太可能發生），則會導致問題。
這些問題主要與資料包大小有關。某些套件不喜歡長度超過 512 位元組的 DNS UDP 封包，這可能是由於有缺陷的韌體或供應商建議的錯誤配置造成的。看我的RFC 5625更多細節。請注意，我在 RFC 中報告的大多數與 DNSSEC 相關的問題都與消費者級設備相關，並且僅在不尋常的配置中。
請注意，如果您的套件在處理大型 UDP 封包時確實存在問題，則備用方法是使用 TCP。然而，一些（被誤導的）安全人員將其防火牆配置為停用 TCP 上的出站 DNS，這打破了後備。看這有關 TCP 上的 DNS 的更多資訊的 IETF 草案。
順便說一句，為了測試您的網路配置是否有可能的 DNS 怪癖，我強烈推薦出色的 內塔利茲爾來自加州大學柏克萊分校 ICSI 的網站。
然而需要明確的是，大多數 DNS 專家都不是由於 DNSSEC 的引入，預計會出現重大問題。多個頂級域名（包括 .org 和 .se）已經簽署，互聯網並沒有因此而崩潰。
DURZ 是一種有意的嘗試，旨在逐步逐步納入 DNSSEC 不可避免地產生的較大回應，以便那些有網路問題的罕見網站可以在夏季整個根區域移交給 DNSSEC 之前解決這些問題。
答案2
對於那些喜歡命令式程式語言的人來說，用偽代碼解釋可能會出現什麼問題:-)
-- 偽代碼（或多或少類似於 Ada 的語法）來顯示發生了什麼
-- 當根被簽署且回應變成時的 DNS 解析器
——更大。
——背景資料：
-- https://www.dns-oarc.net/oarc/services/replysizetest
——RFC 5625
-- SSAC 報告 #35 http://www.icann.org/committees/security/sac035.pdf
——史蒂芬‧波茲邁爾
-- 使用的變數：
-- EDNS0：布林值，表示解析器是否發送EDNS0請求
-- EDNS0_Size：正整數，EDNS0通告的緩衝區大小
-- DO_DNSSEC：布林值，指示解析器支援 DNSSEC 的 DO 標誌
-- Min_Response_Size：整數，最小值（丟棄後
-- 權威機構發送的 DNS 回應的不必要的 RR) 大小
-- 伺服器
-- clean_path_for_fragments: boolean, 表示UDP片段
-- 可以從權威名稱伺服器傳送到解析器
-- Clean_Path_For_EDNS0: boolean, 表示EDNS0回應
--（可能大於 512 位元組）可以從
-- 解析器的權威名稱伺服器
-- Can_TCP: boolean, 表示解析器可以透過TCP請求
--（這意味著乾淨的 TCP 補丁和權威的名稱伺服器
-- 接受 TCP）
-- 對於一個請求，該程式碼可以執行多次，例如
-- 例如，因為解析器首先嘗試使用 UDP，然後重試
——使用 TCP。
if UDP then -- 最常見的 DNS 傳輸協議
如果 EDNS0 那麼
如果 EDNS0_Size > MTU 那麼
-- BIND 默認，EDNS0_size = 4096 位元組
如果 DO_DNSSEC 那麼
-- BIND 預設值，即使未配置驗證
if Min_Response_Size > MTU then -- 今天根的情況並非如此
如果 Clean_Path_for_fragments 那麼
好的;
別的
-- 稍後BIND將切換到no-EDNS0，重新開始
Retry("未收到回應可能是因為 EDNS0");
萬一;
elsif Min_Response_Size > 512 那麼
-- 不會發生碎片
如果 Clean_Path_For_EDNS0 那麼
好的; -- 這是 BIND 的正常且典型的情況
-- 今天的解析器，有簽名的根
別的
Retry("未收到回應可能是因為 EDNS0");
萬一;
else -- 今天不會發生，來自根的回應已經 > 512
好的;
萬一;
別的
-- 如果沒有 DNSSEC，回應會更短，但有些
-- 來自根的回應已經 > 512
如果 Min_Response_Size > MTU 那麼
-- 不太可能，沒有 DNSSEC
如果 Clean_Path_for_fragments 那麼
好的;
別的
Retry("未收到回應可能是因為 EDNS0");
萬一;
elsif Min_Response_Size > 512 那麼
如果 Clean_Path_For_EDNS0 那麼
好的;
別的
Retry("未收到回應可能是因為 EDNS0");
萬一;
else -- 今天最常見的情況，典型的未簽名
-- 答案是100-200字節
好的;
萬一;
萬一;
elsif EDNS0_Size >= 512 then -- 但低於 MTU
如果 DO_DNSSEC 那麼
如果 Min_Response_Size > EDNS0_Size 那麼
-- 假設設定了 TC 位元的 DNS 封包到達
——安全，但並非總是如此
重試（“截斷”）；
elsif Min_Response_Size >= 512 那麼
如果 Clean_Path_for_EDNS0 那麼
好的;
別的
Retry("未收到回應可能是因為 EDNS0");
萬一;
else -- 今天不會經常發生，來自根的一些回應已經 > 512
好的; -- 並非總是如此，某些中間件可能會阻止 EDNS0
-- 響應，即使尺寸為 512
如果 Clean_Path_For_EDNS0 那麼
好的;
別的
Retry("未收到回應可能是因為 EDNS0");
萬一;
別的
好的;
萬一;
萬一;
else -- EDNS0 大小為 512 然後
重試（“截斷”）；
別的
好的;
萬一;
萬一;
其他——TCP
如果 Can_TCP 則
好的; -- 但權威名稱伺服器上的延遲更高，負載更高
別的
Error("回退到 TCP 失敗"); ——徹底失敗
萬一;
萬一;
答案3
測試您的設定的另一個解決方案是，我發現它比 Netalyzr 簡單得多OARC回復大小測試。