服务器安装dns后为什么无法联网，DNS配置错误导致网络不通？

服务器安装DNS后无法联网，绝大多数情况下不是DNS软件本身的问题，而是配置层面的连锁反应最常见的就是系统解析器被改写、递归查询未放行、防火墙拦截53端口这三个坑。

服务器装完DNS就断网的常见原因

很多朋友在服务器上装完BIND或者dnsmasq之后，发现ping不通外网了，这个场景在运维工作中出现频率相当高,尤其是新手第一次在CentOS或者Ubuntu上折腾DNS服务时。

装之前好好的，装完就掉线，问题的根源往往不在“安装”这个动作本身，而在于DNS服务的监听、转发和系统解析配置发生了冲突。

系统resolv.conf被覆盖，基础网络先废了一半

服务器原来能正常联网，是因为/etc/resolv.conf里写着ISP或者云厂商提供的DNS服务器地址，当你安装完DNS软件并启动服务后，很多管理工具会自动把本机DNS指向127.0.0.1,也就是本机。

这一步本身没有错，问题在于很多人在配置BIND时没有设置合理的forwarders，导致本机DNS服务接了解析请求后找不到上游，循环查询卡死，最后超时，表现出来就是：ping 223.5.5.5能通，但ping www.baidu.com不通。

如果你刚装完dns就发现上不了网，第一步不是去看DNS进程跑没跑，而是先看resolv.conf内容：

cat /etc/resolv.conf

如果里面只有nameserver 127.0.0.1而没有备用上游地址，并且你配的DNS服务端又没有转发能力，那所有域名解析都会失败，酷番云和简米云的服务器上还经常遇到NetworkManager或者systemd-resolved把这份文件强制覆盖的情况,你改完一重启就还原。

BIND配置里监听和递归权限没开

这是服务器安装dns后无法联网的第二大原因，BIND默认配置文件/etc/named.conf里，options区块通常只监听本机回环地址,递归查询只允许localhost访问。

当你在服务器上装了BIND，想让内网其他机器也用它做DNS，很多人会去修改listen-on和allow-query，但漏改了allow-recursion。

这种情况下，服务器自身发往公网的解析请求会卡在递归查询环节因为BIND没有把本机IP加入递归白名单，表现出来就是，服务状态正常，53端口也在监听,但域名就是解析不出来。

检查命令：

systemctl status named
ss -lntp | grep 53

防火墙拦截，装完dns反而把端口堵死了

很多云服务器默认防火墙策略只放行常用端口，你装完DNS服务后，防火墙并没有自动放行UDP/TCP 53端口，服务器自己的解析请求发出去了，但对端的响应被防火墙丢掉,自然无法联网。

这种情况在你用firewalld或者ufw的服务器上特别常见，CentOS 7以上系统默认启用了firewalld，Ubuntu系则用ufw，判断方法很简单,临时关掉防火墙试一下就知道：

systemctl stop firewalld

如果关了防火墙就能正常解析,那问题就锁定在防火墙规则上。

排查服务器DNS问题必须按顺序来

与其浑身找原因，不如按下面这个路径一步步排，十分钟内能定位绝大多数故障，这套思路来自Linux运维的通行做法，适用于BIND、dnsmasq、unbound这些主流DNS软件。

第一步：确认系统解析文件没有坏

先确认/etc/resolv.conf里至少有一个能用的外部DNS作为后备，比如nameserver 223.5.5.5，如果里面全是127.0.0.x，先临时把它改掉,确认服务器能否恢复联网：

echo "nameserver 223.5.5.5" > /etc/resolv.conf

能恢复联网，说明你的DNS服务确实没有正常处理本机请求，不能恢复,问题在别处。

第二步：明确DNS服务是否真的在运行

这里不只看进程在不在,要确认端口有没有实际监听：

netstat -an | grep :53

如果只有127.0.0.1:53在监听，说明配置只允许本机访问，你需要把监听地址改成服务器内网IP或者0.0.0.0。

第三步：实测本机DNS服务有没有响应

用dig或者nslookup直接发给本机IP或者回环地址，确认能否拿到域名解析结果，这是区分“DNS服务起作用”和“系统解析路径不通”的关键分界线。

dig @127.0.0.1 www.baidu.com

如果返回状态为REFUSED，一般是递归权限问题，如果超时,那优先查转发配置有没有写对。

第四步：检查防火墙规则，放行53端口

无论你用什么防火墙工具,以下规则是最基础的放行方式：

firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

Ubuntu下用ufw的用户：

ufw allow 53/tcp
ufw allow 53/udp

第五步：确认上游转发配置正确

BIND的/etc/named.conf中，options区块里的forwarders决定解析请求往哪送，行业共识认为，靠谱的转发目标是公共DNS这种有保障的基础设施，比如223.5.5.5或者119.29.29.29,尽量不要用自己所在机房不稳定的上游网关。

配置保存后记得重启服务：

systemctl restart named

不同Linux发行版上的处理差异

服务器安装dns后无法联网的问题，在CentOS和Ubuntu上的处理思路不太一样，下面表格内容基于实际运维经验整理,可直接对照操作。

CentOS系列：NetworkManager和DNS配置的拉扯

CentOS系统上最典型的场景是：手动编辑了/etc/resolv.conf，重启网络后变了回去，装完DNS服务后，NetworkManager会重置网卡的DNS配置,覆盖掉你写的文件。

需要在网卡配置文件里关闭NetworkManager接管：

nmcli con mod eth0 ipv4.ignore-auto-dns yes

或者直接在网卡配置文件中指定DNS顺序，让NetworkManager知道你要用的是哪个解析方向，经常配置在CentOS服务器上做实验的用户，普遍会遇到这个情况，据统计，在系统运维论坛提问的案例里，resolv.conf被重置占到了较大比例。

Ubuntu系列：systemd-resolved的端口冲突

Ubuntu桌面版和服务器版默认开启systemd-resolved，它会占用127.0.0.53:53口，你再装一个BIND监听同样的端口，大概率起不来,或者起来了也不正常。

标准处理方式是把BIND的监听地址改成服务器实际IP或者any，然后停掉systemd-resolved,防止占用端口：

systemctl stop systemd-resolved
systemctl disable systemd-resolved

然后修改/etc/resolv.conf指向本机IP,这是很多Ubuntu服务器配置本地DNS服务的必经步骤。

配置DNS服务时如何操作才能不断网

很多用户问过：服务器装了dns后还能恢复联网，是不是只能重装系统？完全不用，以下几个配置习惯我用下来觉得最省心,按这个改能大幅降低把自己锁在门外的概率。

BIND的options区块参考配置

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    direct
ory   "/var/named";
    dump-file   "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query     { any; };
    allow-recursion { internal_nets; };
    recursion yes;
    forwarders { 223.5.5.5; 119.29.29.29; };
};

注意forwarders放在全局，确保服务器自己解析外部域名时能走转发路径，递归和查询权限别都依赖allow-query,单独的递归白名单更安全。

dnsmasq的防坑写法

如果你用的是dnsmasq,核心参数是这些：

listen-address=0.0.0.0
server=223.5.5.5
server=119.29.29.29
no-resolv

no-resolv确保不读取系统resolv.conf因为你已经把它指向了本机，再用dnsmasq读一遍就会产生循环,这是不少用户配置后连接不上服务器的直接原因之一。

用一台测试机检查服务成果

配置完成，不要急着把其他机器的DNS指过来,先用网络内的另一台Linux主机跑一下：

dig @你的服务器IP www.baidu.com

能拿到A记录，再批量切换内网DNS，这样做的好处是，出问题只影响那台测试机，不影响整个办公网络，行业共识认为，批量切换DNS前做单点验证是最稳妥的做法，据互联网系统协会技术文档说明，递归响应异常的排查中,配置验证是最高频的修复手段。

服务器DNS安装后的Q&A

为什么服务器上搭完DNS，外网域名解析超时，重启服务后过一会儿又不行？

这种情况通常是上游DNS响应不稳定，或者BIND的转发配置没有生效，先把forwarders换成备用的另一组DNS，比如把阿里换成DNSPod的，再配合日志分析来看请求走向，有时候是内网QPS过高导致dns的缓存溢出，重启后暂时恢复，过段时间又打满,这时需要调低缓存内存上限或者拆分内网解析和公网解析到不同服务实例。

服务器搭建DNS后，只有内网域名能通，公网域名全挂，是什么原因？

典型的递归功能未开启，内网域名走的是BIND本地zone文件，这部分不需要递归；公网域名查询需要递归遍历整个DNS体系才能拿到结果，每个转发和授权环节都依赖递归开关的开启，检查配置里recursion yes;和allow-recursion是否只允许了局域网网段,本机IP是否也在列表内。