服务器dns作用是什么情况，如何排查解析故障？

服务器dns作用是什么情况：先分清你的服务器在用哪种dns

服务器dns作用是什么情况，简单说就是当你的服务器需要访问外部网站、发送邮件、调用API接口时，dns负责把域名翻译成服务器能识别的IP地址。 如果你的服务器本身是域名解析服务的提供方，那它的dns作用就是帮别人完成这个翻译过程，搞不清这两种角色,后面排查问题会绕很多弯路。

先搞明白dns在服务器上到底扮演什么角色

服务器上的dns服务，分为“正向解析”和“反向解析”，正向解析是把域名翻译成IP，你在浏览器里输入网址能打开网页，靠的就是这个，反向解析是把IP翻译回域名，主要用在邮件服务器反垃圾验证这类场景，据工信部公开信息，我国域名注册量近年来持续增长,dns解析服务的稳定性和安全性已经成为企业数字化运营的基础门槛。

行业内最常见的误解是：以为服务器dns就是那个“填在网卡里的IP地址”，其实那只是“dns客户端配置”,真正的作用分三种：

• 递归解析：服务器收到域名查询请求后，代替用户去根服务器、顶级域服务器逐级查询，最终返回结果,这是公共dns的主要工作方式。
• 权威解析：服务器本身就是某个域名的“最终答案来源”，比如你自建的dns服务器里存着公司内网的域名记录,这就是权威解析。
• 转发解析：服务器自己不查根，而是把请求丢给上游dns，自己只做缓存,内网dns经常用这种模式。

判断你的服务器dns作用是什么情况，最直接的方法是查监听端口和配置文件。 用netstat -tunlp | grep :53看是否有进程监听；用cat /etc/resolv.conf看服务器自己用的是哪个dns；用dig baidu.com看解析路径，三步走完,你就能定位自己服务器的dns角色。

服务器dns配置方法：域名解析失败时第一个该查的就是这里

经常有人遇到“服务器能ping通IP但打不开网页”或者“apt install报错说域名解析失败”，这时候问题大概率出在dns配置上，服务器dns配置方法其实不复杂,但很多人改错了文件。

主流Linux发行版的dns配置路径不一样，选错文件等于没改，这是常见的坑。

• CentOS/RHEL 7及以下：配置文件是/etc/resolv.conf，但NetworkManager每次重启会覆盖它，需要修改网卡配置文件/etc/sysconfig/network-scripts/ifcfg-eth0里面的DNS1=和DNS2=。



• CentOS/RHEL 8及以上：用nmcli命令，比如nmcli con mod ens33 ipv4.dns "8.8.8.8 114.114.114.114",然后重启网络服务。
• Ubuntu 18.04+：改/etc/netplan/.yaml，里面有个nameservers:段，改完执行netplan apply生效。
• Debian 10+：直接用/etc/resolv.conf，但注意systemd-resolved会管理这个文件，可能需要修改/etc/systemd/resolved.conf里的DNS=一项。

改完配置后，用systemd-resolve --status（有systemd-resolved的机器）或者dig @114.114.114.114 example.com来验证，验证的时候一定要指定上游dns地址，否则还是走的本机缓存,看不出真实效果。

域名解析失败怎么办：从服务器dns角度逐层拆解

域名解析失败这件事，行业内最常用的排查思路是“从右往左看”，拿www.example.com举例，先看com能不能解，再看example.com，最后看www这条A记录，出错点无非四层：根服务器、顶级域、权威服务器、本机缓存。

第一层检查本机到dns服务器的连通性。 ping 8.8.8.8能通不代表UDP 53端口通，用nc -vuz 8.8.8.8 53测试UDP端口，用dig @8.8.8.8 www.baidu.com测试实际解析，如果超时，大概率是防火墙或安全组把53端口拦了，云服务器的安全组规则、ECS主机的iptables,都要查。

第二层检查dns服务器本身是否正常。 如果你用的是公共dns（如5.5.5阿里、29.29.29腾讯、114.114.114运营商），可以换一个试试，行业共识认为，多dns冗余配置是基础操作,单一dns一旦故障就是单点风险。

第三层检查权威解析。 你有自己的域名，用dig NS example.com看返回的权威服务器列表，再用dig A www.example.com @你的权威服务器直接向权威服务器查询，如果这一步返回正确结果，说明域名解析记录本身没问题,问题出在中间环节的缓存上。

企业自建dns和公共dns哪个好：服务器场景下结论很明确

“企业自建dns和公共dns哪个好”这个话题，经常有争论，在服务器场景下,答案取决于你的业务依赖度。

如果服务器只跑面向公网的Web业务，直接用公共dns最省事，如果服务器是内网核心业务（比如办公域名、私有云、k8s集群），自建dns几乎是必须的。 自建dns用的软件主要是BIND、Unbound、CoreDNS三种，BIND老牌功能全但配置复杂；Unbound主打递归性能，缓存效率高；CoreDNS是云原生时代的宠儿,k8s集群里的service发现全靠它。

自建dns需要租一台低配服务器做主节点，一台做从节点，成本按云厂商标准配置来算，其实并不高，具体服务器dns价格取决于你买哪家的机器和带宽规格，但dns查询消耗的资源极低，共享型实例就够跑，公网域名解析量大的话，注意“响应速率限制”这个参数,防止被人当作反射放大器打流量攻击。

服务器dns怎么填：按使用场景给你四个参考配置

“服务器dns怎么填”这个问题，百度上搜索量一直很高，因为不同云厂商的默认dns地址不一样,填错了一个都可能导致解析失败。

• 服务器是简米云ECS，跑的是nginx反代：内网dns填100.2.136（服务商内网公共DNS），公网dns填5.5.5和6.6.6（阿里公共DNS），注意：简米云经典网络和VPC网络的内网dns地址不同，VPC的网络用于查询OSS、RDS等内网域名。
• 服务器是酷番云CVM，业务涉及跨地域访问：内网dns填60.83.19（酷番云的VPC内网DNS地址，具体可在控制台查看），公网dns填29.29.29，酷番云的云解析是DNSPod，只要你域名的NS记录指向它,解析记录改动是秒级生效。
• 自建机房服务器，有域控需求：首选填自己域控服务器的IP，备选填114.114.114作为逃生通道，避免域控挂了整网瘫痪，域控服务器上建议开启dns forwarding，把外部域名转发到公共dns去解析,减轻根区域查询压力。
• 涉及跨境业务的服务器：填8.8.8和1.1.1虽然在国内部分网络环境下不稳定，但如果你有海外节点或者专线，这两个是全球通用性最好的公共dns，要注意的是，Google和Cloudflare的dns对DNSSEC支持较好，有些严格校验的环境中,这两个地址能减少解析被劫持的风险。

还有一个小细节容易被忽略：IPv6环境的dns配置，如果服务器开了IPv6，那resolv.conf或netplan里最好也配上IPv6的dns地址（如2400:3200::1阿里IPv6 DNS），否则开了IPv6但没配置对应dns，某些系统会尝试AAAA记录查询,等待超时反而拖慢解析速度。

服务器dns放在内网和外网有什么区别

内网和外网的dns解析机制有一个核心差异：内网dns主要做“覆盖和改写”，外网dns主要做“迭代和缓存”。

内网场景下，dns服务器通常负责把内部维护的系统名称（比如gitlab.company.local）指向对应服务器的内网IP，便于内部系统互相调用，不走公网流量，这种解析记录不需要注册到公网根域，只需要在内网dns里配置一个zone文件，如果你的业务里有consul、etcd、k8s这类组件，它们往往还会自动注册域名记录到内网dns,实现服务的动态发现。

外网场景下，服务器dns负责的是标准域名解析流程，从根提示文件开始逐级往下查找，这里要注意：服务器上如果有防火墙，出站UDP 53端口要开放给根服务器的IP段。 很多云服务器默认安全组只开了TCP 80/443，结果导致dns查询的响应包进不来,表现为网页加载超时但ping测试一切正常。

服务器dns作用是什么情况，一句话概括：对内是服务发现的基石，对外是业务访问的大门，你的服务器如果出现“域名解析失败“或“网络连接超时”，先看resolv.conf，再看安全组，然后测dns解析链路，别把问题往复杂里想，90%的dns故障都出在这三步里。

服务器dns相关问题解答

服务器上dns地址填错会导致什么后果？

填错dns地址的话，后果是：能ping通IP，但域名解析全部失败，比如curl请求返回“Could not resolve host”这个错误，如果你填的是内网dns的IP，却把它用在公网机器上，往往表现为很多域名能解析，但部分域名超时,因为内网dns的转发策略限制不完整。

服务器dns缓存在哪里，怎么清空？

主流的Linux发行版使用systemd-resolved管理dns缓存，清空命令是systemd-resolve --flush-caches，旧一些的CentOS 6/7系统没有systemd-resolved，用的是nscd，清空命令是service nscd restart，清完缓存后可以用dig facebook.com验证解析是否恢复正常。