Bind9 如何作為私有 DNS 工作，以通過 URIBL Query Refused？
如果對 URIBL 的查詢被阻止，因為 URIBL “檢測到”您的 DNS 查詢正在使用已進行過多查詢並超出限制的 dns 解析器 IP 地址…
如何使用像 Bind9 這樣的本地 DNS 服務來解決這個問題？
我的有限理解是：
當開始對 URIBL 提供程序的查詢時，
本地 Bind9 區域不會包含任何有關 URIBL 的記錄
因此它需要去 DNS 轉發器來解析 URIBL 編輯：我的術語不正確。Bind9 將查詢 rootrvrs 以獲取 gTLD 提示
但是如果您的伺服器的 dns 轉發器是 8.8.8.8（一個 Google dns 場），並且該 IP 地址已被拒絕向 URIBL 查詢，
你如何繞過這個明顯的catch-22？
編輯：在了解了 bind9 如何使用 root srvrs 之後，我刪除了郵件伺服器的 dns 轉發器值 8.8.8.8 和名稱伺服器設置，bind9 返回了一個答案，因為它自己進行查找，而不是將其交給 8.8.8.8 名稱伺服器。
我已經閱讀了至少 50 個有關此問題的網頁，但沒有一個詳細說明它是如何解決的。
編輯：這個問題的其餘部分已被刪除，這是多餘的，我會問一個單獨的問題。
我認為您對 bind 作為記憶體名稱伺服器的工作方式感到困惑。DNS 轉發器僅在您從客戶端的角度說話時才真正發揮作用，並且與配置記憶體名稱伺服器的上下文無關。當向 bind 查詢它沒有的記錄時，它會遵循解析域名的正常過程，從根伺服器開始。我發現這個連結是一種有趣的方式來展示這個過程發生了什麼。您還可以查看您感興趣的任何域的整個醜陋過程 - 嘗試使用
dig +trace serverfault.com. 您所看到的將與 bind 遵循相同的解析鏈。一旦 bind 收到結果並假設為它啟用了記憶體，後續請求將從記憶體中提供，直到記錄 TTL 過期，在這種情況下，它會再次執行該過程以刷新其記憶體。因此，如果您設置了一個記憶體名稱伺服器，並且您試圖通過它查詢 URIBL並且它被拒絕了，那麼它不會被 Google 拒絕——它將是您自己的伺服器 IP。要確認，請嘗試探勘兩個名稱伺服器 - 您自己的 (
dig @<your_bind_server> test.uribl.com.multi.uribl.com) 和 Google 的 (dig @8.8.8.8 test.uribl.com.multi.uribl.com)，並查看拒絕發生的位置。另外，不，bind 不應該記憶體拒絕。