我管理著幾個擁有 10-30 台機器的網絡，並運行一個bind名稱伺服器來為我的客戶提供DNS 解析（而不是轉發到康卡斯特或谷歌——我不喜歡以這種方式宣傳我的使用者的網路活動）。我的名稱伺服器對某些本地事物具有權威性，並且它對其他所有事物進行完整的從根解析。這基本上可以正常工作，但即使在重新啟動之後，bind 也不需要很長時間就開始記錄got insecure response; parent indicates it should be secure錯誤。我相信當一個全新的名稱被解析時，當我的副本bind開始從.com或.org或其他什麼解析時，就會發生這些情況。
我還沒有深入研究目前的 DNS 協議，也沒有開始tcpdump嗅探；我希望有人能夠說「你的時基已關閉」或類似的話，這將使我免於深入的 DNS 潛水。 （我正在運行 NTP，我相信我的系統時間足夠接近，這不是問題。）
是否存在影響運行此類遞歸名稱伺服器的小型網站的常見問題？或者是否有一個並行運行的好工具bind可以幫助我找出為什麼bind會抱怨？請注意，即使某些名稱無法解析，我相信其他名稱也可以解析。例如，我可能遇到問題，foo.bar.com.報告為validating .com/SOA: got insecure response，但gibble.gobble.com解決正常。 （我的bind運行在自建的OpenWRT路由器上，因此建立新版本的工具有些不方便，但如果我必須重新建置並重新安裝新系統，我可以做到。）
答案1
此訊息表示您正在查看的網域啟用了 DNSSEC（即父域有一條指向子網域的 DS 記錄，這表示子網域中的記錄應該被簽章），但是回應沒有附帶 DNSSEC簽章（網域設定錯誤）或您的名稱伺服器無法解釋DNSSEC 簽章（可能是使用您的DNS 伺服器無法處理的加密演算法產生的簽章）。如果沒有無法解析的域的具體範例，我們就無法確定是哪個域。
您可以關閉 DNSSEC 驗證，這肯定會阻止錯誤（和名稱解析）失敗，但從安全性角度來看，這不是一個好主意。如果您從不鎖上房子的前門，您也永遠不會發現自己被鎖在外面;-) 如果錯誤的原因是網域上的 DNSSEC 配置錯誤，那麼顯然您對此無能為力（我不知道）認為BIND 提供了一種選擇性地忽略每個網域的DNSSEC 錯誤的方法，即使您願意）。如果問題是您的 BIND 版本中不支援的加密演算法，則更新 BIND 可能是唯一的修復方法。