如果解析器遇到它不支持的 DNSSEC 算法會怎樣？
它是拒絕返回請求的記錄，還是返回記錄，將域視為不安全？
如果解析器遇到它不支持的 DNSSEC 算法會怎樣？
只要存在一個驗證路徑，DNSSEC 就允許驗證。如果解析器能夠找出它支持的至少一種算法並檢查一切（簽名等）是否正常，則 DNSSEC 驗證將正常，未知算法將被忽略。
當然，如果解析器只找到它不支持的算法，甚至沒有找到它支持的算法，那麼 DNSSEC 驗證將失敗並被
SERVFAIL返回。可能有多個 DNSKEY RR 匹配上述條件。在這種情況下，驗證器無法預先確定使用哪個 DNSKEY RR 來驗證簽名，並且它必須嘗試每個匹配的 DNSKEY RR，直到簽名被驗證或驗證器已經用完匹配的公鑰來嘗試。
所以一個好的算法就足夠了，解析器不必測試所有的算法。能夠在發布端逐步引入新算法，同時更新解析器以了解新算法，這很好。
另請參閱 RFC 8626“DNSSEC 的算法實施要求和使用指南”。
它是拒絕返回請求的記錄還是返回記錄，將域視為不安全？
DNSSEC 通常是二進制的：域具有正確的 DNSSEC 驗證或錯誤（因此
SERVFAIL）。如果解析器失敗，則不允許解析器從域中刪除 DNSSEC，並返回記錄，就好像該域從一開始就沒有 DNSSEC。然而，這就是理論。在實踐中，遞歸解析器有時需要繼續回答，即使是已知 DNSSEC 損壞的域，也確實會發生這種情況，因為它被認為會造成太大的負擔。參見過去著名的 NASA/Comcast 範例。這就是為什麼現在有“負信任錨”或 NTA 的原因：這是遞歸解析器的運營商說“域 X 的 DNSSEC 損壞，忽略那裡的失敗信任並像沒有 DNSSEC 一樣執行”的一種方式。它應該是一種臨時措施，顯然對於每個遞歸解析器都是本地的。
請參閱RFC 7646“DNSSEC 負信任錨的定義和使用”（2015 年 9 月）：
本文件定義了負信任錨 (NTA)，可用於通過在指定域禁用 DNSSEC 驗證來緩解 DNSSEC 驗證失敗。