DNS服务器是什么

DNS Server，直白一点说，就是把域名解析成 IP 地址的系统。人访问网站习惯输入 www.example.com，服务器之间通信靠的是 1.1.1.1、8.8.8.8、203.0.113.10 这种 IP。DNS 做的事情就是中间翻译。

实际使用中发现，很多故障表面看是网站打不开、接口超时、证书异常，排查到后面其实是 DNS 解析不对、缓存没刷新、运营商递归 DNS 污染、权威 DNS 配置缺失，或者某条记录 TTL 设置太长。

DNS 不只是“域名指向服务器”这么简单。生产环境里，它还承担线路调度、容灾切换、CDN 接入、邮件验证、证书签发校验、内网服务发现等工作。尤其是云服务器、海外业务、游戏服、电商站点，这些场景对 DNS 的稳定性很敏感。

DNS解析链路大概怎么走

用户在浏览器输入域名后，系统不会直接去问你的服务器，而是按一条链路逐层查询。

客户端先看本地缓存，比如浏览器缓存、操作系统 DNS Cache、hosts 文件。如果本地没有，就去问配置好的递归 DNS，比如运营商 DNS、公共 DNS、企业自建 DNS。

递归 DNS 如果自己也没有缓存，就会去问 Root DNS，然后问 TLD DNS，比如 .com、.net、.cn 的顶级域 DNS，再找到域名对应的权威 DNS。权威 DNS 返回 A、AAAA、CNAME、MX、TXT 等记录，递归 DNS 缓存后再返回给客户端。

这里补充一点，平时说“修改 DNS 生效慢”，大部分不是权威 DNS 没改成功，而是递归 DNS、客户端、本地应用缓存还没过期。TTL 设置 600 秒，不代表所有地方都严格 10 分钟刷新，有些运营商递归 DNS 会有自己的缓存策略。

常见DNS记录类型怎么理解

A记录和AAAA记录

A Record 用来把域名解析到 IPv4 地址，比如把 api.example.com 指向 203.0.113.10。AAAA Record 用来解析到 IPv6 地址，比如 2400:xxxx::1。

大部分业务还是以 A 记录为主。海外业务、移动端业务、面向 IPv6 网络优化时，可以补 AAAA。配置 AAAA 前要确认服务器、防火墙、安全组、Web Server 都已经监听 IPv6，不然会出现部分用户访问失败。

CNAME记录

CNAME 是别名记录。比如 www.example.com CNAME 到 cdn.example.net，后续真正解析到哪个 IP，由 cdn.example.net 决定。

接 CDN、高防 IP、云厂商负载均衡时经常用 CNAME。注意根域名 example.com 通常不建议直接配 CNAME，很多 DNS 服务商会限制，或者用 ALIAS、ANAME 这类变通能力。

MX记录

MX 用于邮件收发。企业邮箱配置时一定会用到，比如把 example.com 的邮件交给 mx1.mailserver.com。MX 有优先级，数字越小优先级越高。

邮件系统还会配 SPF、DKIM、DMARC，这些通常是 TXT 记录。如果企业邮箱能收不能发，或者发出去进垃圾箱，DNS 里的 TXT 记录要重点查。

TXT记录

TXT 记录经常用于验证所有权，比如 SSL 证书 DNS 验证、Google Search Console、企业邮箱反垃圾验证、云服务绑定域名验证。

实战里 TXT 最容易踩的坑是引号、空格、重复记录。有些面板显示带引号，有些不带；有些 DNS 服务商会自动拆分长 TXT。配置后建议用 dig 查真实返回值，不要只看面板。

NS记录

NS Record 指定某个域名由哪些权威 DNS 服务器负责。比如 example.com 的 NS 指向 ns1.xxxdns.com 和 ns2.xxxdns.com。

如果你在注册商那里改了 NS，等于把整个域名解析权交给新的 DNS 服务商。很多迁移事故就发生在这里：新 DNS 平台没提前导入完整解析记录，NS 一切过去，业务直接断。

公共DNS、递归DNS、权威DNS不要混在一起

DNS 里有三个概念经常被混用：公共 DNS、递归 DNS、权威 DNS。

公共 DNS 通常是给客户端用的，比如 8.8.8.8、1.1.1.1、114.114.114.114。它们负责帮用户查询域名结果，本质上是递归 DNS。

权威 DNS 是域名解析记录真正存放的地方。你在 DNSPod、Cloudflare、阿里云 DNS、Route 53 里添加 A 记录、CNAME 记录，这些平台提供的就是权威 DNS 服务。

自建 DNS 时也要分清角色。内网里搭一个 Bind、CoreDNS、PowerDNS 给员工电脑或服务器查询，这是递归 DNS 或内网 DNS。对公网提供 example.com 的权威解析，那就是权威 DNS，安全策略完全不一样。

Linux服务器怎么配置DNS解析

临时查看当前DNS

在 Linux 上排查 DNS，常用命令是 cat /etc/resolv.conf。里面一般会看到 nameserver 这种配置。

例如：

nameserver 1.1.1.1
nameserver 8.8.8.8

这表示当前机器查询域名时，会优先问 1.1.1.1，再问 8.8.8.8。注意很多系统里的 /etc/resolv.conf 不是手工维护的，而是 NetworkManager、systemd-resolved、DHCP Client 自动生成的。直接改文件，重启网络后可能被覆盖。

Ubuntu配置DNS

Ubuntu 18.04 之后常见的是 netplan。配置文件一般在 /etc/netplan/ 下面，比如 00-installer-config.yaml。

示例配置：

network:
  version: 2
  ethernets:
    ens33:
      dhcp4: no
      addresses:
        - 192.168.1.10/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

保存后执行：

netplan apply

如果是远程服务器，改网络配置前建议开一个 tmux 或 screen，会话断了还能恢复。云服务器上还要注意网卡名，不一定叫 eth0，可能是 ens3、ens5、enp1s0。

CentOS配置DNS

CentOS 7 常见配置在 /etc/sysconfig/network-scripts/ifcfg-eth0 或对应网卡文件里。

示例：

BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.1.10
PREFIX=24
GATEWAY=192.168.1.1
DNS1=1.1.1.1
DNS2=8.8.8.8

修改后可以重启网络：

systemctl restart network

CentOS 8、Rocky Linux、AlmaLinux 很多环境使用 NetworkManager，可以用 nmcli 配置：

nmcli con show
nmcli con mod "System eth0" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "System eth0"

这里最容易出问题的是连接名不对。先用 nmcli con show 看真实名称，不要照抄。

Windows服务器怎么配置DNS

Windows Server 上配置 DNS 比较直观。进入网络适配器属性，找到 IPv4，手动填写 Preferred DNS server 和 Alternate DNS server。

如果是批量服务器，可以用 PowerShell：

Get-NetAdapter

查看网卡名称后配置：

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","8.8.8.8")

查看配置：

Get-DnsClientServerAddress

Windows 上还有一个常用命令是清 DNS 缓存：

ipconfig /flushdns

遇到“DNS 已经改了，但这台 Windows 机器就是访问旧 IP”的情况，先 flushdns，再检查浏览器缓存和应用自身缓存。

怎么配置域名解析到云服务器

拿到服务器公网IP

域名解析到云服务器，本质上就是把 A 记录指向服务器公网 IP。购买云服务器后，控制台里会有公网 IPv4 地址。比如你的服务器 IP 是 198.51.100.20，就可以把 www.example.com 的 A 记录指向这个 IP。

如果业务面向海外用户，服务器线路会影响访问体验。比如美国节点，如果走普通国际线路，国内用户可能出现高延迟和丢包；如果是三网精品、CN2、GIA 或优化线路，体验会稳定很多。需要美国大带宽、海外电商、游戏或 Tiktok 相关业务时，可以看看129云的美国精品大宽带和美国双ISP产品，客服热线 400-9177118 可以直接确认线路、带宽、IP 类型和防御策略。

添加A记录

在域名 DNS 控制台添加记录时，常见字段如下：

主机记录：www
记录类型：A
记录值：198.51.100.20
TTL：600

如果要让根域名 example.com 也能访问，主机记录通常填 @，记录值还是服务器 IP。

主机记录填什么，最终访问的域名就是什么。填 www，就是 www.example.com；填 api，就是 api.example.com；填 @，就是 example.com。

Web服务也要绑定域名

DNS 只负责把域名指到 IP，不负责让 Nginx、Apache、IIS 自动识别这个域名。服务器上还要配置站点绑定。

Nginx 示例：

server {
  listen 80;
  server_name example.com www.example.com;
  root /data/www/example;
  index index.html index.php;
}

如果 DNS 配好了，但访问显示默认页、其他站点内容、404，通常是 Web Server 的 server_name 或站点绑定没配对。

TTL怎么设置更合适

TTL 是 DNS 缓存时间，单位是秒。TTL 越大，递归 DNS 缓存越久，查询压力越小，但切换 IP 生效越慢。TTL 越小，切换更灵活，但查询次数会上升。

常见设置可以按场景来：

普通官网：TTL 600 到 3600 秒都可以。访问量不大，变更不频繁，没必要压太低。

上线迁移：提前一天把 TTL 从 3600 或 86400 降到 300 或 600，等老缓存过期后再切 IP。很多人迁移当天才改 TTL，这个动作意义就小了，因为之前的长缓存还在外面。

高可用切换：如果依赖 DNS 做灾备切换，TTL 可以设 60 到 300 秒。但要知道，DNS 不是实时流量调度系统，有些递归 DNS 不完全按你的 TTL 来。

CDN 或高防 CNAME：一般按服务商建议设置。很多服务商会让你 CNAME 到指定域名，后面调度由他们处理，你只要保证 CNAME 正确。

dig和nslookup怎么查DNS

dig查权威结果

Linux 排查 DNS 推荐用 dig。比如查询 A 记录：

dig www.example.com A

指定公共 DNS 查询：

dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A

查询 NS：

dig example.com NS

追踪完整解析链路：

dig +trace www.example.com

实际排障时，dig @不同 DNS 很有用。比如 @1.1.1.1 返回新 IP，@114.114.114.114 返回老 IP，说明不是权威 DNS 没改，而是递归 DNS 缓存或线路解析差异。

nslookup查客户端视角

Windows 上常用 nslookup：

nslookup www.example.com

指定 DNS：

nslookup www.example.com 8.8.8.8

查 MX：

nslookup -type=mx example.com

nslookup 更适合快速看当前机器能解析到什么。要看更细的 TTL、权威链路，dig 更顺手。

自建DNS服务器怎么配置

什么时候需要自建DNS

不是所有业务都需要自建 DNS。普通网站、API、企业邮箱，直接用成熟的权威 DNS 服务就行。自建 DNS 更多出现在内网域名、私有云、Kubernetes、企业办公网络、IDC 机房、专线环境里。

比如内网有很多服务：git.internal、jenkins.internal、mysql-prod.internal。如果全写 hosts，机器一多就崩。这个时候自建一个内网 DNS，统一维护解析，会舒服很多。

用Bind搭一个内网DNS

以 Ubuntu 为例，安装 Bind9：

apt update
apt install bind9 bind9utils -y

主配置一般在 /etc/bind/named.conf.options。可以配置允许内网网段查询：

options {
  directory "/var/cache/bind";
  recursion yes;
  allow-query { 192.168.0.0/16; 10.0.0.0/8; };
  forwarders {
    1.1.1.1;
    8.8.8.8;
  };
  dnssec-validation auto;
};

然后定义一个内网 Zone，比如 internal.local：

zone "internal.local" {
  type master;
  file "/etc/bind/db.internal.local";
};

创建 /etc/bind/db.internal.local：

$TTL 600
@ IN SOA ns1.internal.local. admin.internal.local. (
  2025010101
  3600
  1800
  604800
  600 )
@ IN NS ns1.internal.local.
ns1 IN A 192.168.1.10
git IN A 192.168.1.20
jenkins IN A 192.168.1.21
mysql-prod IN A 192.168.1.30

检查配置：

named-checkconf
named-checkzone internal.local /etc/bind/db.internal.local

重启服务：

systemctl restart bind9
systemctl enable bind9

客户端 DNS 指向 192.168.1.10 后，就可以解析 git.internal.local、jenkins.internal.local 这些内部域名。

Bind配置里容易忽略的安全问题

不要把递归 DNS 开放给公网。开放递归 DNS 很容易被拿去做 DNS Amplification，形成 DDoS 放大攻击。公网扫描器会持续扫 53 端口，一旦发现开放递归，就可能被滥用。

如果是内网递归 DNS，allow-query、allow-recursion 要限制内网网段。防火墙也要限制 UDP 53 和 TCP 53 的来源。

很多人只放 UDP 53，忘了 TCP 53。DNS 正常查询主要用 UDP，但大响应、Zone Transfer、部分 DNSSEC 场景会用 TCP。内网可以按需放行，公网权威 DNS 要正确处理 TCP 53。

DNS和CDN、高防、负载均衡的关系

DNS 是入口，CDN、高防、Load Balancer 是后面的流量承接层。

接 CDN 时，常见做法是 www.example.com CNAME 到 CDN 分配的域名。用户访问 www.example.com，DNS 返回 CDN 节点 IP，静态资源或动态加速流量先到 CDN。

接高防时，域名通常 CNAME 到高防服务商给的接入域名，或者 A 到高防 IP。攻击流量先打到高防节点，清洗后再回源到真实服务器。真实源站 IP 不要暴露，不然攻击者绕过高防直接打源站，高防就没意义。

接负载均衡时，域名 A 或 CNAME 到 Load Balancer。后端多台云服务器由负载均衡分发。比起 DNS 轮询，Load Balancer 能做健康检查、会话保持、四层或七层转发，故障摘除更可靠。

DNS轮询能不能做负载均衡

DNS 轮询就是一个域名返回多个 A 记录，比如：

www.example.com A 198.51.100.10
www.example.com A 198.51.100.11
www.example.com A 198.51.100.12

递归 DNS 或客户端可能会轮着使用这些 IP，看起来像负载均衡。但它的问题也很明显：没有可靠健康检查，某台服务器挂了，DNS 仍可能返回它；客户端缓存不可控；不同运营商递归 DNS 行为不一致。

小流量、内部服务、临时分摊访问可以用 DNS 轮询。对外生产业务，尤其是支付、登录、游戏网关、API 服务，还是建议用 Load Balancer 或应用层网关。

DNS解析慢和访问慢不是一回事

排查访问慢时，要区分 DNS 解析耗时和 TCP/HTTPS/应用响应耗时。

DNS 慢通常表现为第一次打开卡住，后续访问正常。可以用 curl 看耗时：

curl -o /dev/null -s -w "namelookup:%{time_namelookup} connect:%{time_connect} starttransfer:%{time_starttransfer} total:%{time_total}\n" https://www.example.com

如果 time_namelookup 很高，比如 1 秒以上，就要查本机 DNS、递归 DNS、网络到 DNS 的延迟。如果 namelookup 很低，但 connect 或 starttransfer 高，那问题更可能在网络链路、服务器负载、TLS 握手、后端应用。

海外服务器场景里，经常看到 DNS 很快，真正慢的是跨境链路。比如国内访问美国普通线路，晚高峰丢包和抖动明显；同样的站点换到三网精品、CN2 GIA 或更适合目标用户区域的节点，体验会差很多。选择服务器时不要只看 CPU、内存，线路质量、带宽峰值、防御能力也要一起看。

域名迁移时DNS怎么操作比较稳

迁移域名解析平台或服务器 IP，比较稳的做法是提前准备。

如果只是换服务器 IP，可以提前把 TTL 降到 300 或 600，等原 TTL 周期过去后，再修改 A 记录到新 IP。新旧服务器最好并行一段时间，避免部分用户还访问老 IP 时业务已经停掉。

如果是换 NS，也就是把域名从一个 DNS 服务商迁到另一个 DNS 服务商，要先在新平台完整导入记录。A、CNAME、MX、TXT、CAA、SRV 都要核对，尤其企业邮箱相关记录不能漏。

切 NS 后，用 dig 查：

dig example.com NS
dig @新NS服务器 www.example.com A
dig @旧NS服务器 www.example.com A

NS 切换全球生效期间，新旧权威 DNS 可能同时被查询。所以新旧两边记录最好保持一致一段时间，不要刚切完就删除旧平台记录。

DNS配置常见故障排查

域名解析到了旧IP

先查权威 DNS 是否已经返回新 IP，再查不同递归 DNS 的结果。

dig @权威NS www.example.com A
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A
dig @114.114.114.114 www.example.com A

权威是新的，递归是旧的，大概率是缓存。权威还是旧的，说明 DNS 控制台没改对、改错线路、改错域名，或者当前域名 NS 根本不在这个平台。

只有部分地区打不开

这种情况要查智能解析、线路解析、CDN 调度和运营商 DNS。比如默认线路有记录，电信线路没记录，电信用户就可能解析失败。或者海外线路返回了一个国内无法访问的 IP。

可以用多个地区探测工具查解析结果，也可以找不同网络环境执行 nslookup。不要只在办公室 Wi-Fi 下测一次就下结论。

HTTPS证书签发失败

如果是 DNS-01 验证，重点查 TXT 记录。证书机构要求的主机记录和值必须完全一致。

比如要求添加：

_acme-challenge.example.com TXT xxxxx

有些 DNS 控制台主机记录只需要填 _acme-challenge，不要把完整域名又填一遍，否则会变成 _acme-challenge.example.com.example.com。

邮箱收不到邮件

查 MX 记录、SPF、DKIM、DMARC。MX 决定邮件投递到哪里，SPF 和 DKIM 影响可信度，DMARC 决定校验失败后的策略。

企业邮箱迁移时，不要只改 MX。旧 SPF 没清理、新 SPF 没加全，经常导致发信被判垃圾邮件。多个 SPF 记录也不行，应该合并成一条 TXT。

选择DNS服务时看什么

生产环境不建议把域名解析放在很弱的小面板里。DNS 出问题，业务入口直接没了。选择 DNS 服务时，重点看稳定性、节点覆盖、解析线路、API 能力、DDoS 防护、变更审计和故障历史。

如果业务在海外，DNS 解析平台还要看全球节点质量。只面向国内用户和面向北美、东南亚、欧洲用户，解析调度策略不一样。游戏业务还要关注延迟波动，电商业务关注支付和登录链路稳定，内容业务关注 CDN 配合。

服务器侧也一样。比如美国精品大宽带-C型这种 8C、8G DDR4 ECC、120G SSD、1Gbps 峰值、2.5TB 流量的配置，适合中小型站点、下载分发、轻量海外业务。美国精品大宽带-D型提供 8C、16G DDR4 ECC、160G SSD、1Gbps 峰值、3TB 流量，更适合访问量更高的业务。美国双ISP-C型带 70Mbps 峰值、双 ISP，更偏 Tiktok、亚马逊、电商、游戏这类需要特定网络环境的场景。相关产品可以在129云按业务区域和线路要求筛选。

DNS配置不要只看面板显示

DNS 面板显示“已生效”，只能说明平台配置写入成功，不代表全球递归 DNS 都已经拿到新结果。上线、迁移、故障处理时，还是要用 dig、nslookup 从多个 DNS 源确认。

比较稳的检查方式是：查权威 NS、查公共递归 DNS、查业务服务器日志、查客户端访问 IP。DNS 层返回什么，Nginx Access Log 里实际进来的 Host 和源 IP 是什么，两边对起来，问题会清楚很多。

如果 DNS 已经解析到新服务器，但服务器日志完全没有请求，继续查安全组、防火墙、端口监听、Web Server 绑定、CDN 回源配置。DNS 只是入口解析，不会替你打开 80、443，也不会替你配置反向代理。

实际配置时的一段常用流程

新业务上线时，可以按这个顺序处理：先确认服务器公网 IP 和线路，再配置安全组开放 80、443 或业务端口，然后部署 Web Server，再添加 DNS A 记录或 CNAME，接着用 dig 查解析结果，最后用 curl 指定 Host 测访问。

curl 指定 Host 很适合在 DNS 切换前验证新服务器：

curl -H "Host: www.example.com" http://198.51.100.20/

如果是 HTTPS，还要考虑证书和 SNI，可以用：

curl --resolve www.example.com:443:198.51.100.20 https://www.example.com/

这条命令会绕过当前 DNS，把 www.example.com 临时解析到指定 IP，用来验证新站点非常方便。DNS 切换前先这样测一遍，能提前发现证书不匹配、站点绑定错误、反代配置错误这些问题。

DNS服务器配置里比较容易踩的坑

根域名和 www 不是一回事。example.com 能访问，不代表 www.example.com 能访问；反过来也一样。两个都要访问，就两边都配解析，Web Server 也要绑定两个域名。

CNAME 和其他记录冲突。一个主机记录如果配置了 CNAME，一般不能再同时配置 A、MX、TXT。比如 www 配了 CNAME，就不要再给 www 配 A。

TTL 太长影响迁移。很多老域名 TTL 设置 86400，也就是一天。临时迁移才发现解析迟迟不变，业务窗口被拖长。

内网 DNS 和公网 DNS 返回不一致。公司内网可能有 Split DNS，内网解析到私有 IP，公网解析到公网 IP。排查时要明确自己在哪个网络环境下查询。

自建 DNS 忘了防火墙。Bind 配好了，但 UDP 53 没放行，客户端就是查不到。或者只放了安全组，系统里的 firewalld、iptables 还拦着。

NS 改错平台。域名注册商处 NS 指向 A 平台，但你在 B 平台改记录，怎么改都不会生效。遇到这种情况，先 dig domain NS，看当前权威 DNS 到底是谁。

DNSSEC 配置不完整。开启 DNSSEC 后，如果 DS 记录和 DNSKEY 对不上，可能导致支持 DNSSEC 校验的递归 DNS 解析失败。不了解 DNSSEC 时，不要在生产域名上随手开关。

一条记录从配置到访问生效要看四层

第一层是注册商 NS。确认域名当前 NS 指向哪里。

第二层是权威 DNS。确认 A、CNAME、MX、TXT 等记录在权威 DNS 上返回正确。

第三层是递归 DNS。确认用户实际使用的 DNS 有没有拿到新结果。

第四层是客户端和应用。确认本地缓存、浏览器缓存、App 缓存、系统 hosts 没有干扰。

排障时不要一上来就反复改记录。DNS 改来改去会引入更多变量。先查当前链路，确认问题卡在哪一层，再动配置。