简介一份完整的Linux平台DNS服务器配置实验报告面向网络工程专业学生、Linux运维初学者以及需要完成课程设计或实验任务的人群。报告以Red Hat Enterprise Linux为实验环境从实验目的、实验内容、实验环境、实验步骤、实验心得五个部分展开覆盖BIND软件包的安装、服务器固定IP配置、光驱镜像挂载、named服务主配置文件与区域数据库文件的编写、正向/反向区域数据库文件的设置、域名解析测试等关键环节实验中小型企业域名dxflinux.com下不同部门主机的解析规划也有助于理解DNS正向解析与反向解析的实际应用。资源为1个doc格式文档压缩包大小约3.94MB内容以图文步骤为主便于查阅与打印。目前已有3243人学习下载既适合作为DNS配置初学者的参考资料也可作为实验报告撰写的模板。整篇报告步骤完整并配有命令说明适合实验前预习、课上对照操作以及课后复习总结。1. DNS服务器配置实验内网域名解析卡住的从来不是安装宿舍网换了个网段内网那台存课件和实验数据的服务器IP变了所有书签一夜失效。这种场景在课程作业里太常见了——“DNS服务器的配置实验报告.doc”这类题目交上来的内容大多只写了“安装DNS服务并成功解析”但真正让人卡住的是解析链路上任意一环配错现象却全都是“DNS挂了”。这篇顺着实验报告最常见的路径走装服务、建区域、加记录、做验证把正向和反向解析都跑通再把内网环境里反复踩过的那几个坑列出来。适合要做网络实验的学生也适合刚接手小企业内网域名解析的运维。2. 实验前必须吃透的解析流程与记录类型2.1 解析链路从输入域名到拿到IP中间发生了什么DNS实验的核心不是“装一个服务”而是理解客户端拿到IP之前那几跳查询。浏览器输入www.example.local先查的是本机 hosts 文件和 DNS 缓存没有命中才把请求发给网卡上配置的 DNS 服务器。服务器收到请求后如果自己要找的域名是本地区域直接查区域文件返回结果如果不是就根据根提示向根服务器发起迭代查询逐级拿到权威服务器的地址再拿到最终 A 记录。实验中容易忽略的是递归和迭代的区别。作为客户端向内网DNS发起的是递归查询内网DNS替客户端去问根、问顶级域、问权威这个动作叫迭代。实验报告里如果能写清楚“我在服务器上开了Wireshark抓包看到了对根服务器的迭代查询”这份报告的完成度立刻不一样。但没配转发器、防火墙又挡了 53 端口的出站时迭代查询会超时这正好引出后面避坑章节里最常见的一个坑。2.2 实验报告里必须出现的记录类型A、CNAME、PTR、MX写实验报告时最忌讳只写了一两条 A 记录。一份合格的 DNS 配置实验记录至少要覆盖下表里的前四种记录类型作用实验中的验证方式A域名映射到 IPv4 地址nslookup www.example.localAAAA域名映射到 IPv6 地址nslookup -typeAAAA v6.example.localCNAME别名指向另一个域名nslookup web.example.local返回别名链MX邮件服务器记录nslookup -typeMX example.localNS区域内的权威服务器nslookup -typeNS example.localSOA区域起始授权含序列号等参数nslookup -typeSOA example.localPTR反向解析IP 映射域名nslookup -typePTR 192.168.10.10或dig -xCNAME 记录经常在实验里被忽略。它的作用是让多个服务名指向同一个主机比如内网里web和mail都指向同一台机器用一条 A 记录加一条 CNAME 就能表达清楚。注意 CNAME 不能和 A 记录同时存在于同一个名字上这是 Windows DNS 管理界面会直接报错的一个边界。2.3 为什么实验至少需要两台机器很多学生图省事在 DNS 服务器自己身上做验证结果 nslookup 怎么都通。原因是本机查询可能走 hosts 文件或本地缓存掩盖了服务器配置的问题。像localhost这类名字根本不会出网卡。正确的做法是准备两台虚拟机一台跑 DNS 服务一台作为客户端客户端网卡的 DNS 指向服务器。客户端可以是 Windows 也可以是无桌面 Linux关键在于验证环境要和实际使用场景一致。虚拟化平台选 VMware 还是 KVM 都可以网络模式建议用自定义虚拟网络或桥接避免 NAT 模式带来的额外干扰。NAT 模式下虚拟机的默认网关和 DNS 都是虚拟网卡自动分配的查问题时会多一个变量。后面避坑章节会单独讲虚拟机 DNS 失联的现象。3. 准备环境与安装DNS服务静态IP是第一步3.1 实验环境规划想清楚再动手先定规划再装机别拿到镜像就开始下一步。我给实验定的基线是DNS 服务器静态 IP关闭网卡的“自动获取 DNS”主机名简短有意义和区域名不冲突。下面是常用的一张规划表角色主机名IP 地址网卡 DNS 指向操作系统DNS 服务器dns1192.168.10.1127.0.0.1Windows Server 或 Linux客户端client1192.168.10.20192.168.10.1Windows 10 / LinuxWeb 测试机web1192.168.10.10192.168.10.1任意后续用 IIS 或 Nginx 验证这里有一个选型上的建议如果是在校实验或模拟域环境选 Windows Server如果是为了跑低成本生产环境或学习 Linux 运维选 bind9。两者在区域文件格式上互通先学哪个都不亏。IP 规划用固定的192.168.10.0/24这个私有段即可避免和虚拟网卡的默认网段冲突否则后面创建的虚拟机可能自动拿到同一个网段但不同子网的地址排查的时候很绕。3.2 用 PowerShell 在 Windows Server 上安装 DNS 服务Windows Server 上安装 DNS 角色很快常见有两种入口服务器管理器图形界面或 PowerShell。实验报告里推荐用 PowerShell命令可复制可记录截图也好看。# 以管理员身份运行 PowerShell Install-WindowsFeature DNS -IncludeManagementTools # 确认安装结果 Get-Service DNS # 如果本机网卡是自动获取地址需要改为静态IP # New-NetIPAddress 会覆盖当前地址注意备份原有配置 New-NetIPAddress -InterfaceAlias Ethernet0 -IPAddress 192.168.10.1 -PrefixLength 24 -DefaultGateway 192.168.10.254 Set-DnsClientServerAddress -InterfaceAlias Ethernet0 -ServerAddresses 127.0.0.1IncludeManagementTools这个参数必须带上否则图形管理工具 DNS Manager 不会安装后面配置区域时只能靠命令行新手容易找不到入口。把 DNS 指到127.0.0.1是让服务器自身解析走本机服务后面如果这台机器要加入域这个指向要改成域控地址这是后话。3.3 Linux 发行版上安装 bind9麒麟系统同样适用Linux 上做 DNS 实验的主流方案是 bind9。Debian/Ubuntu 系用apt install bind9CentOS/RHEL 以及国产的麒麟系统用yum install bind。包名不同服务名也不同Ubuntu 上是named麒麟上同样是named配置目录统一在/etc/named/或/etc/bind/下看发行版集成方式。# Ubuntu/Debian 系 sudo apt update sudo apt install bind9 bind9-utils -y # CentOS/RHEL/麒麟系 sudo yum install bind bind-utils -y # 启动并设开机自启 sudo systemctl enable --now named # 确认监听状态udp/tcp 53 都应处于 LISTEN ss -lntup | grep :53bind9-utils或bind-utils里的named-checkconf和named-checkzone是后面调 zone 文件时的玄学终结者语法对不对一跑就知道。别装完就急着改配置先把服务正常起来的基线状态确认好再往下走。3.4 防火墙和端口检查装完服务先看 53 端口DNS 服务监听 UDP 和 TCP 的 53 端口。UDP 是主查询通道TCP 用于区域传送和大包响应。很多实验失败是在服务器本机 nslookup 正常客户端一来就被防火墙拦了。Windows Server 装完 DNS 角色后一般会自动放行但如果你用的是精简版系统或云镜像要手动检查。# Linux 上放行 DNS 端口麒麟/RHEL 系 sudo firewall-cmd --permanent --add-servicedns sudo firewall-cmd --reload # Windows PowerShell 检查防火墙规则 Get-NetFirewallRule -DisplayName *DNS* | Select DisplayName, Enabled, Direction如果客户端能 ping 通服务器但 nslookup 超时九成是防火墙拦了 UDP 53。TCP 53 不通则表现为区域传送失败或查询响应缓慢这类问题不看防火墙规则很难想到。4. 配置正向与反向解析从区域创建到记录验证4.1 创建正向查找区域区域名称决定了后面所有域名正向查找区域是实验的主战场。区域名一般推荐用.local结尾的内部域名比如example.local不要直接用example.com。理由很简单.local不会被公网 DNS 识别不会和内网出口的解析产生混淆实验环境里还省得处理 DNS 分域的问题。Windows 上用 PowerShell 创建区域和记录命令已经足够成熟图形界面和命令行二选一即可我一般用命令行然后配合 DNS Manager 看结果# 主区域名字不带点结尾DynamicUpdate 设 NonsecureAndSecure 便于实验 Add-DnsServerPrimaryZone -Name example.local -ReplicationScope None -DynamicUpdate NonsecureAndSecure # 查看区域是否加载 Get-DnsServerZone -Name example.localReplicationScope None表示区域不复制到 AD适合单机实验。如果后面要把 DNS 集成进 AD 域环境这里要改成Domain或Forest。动态更新在纯手工实验里其实用不上但开启后 DHCP 分配的机器可以自动注册记录实验后期做 DHCPDNS 联动时会方便很多。4.2 添加A记录和CNAME记录一条条加别图快全选正向区域内最常见的两种记录是 A 和 CNAME。A 记录把主机名映射到 IPv4 地址CNAME 把别名指向已有 A 记录。注意 CNAME 指向的必须是完整域名带结尾点这是写 zone 文件时最容易翻车的地方Windows 图形界面会自动补全但 Linux 的 zone 文件手写时必须自己带点。# 添加 A 记录 Add-DnsServerResourceRecordA -ZoneName example.local -Name www -IPv4Address 192.168.10.10 # 添加 CNAME 记录把 web 指向 www.example.local Add-DnsServerResourceRecordCName -ZoneName example.local -Name web -HostNameAlias www.example.local # 验证本机查询 Resolve-DnsName www.example.local -Server 192.168.10.1Resolve-DnsName是 Windows 上比 nslookup 更好用的排查命令输出带记录类型和 TTL一眼能看出命中的是缓存还是区域文件。CNameHostAlias参数的值如果漏了结尾点Windows 会自动补全这个不用太紧张但写脚本的时候最好按 FQDN 规范来。4.3 反向查找区域与PTR记录子网反写的规则要记牢反向区域的名称为“子网反写in-addr.arpa”。比如192.168.10.0/24对应10.168.192.in-addr.arpa。掩码不是 24 位时规则更绕192.168.0.0/16对应168.192.in-addr.arpa10.0.0.0/8对应10.in-addr.arpa。实验中用 24 位掩码最省心。# 创建反向查找区域 Add-DnsServerPrimaryZone -Name 10.168.192.in-addr.arpa -ReplicationScope None -DynamicUpdate NonsecureAndSecure # 添加 PTR 记录IP 最后一组 10 对应 www.example.local Add-DnsServerResourceRecordPtr -ZoneName 10.168.192.in-addr.arpa -Name 10 -PtrDomain www.example.local # 反向查询验证 Resolve-DnsName 192.168.10.10-Name 10的含义是“网段内最后一段地址”不要写成完整 IP。反向解析在实验报告里经常被跳过但生产环境下邮件服务器反查、日志审计都要用 PTR实验里顺手加上报告完整度能上一个台阶。4.4 Linux下zone文件写法named.conf中的区域定义与序列号Linux 上配置 bind9 的区域有两种写配置的方式老式的/etc/named.conf里直接写 zone 块新版 Ubuntu 的/etc/bind/named.conf.local是独立文件效果一样。关键是 zone 文件本身。# /etc/named.conf 中追加 zone example.local IN { type master; file /etc/named/example.local.zone; allow-update { none; }; }; zone 10.168.192.in-addr.arpa IN { type master; file /etc/named/10.168.192.arpa; };# /etc/named/example.local.zone $TTL 1H IN SOA dns1.example.local. admin.example.local. ( 2025061801 ; 序列号每次修改必须递增 1H ; 刷新时间 15M ; 重试时间 1W ; 过期时间 1H ) ; 否定缓存TTL IN NS dns1.example.local. dns1 IN A 192.168.10.1 www IN A 192.168.10.10 web IN CNAME www.example.local.SOA 记录里的序列号2025061801是很多人忽略的点。bind9 不会自动识别你对 zone 文件的修改必须手动递增这个序列号然后rndc reload否则从服务器或下游缓存拿到的一直是旧数据。这个“改了不生效”的现象我见过太多次说玄学也好其实就是序列号没动。写完用named-checkzone example.local /etc/named/example.local.zone做语法校验过了再systemctl reload named。5. DNS配置避坑五个现象背后的真实原因5.1 Linux下改了 resolv.conf重启网络就还原现象编辑/etc/resolv.conf写入nameserver 192.168.10.1当时能用重启网络或重启系统后文件被重置DNS 指向变回自动获取的网关地址。原因新版本 Linux 发行版的/etc/resolv.conf由 NetworkManager 或 systemd-resolved 托管手动写文件会被覆盖。这是 Linux 系统中配置 DNS 出现的高频问题。解决用 nmcli 把 DNS 写进连接配置而不是直接改文件。# 查看连接名 nmcli connection show # 将 DNS 写入连接配置并忽略自动获取的 DNS nmcli connection modify System eth0 ipv4.dns 192.168.10.1 ipv4.ignore-auto-dns yes nmcli connection up System eth0 # 确认生效 cat /etc/resolv.conf这个方案在麒麟系统和 RHEL 系上都适用。如果系统用的是 systemd-resolved还需要确认/etc/resolv.conf是否软链到stub-resolv.conf必要时用resolvectl dns命令查看实际生效的 DNS 配置别只看文件内容。5.2 Windows虚拟机自动获取DNS时失联手动指定就正常现象Windows 虚拟机在 NAT 网络下能上网但客户机把 DNS 指向内网 DNS 后失联手动在网卡填192.168.10.1又恢复。原因虚拟机 NAT 模式的 DHCP 服务给客户端分配的 DNS 是虚拟网关地址客户端优先使用它做解析指向内网 DNS 的配置没在网卡属性里真正生效或者是 DNS 缓存里还残留旧记录。解决在虚拟机平台的 DHCP 配置里直接改 DNS 分配让 DHCP 下发正确的 DNS 地址。VMware 的虚拟网络编辑器里可以指定“NAT 设置”的 DNS 服务器Hyper-V 则去改虚拟交换机或 DHCP 池的选项。同时清一下客户端缓存ipconfig /flushdns ipconfig /all/all输出里看到“DNS Servers”一栏的 IP 是内网 DNS再往下验证才有意义。5.3 内网DNS查询外网域名超时或报 SERVFAIL现象客户端把 DNS 指向内网 DNS 后解析www.example.local正常但查任何公网域名返回 SERVFAIL 或超时。原因内网 DNS 没配转发器迭代查询又发不出去常见是防火墙拦了 UDP 53 出站或者根提示文件指向的根服务器 IP 在当前网络不可达。解决在 DNS 服务器上配置转发器把公网解析交给上游。# Windows DNS 添加转发器 Add-DnsServerForwarder -IPAddress 223.5.5.5, 114.114.114.114# Linux bind9 转发配置写在 named.conf 的 options 段 forwarders { 223.5.5.5; 114.114.114.114; }; forward only;223.5.5.5和114.114.114.114是国内的公共 DNS 服务地址实验环境里做转发器足够稳定。forward only让 bind 完全依赖上游不回退到根迭代能减少一半的排查变量。生产环境可以去掉only让服务器在上游不可用时自己迭代。5.4 PTR记录加了反向解析还是失败现象nslookup 192.168.10.10返回“Non-existent domain”但反向区域里明明有 PTR 记录。原因反向区域名写错是最常见的情况。比如把10.168.192.in-addr.arpa写成了192.168.10.in-addr.arpa或者区域创建成功但 PTR 记录的Name字段填的是完整 IP 而不是最后一段。解决先用Resolve-DnsName -Type PTR 192.168.10.10或 Linux 上的dig -x 192.168.10.10看返回的权威区域名再回到 DNS 管理界面核对区域命名的反写规则。24 位掩码对应x.x.x.in-addr.arpa是没错的错多半是把网段顺序搞反了。5.5 AD域环境中的DC网卡DNS指错方向现象部署 AD 域时三台 DC 之间互相报“找不到域控制器”或“RPC 服务器不可用”dcdiag一片红。原因DC 的网卡 DNS 指向了外部 DNS路由器或公共 DNS而 AD 域名解析需要先经过 DC 上的 DNS 才能找到域控。AD 域里 DC 的网卡 DNS 配置有硬性要求必须指向自身或另一台 DC不能指向外部。解决把每台 DC 的网卡 DNS 改为回环地址或另一台 DC 的固定 IP重启Netlogon服务和 DNS 服务重跑dcdiag验证。这个坑在单台 DNS 实验环境里不会暴露但一旦实验扩展到“DNSAD 域控”组合它就是第一个拦路虎。6. 用查询工具和日志验证解析从实验走向生产实验到“能解析”不算完建议把验证手段也写进报告。客户端的验证命令Windows 上nslookup和Resolve-DnsName配合用Linux 上dig是主力。dig的trace参数能一步步展示从根到权威的查询路径这是排查“内网解析正常但公网解析慢”时最好用的工具。# 指定服务器查询绕过系统默认 DNS dig 192.168.10.1 www.example.local # 追踪完整解析路径 dig 192.168.10.1 www.baidu.com trace # 只输出最终结果便于脚本处理 dig 192.168.10.1 www.example.local short另一个容易被忽略的是 DNS 日志。Windows DNS 管理器里可以开启“调试日志”把查询来源和响应状态记录到文件Linux bind 则在logging配置段里打开 queries 日志。实验报告里附一段“开启日志后观察客户端查询到达服务器”的记录比贴一堆截图更能体现你理解了解析链路的全貌。从实验走向生产有几个收敛项值得注意。转发器要选两条以上避免单点依赖区域传送只允许从服务器到指定 IP递归查询在生产环境建议限制为内网来源防止被外部利用放大攻击。物联网设备这类纯 IP 直连的场景DNS 依赖不高但一旦设备多了为设备分配固定域名比维护一堆 IP 清单省心得多。我自己的习惯是每次改完 DNS 配置先在服务器本机查再到客户端查最后在客户端上用dig trace看完整链路。三步走完定位不了就开抓包看 UDP 53 的往返。这套流程救了我很多次。希望帮到你。本文还有配套的精品资源点击获取