自建DNS服务器全攻略：从解析原理到安全加固实践

1. 自建DNS前必须搞懂的解析原理和角色定位

先说一个很多人的误区。绝大多数人用了十几年网络，对DNS的认识却停留在“路由器里填一个114.114.114.114或者8.8.8.8”这个层面。一旦遇到网站打不开、域名解析到错误IP、内网设备找不到服务端这类问题，就只会重启路由器、换DNS。直到你真正动手搭建过一台DNS域名解析服务器，才会明白解析链路里每一个环节都在干什么，出了问题能往哪个方向追。

把DNS拆开看，本质就一句话：把人类好记的域名，翻译成网络设备能用的IP地址。打个比方，域名是门牌号“幸福路88号”，IP是经纬度坐标，DNS就是一本自动更新的城市黄页。你输入的是门牌号，系统通过DNS查到经纬度，才能把你送到目的地。这个过程看起来简单，但里面有两个关键角色经常被搞混：

• 递归解析器（Recursive Resolver）：替终端用户跑腿的角色。你给它一个域名，它一层一层向上游查询，直到拿到最终IP再返回给你。你电脑里配置的DNS地址，配置的就是这个递归解析器。
• 权威服务器（Authoritative Server）：真正掌握某个域名最终答案的角色。比如.com顶级域会把example.com的NS记录指向某一组服务器，这组服务器就是example.com的权威来源，它说了算。

这里引出自建DNS的第一个价值判断：绝大多数人需要的，是自建一个私有递归解析器，为内网提供缓存和转发能力；少数人有托管业务域名需求，才需要自建权威DNS。两种角色的配置文件、优化方向完全不一样，千万别买错药。我在实际项目里见过有人折腾了好几天，用Bind9搭了一个权威服务器，结果只想给办公室局域网做域名缓存，方向从一开始就反了。

还需要理解一个概念：递归迭代与缓存TTL。递归解析器拿到域名后，会先问根服务器，根服务器说“你去问.com的服务器”，再问.com，.com说“去问example.com的权威服务器”，最后权威服务器返回真正的A记录。整个过程是迭代多轮的，所以解析器会把结果连同TTL（Time To Live，生存时间）一起缓存下来，TTL内再遇到同样的查询就直接返回缓存，不再上游查询。自建DNS最大的立竿见影收益，就在这里——只要你局域网里有人问过某个域名，其他人在TTL内再访问，就完全不卡了。

关于公共DNS的选择，我习惯先看网络归属地，再谈“谁最快”。目前国内常用的几个公共DNS，各有侧重：

自建DNS定位清晰后，下面每一步都有明确目标：内网缓存加速、统一管理、故障可查、按需过滤。带着这个认知去动手，你会少走很多弯路。

2. 从一次抓包看懂DNS完整解析链路

很多人理解DNS，看再多文章都不如自己抓一次包。DNS是明文协议，非常适合用来做第一次网络协议分析。我建议你打开Wireshark，然后执行一条dig命令，整个过程一目了然。

先看主动查询的工具。Linux和macOS下用dig最顺手，Windows下可以用nslookup，也可以安装Wireshark自带的工具。我们以dig @223.5.5.5 www.example.com A为例，这条命令的意思是：向阿里公共DNS查询www.example.com的A记录。加+trace参数可以看到完整迭代链：

bash复制dig @223.5.5.5 www.example.com A +trace

实际输出里，你会依次看到根服务器返回的.com NS记录，然后.com返回example.com的NS记录，最后权威服务器返回真正的A记录和TTL。这就是我在第1章说的迭代查询路径，纸上谈兵一百遍，不如自己跑一遍。

接着用Wireshark抓包看报文结构。先打开Wireshark，选择当前上网的网卡，设置过滤条件为dns || port 53，然后重新执行上面的dig命令。抓到的DNS响应报文里，你需要关注这几个区域：

• Transaction ID（事务ID）：一个16位标识符，请求和响应的ID一致。这是DNS安全机制里最基础的校验点，也是DNS欺骗攻击的重点攻击对象。
• Queries（查询区）：包含你查询的域名、类型（A、AAAA、MX等）、类别（通常为IN）。
• Answers（应答区）：返回的解析结果，里面能看到A记录、TTL、以及权威服务器信息。
• Additional（附加区）：dig +trace时的附加信息，常见的是NS的IP地址，避免额外再查一次。

关于通过IP反查域名记录，这也是Wireshark的一个高频用法。热搜词里有人问“wireshark根据ip反查询域名解析记录”，实操方法有两个。一个是直接查PTR记录：

bash复制dig -x 93.184.216.34

-x参数会发起PTR记录查询，返回这个IP上绑定的域名信息。另一个是用Wireshark的DNS统计视图，在菜单栏打开Statistics -> DNS，能看到抓包时间范围内所有DNS查询名和响应情况。如果只想快速定位某个IP对应哪些域名，可以在过滤栏输入dns.a == 93.184.216.34，它会列出所有包含该IP的DNS响应报文。这在排查域名被解析到哪个IP、某个IP被哪些域名共用的时候非常管用。

抓几次包之后，你需要建立一种敏感度：DNS报文明文可见，意味着内网任何一台设备都能看到你访问了哪些域名，运营商或路由器管理员同样能看到。更隐蔽的是，如果局域网内有设备伪造DNS响应，用户几乎无感知。这个风险我会在第6章专门讲怎么检测和加固。

3. 轻量起步：用dnsmasq在10分钟内跑起第一台DNS服务器

自建DNS解析服务器，软件选型决定了你后续的上限。如果你从Bind9（目前最主流的DNS软件）起步，配置复杂度和学习曲线会劝退很多人。我推荐内网场景从dnsmasq入手，它是轻量级DNS转发器和DHCP服务端，与Linux系统集成好，配置文件逻辑简单，能覆盖70%以上的内网DNS需求。等遇到更复杂的视图、策略、DNSSEC完整场景，再迁移到Bind9不迟。

我常用的选型对照表，你可以按需求对号入座：

我的建议很直接：临时用、内网规模几十台设备，dnsmasq足够；要做正经公网解析或复杂的策略分流，直接上Bind9。接下来以Ubuntu 22.04为例，完整演示dnsmasq搭建过程。

安装就是一行的活：

bash复制sudo apt update
sudo apt install -y dnsmasq

安装完成后，先别急着改配置，systemctl status dnsmasq看一眼默认状态，然后备份原始配置：

bash复制sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak

编辑/etc/dnsmasq.conf，我的最小可用配置是这样：

ini复制# 监听本机及内网网卡，不要监听公网网卡
interface=eth0
bind-interfaces

# 设定上游DNS服务器，多个会轮询
server=223.5.5.5
server=119.29.29.29

# 缓存条数，默认150条太少了，内网场景加大
cache-size=1000

# 开启日志，排错必需
log-queries
log-facility=/var/log/dnsmasq.log

# 内网域名解析，把 *.lan 解析到 192.168.1.100
address=/lan/192.168.1.100

# 不允许从上游读取 /etc/resolv.conf 中的服务器
no-resolv

然后测试配置并重启服务：

bash复制sudo dnsmasq --test
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq

验证是否工作，从另一台内网机器执行：

bash复制dig @192.168.1.100 www.baidu.com
dig @192.168.1.100 test.lan

第一条应该返回百度的真实IP；第二条应该直接返回192.168.1.100，而且响应时间几乎为0，因为走的是本地静态解析。这就是自建DNS第一个可见成果：内网设备可以通过一个统一的域名访问服务器，再也不用记IP。

这里有几个坑提前说一下。第一，interface=eth0要写对网卡名，用ip addr确认，写错了服务会起不来。第二，bind-interfaces这个参数很关键，它让dnsmasq只绑定指定接口，避免在公网网卡上暴露出一个毫无防护的DNS服务，变成内网攻击跳板。第三，no-resolv会忽略系统的/etc/resolv.conf，这样上游源只剩你配置的server=条目，行为可控。我遇到过不少线上事故，就是没加no-resolv，结果dnsmasq把系统网络自带的DNS也一起用了，解析结果时好时坏。

客户端接入方式，通常有两种。一种是在路由器LAN口的DHCP设置里，把首选DNS服务器填成dnsmasq所在机器的IP，所有自动获取地址的设备一次性生效。另一种是手工改单台设备的DNS：Windows在“网络适配器选项-属性-Internet协议版本4”里设置，Linux改/etc/resolv.conf或者用nmcli，macOS在系统设置里的网络面板改。我建议内网统一走DHCP下发，省心且不易遗漏。

4. 真实需求驱动：加速解析、内网域名、域名屏蔽的完整配置

dnsmasq跑起来只是第一步，真正有价值的是把它用在实际需求上。本章把几个高频场景拆开讲，每个都有完整配置和验证方法。

4.1 缓存策略与TTL调优，让重复访问更快

自建DNS最直接的收益就是缓存。默认cache-size只有150条，对多人办公网来说明显不够。我会同时调大缓存，并把一部分稳定性域名的TTL强制拉长。dnsmasq在2.86版本后支持min-cache-ttl参数，可以指定缓存的最短TTL下限：

ini复制# 缓存10000条，适合常规办公网
cache-size=10000

# 强制缓存至少3600秒，避免频繁上游查询
min-cache-ttl=3600

min-cache-ttl的意义在于，有些域名的权威服务器把TTL设得很短（比如30秒），用于负载均衡调度。但在内网场景我们并不需要这么高的实时性，强制拉长TTL可以显著降低上游查询次数，也降低公网DNS被刷爆的风险。注意，如果你的业务依赖域名解析的秒级变更，不要开这个参数。

调优后怎么验证效果？看日志最直观：

bash复制tail -f /var/log/dnsmasq.log

日志里会显示每条查询是cached还是forwarded。假设访问一次www.aliyun.com，第一次显示forwarded to 223.5.5.5，第二次再访问同一个域名，日志变成cached，且响应时间明显下降。这就是缓存命中该有的样子。

4.2 内网域名自动解析，告别记IP

内网服务器多起来之后，记IP是完全不现实的。我在一个办公室里维护过十多个内网服务，用dnsmasq把每个服务都映射成有意义的域名，维护效率提升非常明显。

为单个域名指定IP：

ini复制address=/jenkins.lan/192.168.1.10
address=/wiki.lan/192.168.1.11
address=/nas.lan/192.168.1.12

还有一种更系统的方式，针对整个域名段做通配解析。比如把*.dev.lan都解析到开发服务器：

ini复制address=/dev.lan/192.168.1.20

这样api.dev.lan、frontend.dev.lan都会解析到192.168.1.20，后端服务可以通过子域名区分用途。我还会用local=/lan/声明哪些域名属于本地域，不会转发到公网，避免内网域名泄漏给上游DNS。

内网域名的排错，有一个容易被忽略的细节：如果内网DNS解析了某个域名，但这个域名在公网DNS也存在，内网解析结果必须优于公网结果，否则一旦DNS失效，设备会默默切换到公共DNS，解析到公网IP，导致服务地址变化。所以dnsmasq配置完成后，我建议在客户端用dig验证一下，确认返回的是内网IP再继续用。

4.3 用自建DNS“优化”特定域名的解析结果

热搜词里“自建dns加速github”是很多人都想搞明白的。这里我不展开任何敏感内容，只讲一个正常无害的常规优化手段：GitHub在国内部分网络下解析到的IP，可能不是最优节点，导致访问很慢。用自建DNS对比几个公共DNS的解析结果，选择响应更好的一条记录，固定到本地解析即可。

操作步骤如下：

1. 分别用多个公共DNS查询目标域名：

bash复制dig +short @223.5.5.5 github.com
dig +short @119.29.29.29 github.com
dig +short @8.8.8.8 github.com

2. 记录每个DNS返回的IP列表，在本地网络环境测试哪个IP的延迟和丢包率表现最好：

bash复制for ip in $(dig +short @223.5.5.5 github.com); do
    ping -c 4 $ip
done

3. 选定一个可用的IP，写入dnsmasq配置：

ini复制address=/github.com/140.82.112.3

这样只影响内网的GitHub解析，不会影响其他域名。注意，这种固定IP的方式有风险：目标服务的IP变更后会失效。所以我通常只在明确某个IP是稳定节点时才会这么做，并且时刻保留一份备份配置。

4.4 屏蔽指定域名，广告与恶意站点拦截

自建DNS另一个实用价值是域名过滤。最简单的做法是把要屏蔽的域名指向一个黑洞IP：

ini复制address=/ads.example.com/0.0.0.0
address=/tracker.example.com/0.0.0.0

需要批量屏蔽时，用addn-hosts配合一个专门的hosts文件更好管理：

ini复制addn-hosts=/etc/dnsmasq.blocklist

然后在/etc/dnsmasq.blocklist里维护：

text复制0.0.0.0 badsite1.com
0.0.0.0 badsite2.com
0.0.0.0 *.spam-domain.com

更进阶的企业级做法是用Bind9的Response Policy Zone（RPZ）。它允许你定义策略，对命中的域名返回NXDOMAIN、修改解析结果，或者转发到特定服务器。如果你管理的设备超过50台，对DNS管控有合规要求，建议直接迁移到Bind9。我在第6章会再展开与DNS安全相关的话题。

5. 高频故障的完整排查链路：从530 origin dns error到Linux重启还原DNS

自建DNS不可能不出问题，出现问题不可怕，可怕的是没有排查思路。这一章我把两类最高频的疑难问题完整展开：一类是应用层面的“530 origin dns error”，一类是系统层面的“Linux修改DNS后重启网络被还原”。

5.1 530 origin dns error：源站DNS配置与CDN托管不一致

“530 origin dns error”通常出现在使用Cloudflare等CDN服务时，源站回源阶段报出的错误。从报错字面看，是源站DNS解析失败。我遇到过一个具体案例：某客户的业务托管在Cloudflare上，源站服务器指向第三方云厂商的域名。某天突然大面积报530，排查链路如下：

第一步，先用dig确认源站DNS本身是否正常：

bash复制dig @223.5.5.5 origin.example.com A

如果这条命令返回不了A记录，说明是权威解析出了问题，需要检查DNS托管商的控制台记录是否还在。如果这一步有返回，继续第二步。

第二步，确认NS记录是否正确。Cloudflare解析一个域名时，会检查这个域名的NS记录是否指向Cloudflare分配的NS服务器：

bash复制dig example.com NS

返回结果里NS记录如果指向了别家，比如阿里云解析的NS，而你的域名实际上是在Cloudflare控制台添加的，两个体系就不匹配，CDN无法确定源站位置，就会报530。这种错位常见于域名刚转移、DNS托管切换没完成时。

第三步，直接向Cloudflare分配给你的NS服务器查源站记录：

bash复制dig @dns.ns.cloudflare.com origin.example.com A

如果这个权威查询能返回，但公共递归DNS查不到，说明记录传播或代理设置有问题；如果权威查询本身就空，那问题基本锁定在Cloudflare控制台的DNS记录配置上：源站域名的记录没有创建，或者代理状态设成了“仅DNS”但源站指向了不存在的内网域名。

最后别忘了看TTL。如果权威服务器返回结果正常，但递归解析器缓存了错误的旧值，也会导致客户端读到错误IP。排查时可以临时指定一个从未用过的新公共DNS来查询，排除本地缓存干扰：

bash复制dig @1.1.1.1 origin.example.com A

530问题排查的核心心法就是：逐层验证权威链路，而不是盲目刷新CDN缓存。只要NS记录、源站记录、代理开关三项对齐，绝大多数530都会消失。

5.2 Linux修改DNS后重启被还原：NetworkManager的机制与正确改法

这是Linux新手到老手都会踩的坑。你手动改了/etc/resolv.conf，一切正常，结果一重启网络，或者重启机器，DNS又回到原来的配置。原因很简单：现代Linux发行版里，/etc/resolv.conf通常是符号链接，由NetworkManager或systemd-resolved动态生成，你直接改它，等于改了临时文件，随时会被覆盖。

先看看当前/etc/resolv.conf指向谁：

bash复制ls -l /etc/resolv.conf

输出如果是/run/systemd/resolve/stub-resolv.conf或/run/NetworkManager/resolv.conf，就说明DNS被系统服务托管了。这时候有两种正规改法：

方法一，用NetworkManager修改连接配置，这也是一劳永逸的推荐方式：

bash复制nmcli con show
nmcli con mod "Wired connection 1" ipv4.dns "192.168.1.100 223.5.5.5"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

ipv4.ignore-auto-dns yes是关键，它会让NetworkManager忽略DHCP下发的DNS，只用你手动指定的地址。重启后依然生效。

方法二，如果你希望完全禁用systemd-resolved，让dnsmasq来接管53端口监听，需要先停掉systemd-resolved的服务，再手动维护resolv.conf：

bash复制sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

这里有个细节，如果你本机就运行了dnsmasq，nameserver 127.0.0.1指向本机是合理的；如果你只是想让系统直接使用局域网内另一台DNS服务器，就填那台服务器的IP。

如果你不想改动NetworkManager策略，也不想停systemd-resolved，只是想临时测试某个DNS的效果，可以在执行命令时临时指定，不落盘：

bash复制# 临时使用指定DNS解析某个域名
dig @192.168.1.100 www.example.com

# 临时修改当前shell的DNS解析
echo "nameserver 192.168.1.100" | sudo tee /etc/resolv.conf

这类临时改法重启后自动还原，适合测试，不适合生产。搜索词里“linux修改dns后重启网络+还原”说明遇到这个坑的人非常多，核心一句话：别直接改resolv.conf，去改你的DNS管理组件配置。

5.3 浏览器拦截内网DNS解析页面的新问题

还有一个近期常见的排查点：“此连接已被阻止，因为它是公共页面发起的，旨在连接到您本地网络上的设备或服务器。”这是浏览器新的Private Network Access安全策略提示。它和DNS本身不一定直接相关，但如果你自建DNS解析了某个域名到192.168.1.x，而你在公网页面上嵌入了指向内网地址的资源，现代浏览器会拦截这个请求。

排查思路：确认被拦截的域名解析结果是不是内网IP；确认页面是否通过HTTPS加载，以及目标内网服务是否正确配置了CORS。如果确实是业务需要，可以在内网服务端允许该来源的跨域访问，或者在浏览器侧关闭该站点的安全限制（仅限开发调试）。部署到生产环境后，仍需走正式的安全策略。

5.4 高频问题速查表

6. 防止DNS劫持：检测手段与加固实践

DNS劫持是内网安全最难防的一类攻击，因为用户无感知。所谓DNS劫持，就是DNS解析过程被第三方篡改，把原本该访问的域名解析到攻击者控制的IP上。网上有大量案例：某局域网用户访问网银页面，结果地址栏域名没变，打开的却是钓鱼页面，输完账号密码钱就没了。这就是典型的DNS劫持。

6.1 先判断自己是不是已经被劫持

一个很基础但很有效的检测方法：用多个独立渠道解析同一个域名，然后对比结果。如果你局域网内的DNS解析结果和公共DNS返回的结果不一致，基本可以断定解析被拦截或篡改了。

bash复制# 使用本机配置的DNS查询
dig www.baidu.com

# 使用信任的公共DNS查询
dig @223.5.5.5 www.baidu.com
dig @119.29.29.29 www.baidu.com

如果第一个结果和后面两个结果不一样，特别是返回了陌生IP，优先级从高到低排查：

1. 本机hosts文件有没有被写入异常条目；
2. 电脑的DNS设置有没被改成非预期地址；
3. 路由器WAN口或DHCP配置的DNS是否被改；
4. 路由器的DNS代理功能是否开启，且指向了不可信地址；
5. 局域网上是否有设备在运行伪造DNS响应。

通过抓包可以发现最后一条。用Wireshark过滤dns.flags.response == 1，看同一事务ID是否有两个不同来源的响应包。正常情况只有一个响应；如果出现两个，其中很可能有一个是伪响应。另外，端口53的UDP流量可以伪造，如果业务对解析安全要求高，可以使用DNS over TLS（DoT）或者DNS over HTTPS（DoH）来规避明文污染。dnsmasq本身不支持DoH，需要加一层dnsdist或使用dnscrypt-proxy这类工具转发到加密DNS上游。

6.2 DNS加固实践：从TTL、DNSSEC到日志审计

自建DNS服务器本身的加固，我总结为四个字：少露、多查、加密、验证。

少露——DNS服务只监听内网接口，千万不要暴露到公网。我在配置里强调的bind-interfaces就是这个目的。公网暴露的DNS解析器不仅会被人利用做放大攻击，还会被扫描器盯上变成待宰目标。

多查——开启查询日志，定期检查异常域名。dnsmasq的log-queries可以记录每个域名查询，把日志接入到Elasticsearch或者直接写个脚本，定期统计查询量异常大的域名。内网突然出现大量对陌生域名的解析请求，很可能是挖矿木马或者间谍软件在回连C2服务器。

加密——如果使用DoH/DoT，运营商层面的DNS劫持会被直接跳过。但要注意，内网的终端要支持DoH配置，否则还是要先把明文DNS流量导到内网DNS服务器，再由它加密上游转发，这个模式下内网DNS服务器就是唯一的明文入口，做好保护即可。

验证——DNSSEC可以防止伪造应答和缓存投毒。dnsmasq支持DNSSEC验证，但功能相对有限；要严格验证建议直接上Bind9。Bind9上启用DNSSEC比较直接：

bind复制options {
    dnssec-validation auto;
    dnssec-enable yes;
};

开启后，dig查询结果末尾会多一个status: NOERROR和flags: qr rd ra ad，其中的ad字段是Authenticated Data，表示结果通过了DNSSEC验证。如果看到servfail或status: SERVFAIL，说明该域名的DNSSEC链路有问题，查询可能被伪造或权威配置错误。

6.3 我的日常安全巡检清单

最后分享一套我每天都在用的巡检方式，很轻量，但管用。以下命令可以写成脚本定时跑：

bash复制# 检查本机配置的DNS是否有异常变更
cat /etc/resolv.conf

# 检查hosts文件是否有新增异常条目
cat /etc/hosts

# 对比本地DNS与公共DNS的关键域名解析结果
for domain in www.baidu.com www.taobao.com github.com; do
    echo "== $domain =="
    echo "local:  $(dig +short $domain)"
    echo "aliyun: $(dig +short @223.5.5.5 $domain)"
done

# 查看dnsmasq日志中的异常解析
grep "cached" /var/log/dnsmasq.log | tail -20

这套巡检的本质是建立一个“本地解析结果”与“公网解析结果”的对照基线，每次脚本跑出来的结果如果不一致，就说明有东西在中间动手脚。DNS劫持防不胜防，但只要你坚持对比、坚持看日志，大多数劫持在几小时内就会被发现，而不是等到用户投诉网站打不开才反应。

在实际运维中，我见过太多人把DNS防护完全交给运营商和公共DNS，觉得“免费的省心”，直到出了事故才回头补课。自建DNS的价值不只在性能和可控，更在于你可以知道每一次解析背后发生了什么。花一个下午把它搭起来，之后的运维收获绝对对得起这个时间。