我的系统日志中充斥着类似这样的消息
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 攻击还是只是 bind 的奇怪行为。
所以我设置了一个简单的 fail2ban 监狱，封锁 24 小时内产生超过 20 个此类错误的 IP。周末过后我检查了一下，结果令人震惊：超过 1000 个 IP 被封锁。包括像 1.1.1.1 这样的著名 IP。所以这不可能是对的。
我的服务器是通过 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 攻击。有人可以利用你的这种阻止行为让你的服务器停止响应来自任意地址的查询，这可能会被滥用来拒绝合法流量。