网站被 DDoS 打不开时，很多站长第一反应是服务器扛不住。但访问一个网站要经过本地缓存、递归解析、权威解析、拿到 IP、再建立连接这一整条链路，其中任何一环出问题，现象都是「打不开」。DNS 自身被压垮、解析记录被改动、解析还指着旧 IP、上游把 IP 拉黑，这几类问题都不在服务器上。本文用 9 个问答讲清被打之后域名与解析侧的排查顺序和加固方法。
Q：被打后网站打不开，一定是服务器撑不住了吗？
- 不一定。要先建立一个概念：「网站打不开」是现象，不是结论。
- 完整链路是：浏览器缓存 → 本地 DNS 缓存 → 递归解析器 → 权威 DNS → 返回 IP → TCP 与 TLS 握手 → 服务器响应。
- 链路上常见的四类解析侧故障：
- DNS 服务被压：权威服务器或递归解析器被 UDP 洪水打到超时，查询直接没响应。
- 记录被改：域名或 DNS 服务商账号被盗，NS 记录或 A 记录被换掉。
- 记录没跟着变：切了高防或 CDN，但解析还指着源站 IP，等于防护没有生效。
- 被上游处理：IP 被机房黑洞、被运营商限速，或域名被注册商置为 clientHold 状态。
- 判断顺序应该是：先证明解析通不通，再证明连接通不通，最后才怀疑服务器负载。
Q：怎么一步步分清是解析问题还是服务器问题？
- 用几条命令就能把范围缩小，关键是换一个递归解析器做对照：
# 1) 本地视角：解析到了哪个 IP
dig +short www.example.com
# 2) 换公共递归解析器对照，绕过本地缓存
dig +short @223.5.5.5 www.example.com
dig +short @8.8.8.8 www.example.com
# 3) 直接问权威服务器，绕开所有缓存
dig @ns1.yourdns.com www.example.com +noall +answer
# 4) 绕开 DNS，指定 IP 直接测业务端口
curl -sI -m 5 --resolve www.example.com:443:1.2.3.4 https://www.example.com/- 对照结果怎么读：
- 本地解析失败、公共解析正常 → 本地缓存或本地网络问题，不是服务器。
- 公共解析也超时或失败 → 权威 DNS 侧的问题，多半是被压或 NS 不可达。
- 能解析出 IP，但第 4 步 curl 超时 → 问题在线路、端口或服务器本身。
- 解析出来的 IP 不是高防或 CDN 的 IP → 记录或 TTL 出了问题，防护实际没有生效。
Q：怎么确认是权威 DNS 被压垮了？
- 典型特征：不是所有查询都失败，而是时通时不通、响应很慢或返回 SERVFAIL。
- 三件事可以确认：
- 从多个外部节点测：用不同公共解析器反复查同一域名，成功率明显不稳就是被压。
- 看完整解析路径：
dig +trace www.example.com，能定位是根、顶级域还是你自己的 NS 没响应。 - 在权威服务器上抓包：看 53 端口是否被大量非正常来源刷。
# 抓 53 端口，观察来源 IP 分布
tcpdump -i eth0 -n -c 500 'udp port 53' 2>/dev/null | awk '{print $3,$5}' | sort | uniq -c | sort -rn | head -20
# 看每秒查询量级别，判断是否被打
sar -n DEV 1 5 | grep -E 'IFACE|eth0'- 顺带说一个常见误区：DNS 攻击不只是「被打」，也可能是「被利用」。如果你的服务器开放了递归解析，会被拿去当放大攻击的反射器，最后把自己卷进黑洞。
Q：自建 DNS 该怎么加固，避免被打死或被人利用？
- 核心三条：不做公共递归、限制单 IP 速率、禁止区域传送。
# named.conf.options（BIND）关键项
options {
recursion no; # 只做权威解析，关闭递归，避免被当反射器
allow-transfer { none; }; # 禁止 AXFR 拉走全量记录
allow-query { any; }; # 只允许正常查询
rate-limit {
responses-per-second 10; # 单客户端每秒应答上限
slip 2; # 超限时按概率回 TC，让客户端改用 TCP 重试
window 5;
};
};
# 内核层再加一道闸：限制单 IP 对 53 端口的请求速率
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name dnslimit --hashlimit-above 30/sec --hashlimit-burst 60 \
--hashlimit-mode srcip --hashlimit-htable-expire 60000 -j DROP- 如果 Nginx 回源写的是域名而不是 IP，解析抖动会直接变成 502，建议显式指定 resolver 并缩短缓存时间：
resolver 223.5.5.5 119.29.29.29 valid=30s ipv6=off;
resolver_timeout 2s;Q：怎么发现解析记录被改了，平时该怎么防？
- 发现靠对比，防护靠权限：
- 查 NS 有没有被换：
dig NS example.com +short，结果必须和你在后台里看到的一致。 - 查域名状态：whois 里出现
clientHold说明被注册商暂停解析；出现clientTransferProhibited是转移锁已开启，属正常。 - 多地对照：用两三个不同公共解析器同时查，结果不一致往往说明缓存被污染，或者正在切换过程中。
- 四项基础防护：域名和 DNS 账号开两步验证、开启注册商转移锁、开启变更邮件通知、用独立邮箱且不与其它业务共用。
- DNSSEC 可以防篡改，但要注意：配置错误会让整站解析直接失败，务必先在测试域名上验证通过再上生产。
Q：切了高防还是打不开，是不是 TTL 没生效？
- 这是最典型的「防护上线了但没生效」，原因通常是三条：
- TTL 是上限不是定时器：递归解析器可以自行延长缓存，改完记录不代表全网立刻生效。
- 只改了主域名没改子域名：www、api、图片和静态资源域名经常各有记录。
- 解析切对了，但源站还开着公网访问：攻击者直接打源站 IP，防护形同虚设。
- 正确做法是提前 24 小时把 TTL 降到 60 至 300 秒，再切记录；切完用权威服务器直接验证：
# 直接问权威，看新记录是否已经生效
dig @ns1.yourdns.com www.example.com +noall +answer
# 看递归侧还剩多少缓存时间（ANSWER 段第二列即剩余 TTL）
dig www.example.com | grep -A1 'ANSWER SECTION'- 另外别忘了源站侧收口：只放行高防或 CDN 的回源网段，其余来源直接拒绝，否则隐藏源站 IP 这件事等于没做。
Q：解析正常但就是访问不了，怎么判断是不是被上游处理了？
- 表现很有辨识度：解析结果正常，但部分地区甚至全部地区连不上，或者只有某个端口不通。
- 排查三步：
- 测路径：
traceroute -T -p 443 1.2.3.4，走到某一跳就断，通常是那一侧做了限制。 - 测端口：
nc -vz -w 3 1.2.3.4 443，端口不通而 ping 通，说明是策略层拦截。 - 直接问上游：机房、云厂商、运营商是否对该 IP 做了黑洞或限速，这是最快的确认方式。
- 处理方向：短期换 IP 或把流量切到高防节点；长期要把源站 IP 从公开渠道收干净，别让攻击者总能找到真实地址。
Q：平时怎么做，才能在被攻击时不慌？
- 四条能显著提高抗风险能力：
- 解析冗余：至少两个不同的 DNS 服务商、四台以上 NS，避免单点故障。
- 监控告警：监控解析成功率、权威服务器 QPS、解析响应时间，而不是只监控网站首页能不能打开。
- 预案留档：把「切解析、改 TTL、封源站、报上游」写成可执行清单，附上账号和联系人。
- 定期演练：每季度做一次解析切换演练，确认真的能在 10 分钟内生效。
Q：还有什么补充建议？
- 把「网站打不开」当成一条链路来排查，而不是一个点。先分解析、再分连接、最后看负载，能省掉大量无效操作。
- 被打之后的第一小时最值钱，此时保留日志、记录解析变化和 traceroute 结果，对后续找上游、报案都有用。
- 如果自家 DNS 运维能力有限，把权威解析托管给专业服务商，通常比自建更稳，成本也未必更高。