- CERT-Bund 在编号 WID-SEC-2026-2484 下发布了一份关于 BIND 安全漏洞的公告。
- 所有运行
named的服务器都可能受到影响——无论是作为自有域名的权威域名服务器,还是作为递归解析器。 - 在一台 Root 服务器上,检查用不了 15 分钟:确认版本、检查 53 端口的可达性、调整配置、更新软件包。
DNS 服务器大多数时候就这样自顾自地运行,多年无人问津,直到某天冒出一份编号类似 WID-SEC-2026-2484 的公告,你才开始怀疑,服务器上的“named”是不是还是 2023 年安装的那个版本。
事情的原委
CERT-Bund 的预警与信息服务发布了一份关于 BIND 安全漏洞的公告。BIND 是互联网上很大一部分权威及递归 DNS 基础设施所使用的域名服务器软件——从管理几个域名的业余域名服务器,到整个数据中心的递归解析器都在用它。具体的 CVE 编号、受影响的版本范围以及严重程度,请查阅CERT-Bund 的原始公告——那才是权威来源,而不是这篇摘要。
作为运营者,无论公告细节如何,对你而言重要的事情始终一样:你需要知道运行的是哪个版本、该服务是否能从互联网访问,以及你能多快装上更新,同时不中断你自己或客户域名的解析。
谁可能受到影响
并不是每个拥有域名的人都会自己运营域名服务器——大多数人使用的是注册商或主机商提供的 DNS。如果你在自己的 Root 服务器或 VPS 上自行安装了 bind9 或 named——比如用来管理自己的区域、为内部服务运行递归解析器,或者集中管理多个域名的 DNS——这份公告才与你相关。
| 运行方式 | 是否可从互联网访问 | BIND 漏洞的典型风险 |
|---|---|---|
| 权威域名服务器(自有域名) | 是,53 端口必须开放 | 区域劫持、缓存篡改,最坏情况下可执行代码 |
| 递归解析器(公开) | 是,通常还可能被滥用于 UDP 放大攻击 | 缓存投毒、DDoS 放大、代码执行 |
| 内部解析器(仅限局域网/VPN) | 否,仅可从自有网络访问 | 风险较低,但在其他入侵事件发生后的横向移动中仍具相关性 |
如何检查你自己的服务器
以下步骤假设 BIND 是通过你所用发行版的软件包管理器以 bind9 软件包形式安装的,这是大多数 Debian 和 Ubuntu 系统上的常见做法。
- 确认已安装的版本。 首先检查实际运行的版本,而不只是软件包管理器中显示为已安装的版本。
named -v sudo systemctl status bind9 - 与公告比对。 打开公告,将其中列出的受影响版本范围与你的输出结果进行比对。如果你的版本比公告中提到的已修复版本更旧,那么你就受到了影响。
- 检查可达性。 确认你的服务器是否以及如何能从互联网访问——这决定了更新的紧迫程度。
sudo ss -tulpn | grep :53 - 更新软件源并安装更新。 先拉取最新的软件包列表,再安装更新本身。
sudo apt update sudo apt list --upgradable | grep bind9 sudo apt upgrade bind9 - 重启服务并检查状态。 仅仅升级还不够——必须重启正在运行的进程,已修复的版本才会生效。
sudo systemctl restart bind9 sudo rndc status - 加固配置,这一点与本次具体公告无关。 在
named.conf.options中限制谁可以发起递归查询和请求区域传输:allow-recursion { 127.0.0.1; dein.internes.netz/24; }; allow-transfer { deine.sekundaer.ip; };
检查是否成功
更新并重启之后,你应该检查两件事:新版本确实已经生效,以及域名解析仍然正常工作。
named -v
dig @127.0.0.1 deine-domain.de +short如果 dig 返回了应答,并且 named -v 显示的正是预期中已修复的版本号,那么更新就成功了。之后再看一眼日志,确认重启过程中没有出现配置错误:
sudo journalctl -u bind9 -n 50 --no-pager自己运营 BIND 服务器,还是交给别人?
像这样的一份公告,正好是个契机,可以从根本上问一问:对你的使用场景来说,自行维护域名服务器是否仍然是正确的选择。
- 对区域、TTL 和访问规则拥有完全的控制权
- 不依赖第三方服务商的可用性
- 如果你需要复杂的内部 DNS 结构或 Split-Horizon 设置,这是必要的
- 你必须自己负责跟踪像这样的公告并及时打补丁
- 无论当前有没有公告,开放的 53 端口始终是一个长期的攻击目标
- 如果域名数量不多,维护成本往往与收益不成比例
如果你决定自己运营,那么对 BIND 而言,适用的基本原则和服务器上其他任何公开可访问的服务一样:尽可能收紧访问权限、及时安装更新,并且不要忘记其余的安全加固措施。比如同一台服务器上的 SSH 访问该如何正确加固,我们在另一篇关于 SSH 访问、密钥和 fail2ban 的文章中做了总结——其中的原则可以直接套用过来。
一份公告并不会改变威胁状况,它只是让威胁变得可见。漏洞之前就已经存在——只是还没有一个公开的编号。
一份已经公开的公告如果被忽视,会很快变成真正的问题——我们对Virtualizor 遭 BGP 劫持并被植入恶意更新事件的回顾就说明了这一点:在那起事件中,真正的漏洞也是在被利用之前就已经为人所知。更新之后,如果不仅重启服务,还持续对其进行监控,就能更早发现再次出现的故障或入侵——为此我们提供了针对服务器和服务的监控方案。
如果你根本不再需要 BIND
BIND 常常在实际需求早已消失之后仍然保留在系统上——一套旧的设置、一台测试服务器、一个已经停止的项目。在这种情况下,面对公告最干净利落的应对方式不是更新,而是卸载:
sudo systemctl stop bind9
sudo systemctl disable bind9
sudo apt purge bind9一个没有在运行的服务,不管漏洞有多严重都无法被利用——而且无论当前公告如何,少开一个端口就是少一分攻击面。
