綁定：查詢（記憶體）’./ANY/IN’ 被拒絕 - 是 DDos 攻擊嗎？

我的系統日誌中充斥著類似的消息

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 查詢的影響，或者我應該忽略它們。

很難確切地說，但乍一看，它可能是一次嘗試的反射攻擊（或測試在此類攻擊中使用您的伺服器的可行性）。

這種攻擊背後的想法是通過 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 攻擊打開了大門。有人可以使用您的這種阻止行為使您的伺服器停止響應來自任意地址的查詢，這可能被濫用以拒絕合法流量。

引用自：https://serverfault.com/questions/1049513