我的系統日誌充斥著類似的消息
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
我不知道這是 DDoS 攻擊還是只是奇怪的綁定行為。
所以我設置了一個簡單的fail2ban監獄，它會阻止在24小時內產生超過20個此類錯誤的IP。週末後我檢查了一下，驚訝地發現：超過1000個IP被封鎖了。包括像1.1.1.1這樣著名的。所以這不可能是正確的。
我的伺服器是透過 Plesk Obsidian 管理的 Debian 9。我沒有對bind9/named 進行特殊配置（據我所知）。它是我所有網域的主要 ns 伺服器。
所以問題是：我能做些什麼來保護我的伺服器免受如此大量的 DNS 查詢的影響，或者我應該忽略它們。
答案1
很難明確地說，但乍一看，這可能是一次嘗試的反射攻擊（或是對在此類攻擊中使用伺服器的可行性的測試）。
此類攻擊背後的想法是透過 UDP 發送帶有欺騙性來源 IP 位址的查詢到開放解析伺服器，以生成到攻擊目標（實際具有欺騙性來源 IP 的主機）的流量，使用已知會產生大響應以獲得攻擊者發送查詢所需的頻寬的高放大率。
假設情況確實如此，其意義是：
- 您不是真正的目標，而只是為了「借出」您的頻寬。來源位址是指誰被認為受到攻擊（或誰正在探測您的伺服器是否可用於此類目的）。
- 它實際上並沒有起作用。當您拒絕這些請求時，回應並不像實際回應那麼大
. ANY。 （大概是因為一開始就不允許遞歸，這很好）。
關於您認為它似乎合法的感覺，因為來源 IP 位址之一是1.1.1.1，我想說我的本能反應恰恰相反。看到1.1.1.1這個查詢的來源位址立即表示發生了一些奇怪的事情：
- 我們知道這
1.1.1.1是任播，這使得從該地址發起查詢是一個糟糕的主意。如果您回應查詢，1.1.1.1您的回應將被路由到最近的（在 BGP 意義上）1.1.1.1實例，而不是產生查詢的實例。 - 即使忽略來源位址的選擇，為什麼 Cloudflare 公用解析器會向您的伺服器傳送查詢
. ANY？您不是權威機構.，他們也沒有理由向您轉發查詢。
也就是說，我認為你是對的，這些查詢可能是「不懷好意的」。
現在，我不太確定要阻止來自這些位址的流量是否是一個好主意。這裡的問題是它容易遭受 DoS 攻擊。有人可以利用您的這種阻止行為來使您的伺服器停止回應來自任意位址的查詢，這可能會被濫用來拒絕合法流量。