DHCP 服务器与DNS服务器-EW帮帮网

DHCP 服务器与DNS 服务器

DHCP 服务介绍

在大型网络中，系统静态分配IP地址面临问题：

确保不要同时在多个系统上使用同一个地址。
部署新系统通常需要手动分配其IP地址。在云环境中，实例的网络是自动化配置的。

动态主机配置协议（DHCP-Dynamic Host Configuration Protocol）提供了一种自动配置网络参数的方法，例如IP地址，默认网关，DNS服务器和域或NTP服务器。在网络中部署DHCP服务器，您可以集中控制这些参数。

DHCP有两种协议：

用于IPv4网络的 DHCPv4。
用于IPv6网络的 DHCPv6。

本课程只介绍DHCPv4。

如果把局域网比作一个热闹的公寓楼，那DHCP 服务就像是楼里的「自动门牌号管理员」。

当你（一台新电脑、手机或设备）第一次搬进这栋楼（接入网络），还没来得及申请门牌号（IP 地址）时，DHCP 就会主动跑过来：“新来的朋友？我给你分配一个临时门牌号吧！”

它会当场给你发三个关键东西：

一个独一无二的门牌号（IP 地址，比如 192.168.1.100）
通往小区大门的路（子网掩码，告诉你这栋楼的范围）
快递收发点地址（网关，让你能连到外面的互联网）

更贴心的是，这个门牌号有「租期」（比如 24 小时）。到期前它会问你：“还住这儿不？要续期不？” 你要是还在网，就自动续期；要是搬走了（断开连接），它就把这个号码收回来，分给新来的设备。

要是没有 DHCP，每台设备都得手动记门牌号，一旦记错就会和邻居 “撞号”（IP 冲突），整栋楼的通信都会乱套。所以说，DHCP 就是那个默默干活的管理员，让所有设备在网络里 “住得舒服、找得到彼此”。

配置 DHCP 服务器

dhcpd服务使用/etc/dhcp/dhcpd.conf配置文件。 dhcp软件包提供/usr/share/doc/dhcp-*/dhcpd.conf.example 配置文件示例。

# 安装软件包
[root@server ~]# yum install -y dhcp

#配置
[root@server ~ 10:45:02]# /bin/cp /usr/share/doc/dhcp-*/dhcpd.conf.example /etc/dhcp/dhcpd.conf
[root@server ~ 10:52:26]# vim /etc/dhcp/dhcpd.conf
#典型的DHCP配置示例：
subnet 10.1.8.0 netmask 255.255.255.0 {
  range 10.1.8.101 10.1.8.130;
  option domain-name-servers 223.5.5.5;
  option domain-name "laoma.cloud";
  option routers 10.1.8.2;
  option broadcast-address 10.1.8.255;
  default-lease-time 600;
  max-lease-time 7200;
}
[root@server ~ 10:57:20]# systemctl restart httpd

配置说明：

authoritative，指示服务器对其所管理的子网具有权威性。
subnet，提供的子网详。
range，指定服务器在该范围内分配IP地址。
option routers，指定服务器提供默认网关地址。
option domain-name-servers，指定服务器提供DNS名称服务器。
option domain-search，指定服务器提供DNS域搜索列表。
default-lease-time，提供网络信息默认租期，如果客户端不要求任何特定的租期。单位秒。
max-lease-time，指示服务器可以从客户端请求接受的最大租期。单位秒。

客户端系统上的NetworkManager使用domain-name-servers和domain-search更新resolv.conf文件中的nameserver和search参数。

配置 DHCP 客户端

添加一个自动获取ip连接

[yy@client ~ 11:02:46]$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
ens33            UP             10.1.8.11/24 fe80::20c:29ff:fea
ens36            UP             10.1.8.101/24 fe80::d351:85f3:
#修改网卡设备名称为ens36-dhcp
[root@client ~ 11:24:14]# nmcli connection add type ethernet ifname ens36 con-name ens36-dhcp
连接 "ens36-dhcp" (c78b94a7-0f2a-4bd4-b9f4-e11c457f9296) 已成功添加。
#验证
[root@client ~ 11:24:25]# nmcli c
NAME        UUID                                  TYPE      DEVICE 
ens33       fe77f624-67c9-4a51-86a4-748bd6492321  ethernet  ens33  
ens36-dhcp  c78b94a7-0f2a-4bd4-b9f4-e11c457f9296  ethernet  ens36

基于 MAC 地址预留IP地址

在配置文件中，host声明可以将MAC地址绑定到IP地址。此配置对于始终为特定系统的网络接口提供相同的IP地址特别有用，尤其是Web或数据库系统之类的服务器。

如果把局域网比作一个公司的办公区，每个设备的MAC 地址就像是员工的「身份证号」（唯一且固定），而IP 地址则是他们的「工位编号」。

「基于 MAC 地址预留 IP」就像是公司的「固定工位制度」：

新来的临时员工（陌生设备）会被前台（DHCP 服务器）随机分配一个临时工位（动态 IP）
但老员工（常用设备，比如老板的电脑、打印机）的身份证号（MAC 地址）会被登记在前台的「固定工位表」上
只要老员工刷身份证（MAC 地址）进门，前台就会直接把他的专属工位号（预留 IP）给他，永远不变

比如你家的路由器里给客厅的智能电视预留了 IP：192.168.1.100，不管电视重启多少次、路由器断电多久，只要电视一联网（出示 MAC 地址），路由器就会说：“哦，是你啊，100 号工位还是你的～”

这样做的好处就像固定工位：大家总能在老地方找到常用设备（比如智能家居控制、文件共享），不会因为工位总变而找不到人。

客户端MAC地址查看

#客户端查看mac地址
[root@client ~ 11:42:42]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,
ens33            UP             00:0c:29:ac:81:1e <BROADCAST,MU
ens36            UP             00:0c:29:ac:81:28 <BROADCAST,MU
#服务端配置文件
[root@server ~ 11:34:17]# vim /etc/dhcp/dhcpd.conf
host client.linux.fun {
  hardware ethernet 00:0c:29:ac:81:28;
  fixed-address 10.1.8.88;
}
[root@server ~ 11:44:12]# systemctl restart dhcpd
#重新激活
[root@client ~ 11:43:48]# nmcli connection up ens36-dhcp
连接已成功激活（D-Bus 活动路径：/org/freedesktop/NetworkManager/ActiveConnection/5）
#客户端ip地址变为固定的10.1.8.88
[root@client ~ 11:45:31]# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
ens33            UP             10.1.8.11/24 fe80::20c:29ff:feac:811e/64 
ens36            UP             10.1.8.88/24 fe80::1677:7a37:9c42:13a4/64

DNS 服务介绍

如果把互联网比作一个超级大商场，那DNS 服务就像是商场里的「智能导航台」。

你想去 “京东”（域名：jd.com）买东西，直接告诉导航台 “我要去京东”（输入域名），它就会立刻告诉你具体位置：“在 3 栋 201 室”（对应的 IP 地址：111.13.100.91）。

要是没有这个导航台，你就得记住每个店铺的精确位置（比如 111.13.100.91）才能找到地方 —— 这就像记电话号码一样麻烦，而且店铺搬家了（IP 地址变了）你也不知道。

DNS 还很聪明：

会把常去的店铺位置存在 “小本本” 里（本地缓存），下次问就不用查了
一层一层往上问（根域名服务器→顶级域名服务器→权威服务器），总能找到答案
一家店多个门（一个域名对应多个 IP），它会帮你选最近的那个门进

简单说，DNS 就是互联网的 “通讯录翻译官”，让我们不用记枯燥的 IP 数字，只要记住好记的域名，就能轻松找到网上的各种服务～

DNS（Domain Name System，域名系统）服务是一种用于将域名转换为IP地址的分布式数据库服务。它是互联网的核心服务之一，使得用户能够通过易于记忆的域名来访问网站和其他网络服务，而无需记住复杂的IP地址。。

DNS 也是一个存储网络主机和资源目录的分层命名系统。 目录中的信息将网络名称映射到不同资源记录。

根域：DNS层次结构最顶层，使用独立的"."表示。
顶级域：DNS层次结构第二层，例如**.com**，.net和**.org**等域。
二级域：DNS层次结构第三层，例如**laoma.cloud **和 redhat.com等域。由各个组织使用。
以此类推。

在这里插入图片描述

DNS 查询

如果把互联网比作一座超级大商场，那DNS 查询就像是你找人的全过程：

当你想找 “星巴克”（输入域名：starbucks.com），但不知道具体在商场哪层哪号（IP 地址）——

先问自己口袋里的小纸条（本地 DNS 缓存）：“我之前记过星巴克在哪儿吗？”
如果记过（有缓存），直接就能出发，省时间。
小纸条没记录？就问商场总服务台（本地 DNS 服务器，比如你家路由器或运营商提供的）：“请问星巴克在哪个位置？”
服务台如果知道（它的缓存里有），会直接告诉你：“在 3 楼东侧 302（IP 地址）。”
服务台也不知道？就一层层往上问：
- 先问商场分区导览台（顶级域名服务器，.com 服务器）：“星巴克在哪个区域？”
- 分区导览台指向品牌专属柜台（权威 DNS 服务器）：“去星巴克自己的服务台问，他们最清楚。”
- 最后品牌柜台（权威服务器）精准告诉你：“3 楼东侧 302，没错！”
记住答案备用：服务台会把这个地址记在自己的本子上（缓存），下次有人再问，就不用重复跑腿了。

整个过程，你只需要说 “找星巴克”，不用记 302 这些数字 ——DNS 查询就是这样一套 “从好记的名字到具体地址” 的问路流程，让你在互联网商场里轻松找到想去的地方～

主机的 DNS 查询主要有两种方式：递归查询和迭代查询。

DNS 查询时，DNS 请求报头部的 RD 字段决定了查询类型：

RD 为 1 => 递归查询，默认查询方式。
RD 为 0 => 迭代查询。

如果把 DNS 查询比作 “找人”，那递归查询和迭代查询就是两种不同的 “问路方式”：

递归查询：当甩手掌柜，让对方全程包办

就像你问前台小姐姐：“请问星巴克在哪？”
小姐姐说：“你坐着等，我帮你查到底！”
然后她自己跑遍商场总服务台、分区导览台、品牌柜台，最后把精确地址告诉你 ——你只问一次，对方负责搞定所有中间环节。

对应到 DNS：本地 DNS 服务器收到你的查询后，会主动向上级服务器一层层查，直到拿到最终 IP 地址，再一次性返回给你。你（客户端）全程只和本地 DNS 打交道。

迭代查询：自己跑流程，对方只指方向

还是问星巴克，但前台小姐姐说：“我不知道具体位置，但你可以先去 3 楼导览台问问”；
你跑到 3 楼导览台，对方又说：“你再去东侧品牌区的服务台，他们肯定知道”；
最后你自己找到品牌服务台，拿到了地址 ——每一步都要自己跑，对方只给下一个查询目标。

对应到 DNS：本地 DNS 服务器问根服务器 "xxx.com在哪 “，根服务器说” 去问.com 服务器 “；本地 DNS 再问.com 服务器，对方说” 去问该域名的权威服务器 "；直到本地 DNS 自己从权威服务器拿到 IP，再返回给你。

简单说：

递归是 “你帮我查”（客户端→本地 DNS，全程躺平）
迭代是 “告诉我找谁查”（本地 DNS→各级服务器，自己跑腿）

两者配合完成一次 DNS 查询：你（客户端）对本地 DNS 用递归，本地 DNS 对上层服务器用迭代，最后合力找到目标～

递归查询：以本地名称服务器为中心，DNS 客户端只是发出原始的域名查询请求报文，然后就一直处于等待状态，直到本地名称服务器发来了最终的查询结果。此时的本地名称服务器就相当于中介代理 的作用。

迭代查询：以DNS客户端自己为中心。所有查询工作全部是 DNS 客户端自己进行。DNS客户 会按照顺序向本地名称服务器、一级名称服务器、二级名称服务器、权威名称服务器发出查询 DNS 的请求查询报文，这个过程中每一级服务器就会返回一个能解答这个查询的下一个名称服务器列表 A，获取到下个查询列表信息 A 后 DNS 客户会再向返回的列表 A 中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果。

有些DNS服务器，为了减轻自己的负载，则会配置禁止使用递归查询，则客户端只能使用递归查询。

两者主要区别：

递归查询 以本地名称服务器 为中心进行查询
迭代查询 以 DNS客户端自己 为中心查询。

DNS 迭代查询

**迭代查询，也叫迭代解析。**使用迭代解析方式时，**所有的查询工作都是由 DNS 客户自己进行的。**如果它所配置的主名称服务器（如 Windows 系统中的 首选 DNS 服务器）不能解析的话，客户端还会继续向所配置的其它名称服务器（如 Windows 系统中的 备用 DNS 服务器）查询。

如果考虑了本地名称服务器的缓存技术（在 DNS 服务器上对一定数量查询过的记录保存一定时间，这样后面查询同样的域名信息时就可直接从缓存中调出来，以加速查询效率）的话，迭代名称解析的基本流程如下（在此仅以首先 DNS 服务器作为本地名称服务器为例，与其它备用 DNS 服务器的解析流程完全一样）：

DNS 客户端向本机配置的本地名称服务器发出 DNS 域名查询请求。
本地名称服务器收到请求后，先查询本地的缓存。
- 如果有该域名的记录项，则本地名称服务器就直接把查询的结果返回给客户端。
- 如果本地缓存中没有该域名的记录，则向 DNS 客户端返回一条 DNS 应答报文，报文中会给出一些参考信息，如本地名称服务器上的根名称服务器地址等。
DNS 客户端在收到本地名称服务器的应答报文后，会根据其中的根名称服务器地址信息，向对应的根名称服务器再次发出与前面一样的 DNS 查询请求报文。
根名称服务器在收到 DNS 查询请求报文后，通过查询自己的 DNS 数据库得到请求 DNS 域名中顶级域名所对应的顶级名称服务器信息，然后以一条 DNS 应答报文返回给 DNS 客户端。
DNS 客户端根据来自根名称服务器应答报文中的对应顶级名称服务器地址信息，向该顶级名称服务器发出与前面一样的 DNS 查询请求报文。
顶级名称服务器在收到 DNS 查询请求后，先查询本地的缓存：
- 如果有所请求的 DNS 域名的记录项，则直接把对应的记录项返回给 DNS 客户端。
- 否则，通过查询后把对应域名中二级域名所对应的二级名称服务器地址信息以一条 DNS 应答报文返回给 DNS 客户端。
DNS 客户端继续按照步骤 5 与步骤 6 的方法分别向三级、四级名称服务器查询，直到查到最终的权威名称服务器返回到最终的记录。

如果在上述步骤中对应域名的权威名称服务器都说找不到对应的域名记录，则会向 DNS 客户端返回一条查询失败的 DNS 应答报文，称为负响应。当然，如果这个权威名称服务器上配置了指向其它名称服务器的转发器，则权威名称服务器还会在转发器指向的名称服务器上进一步重复上述步骤查询。另外，如果 DNS 客户端上配置了多个 DNS 服务器，则还会继续向其它 DNS 服务器查询的。

DNS 查找到这里就基本来可以获取域名对应的 IP 了，除非需要查找的域名没有配置 IP 则查询失败。

主机和资源记录

如果把 DNS 服务器比作一本 “互联网通讯录”，那资源记录（Resource Record，RR） 就是通讯录里的一条条具体记录。每条记录都有固定格式，就像通讯录里每条信息都包含 “姓名、电话、地址” 一样，DNS 资源记录也有自己的 “身份信息”。

常见的资源记录类型，就像通讯录里的不同联系方式：

A 记录：最常用的 “住宅电话”，直接告诉你域名对应的 IP 地址（比如baidu.com → 180.101.50.242）。
AAAA 记录：相当于 “IPv6 手机号”，专门对应 IPv6 地址（比 A 记录的数字更长，像一串身份证号）。
CNAME 记录：类似 “别名备注”，比如给 “张三” 备注 “老张”，www.taobao.com其实是taobao.com的别名，通过 CNAME 指向主域名。
MX 记录：相当于 “快递收件点”，指定邮件该送到哪个服务器（比如qq.com的邮件都由mx.qq.com接收）。
NS 记录：相当于 “通讯录管理员”，告诉你哪个服务器负责管理这个域名的记录（比如com域名由 Verisign 等机构的服务器管理）。

每条记录还有 “有效期”（TTL），就像通讯录会定期更新，过期后 DNS 服务器会重新获取最新信息。

简单说，资源记录就是 DNS 服务器里存的 “具体联系方式”，不同类型对应不同用途，共同帮你把域名翻译成能找到的 “网络地址”。

⼀个主机，无论是客户端还是服务器，都具有以下 DNS 资源记录：

⼀个或多个A或AAAA记录
用于将其IP地址反向映射到名称的PTR记录
⼀个或多个CNAME记录（可选）

DNS zone 还具有以下资源记录：

唯一的 SOA 记录
每个权威名称服务器的 NS 记录
⼀个或多个MX记录（可选）
用于在域中查找服务的⼀个或多个SRV记录（可选）

配置权威名称服务器

权威名称服务器架构

架构示例1：外部客户端查找laoma.cloud

在这里插入图片描述

这张图是 DNS 查询过程的 “真人跑腿版说明书”，把技术流程变成现实场景，秒懂！

角色代入：把 DNS 服务器当 “问路大哥”

Internal Network（公司内网）：你公司的 “内部通讯录室”，存着 example.com 的基础信息
Customer Site（用户侧）：你家 / 用户办公室，想访问 www.example.com 的普通路人
client (stub resolver)：你手机 / 电脑里的 “小助手”，负责帮你发起 DNS 查询
caching-only：你家路由器里的 “临时备忘录”，能记住之前查过的地址（但这次没缓存，得重新查）
secondary (example.com)：公司对外的 “前台大哥”，专门负责回答外人的问路
authoritative (.) / authoritative (.com)：互联网里的 “行业大佬”，掌管根域名（.）和顶级域名（.com）的全局地址
primary (example.com)：公司内网的 “终极通讯录”，存着 example.com 的最权威信息

流程拆解：查 `www.example.com` 像 “问路找星巴克”

用户侧：小助手开始问路（绿色递归查询）
你想访问 www.example.com，但手机 / 电脑（client）和家里路由器（caching-only）都没记过地址 → 小助手说：“我啥都不知道，你（路由器）帮我查到底！”（这就是递归查询：用户只问一次，让路由器全程包办）
路由器找 “前台大哥”（蓝色迭代查询）
路由器（caching-only）也不知道地址，于是开始 “迭代问路”：
- 先问互联网最顶层的 “根域名大佬”（authoritative (.)）：“example.com 在哪？”
  根大佬说：“我不清楚具体地址，但你可以去问 .com 行业大佬！”（根域名只负责指路，不存具体地址）
- 路由器又问 .com 大佬（authoritative (.com)）：“example.com 在哪？”
  .com 大佬说：“去问 example.com 公司的前台大哥（secondary (example.com)），他们自己清楚！”（顶级域名也只负责指路）
公司前台：从内网同步地址（红色区域传送）
公司的 “前台大哥”（secondary）其实是从内网的 “终极通讯录”（primary）同步来的信息 → 相当于公司定期把最新地址抄给前台，确保外人问到时，前台能直接回答。
前台告诉路由器最终地址
路由器问到公司前台（secondary）后，前台直接说：“www.example.com 的地址是 xxx.xxx.xxx.xxx！” → 路由器把地址记到 “临时备忘录”（caching-only），再告诉用户的手机 / 电脑 → 你就能成功访问网站啦！

关键区别：递归 vs 迭代 vs 区域传送

递归查询（绿色）：用户→路由器，像 “甩手掌柜”：“你帮我查，别让我操心！”
迭代查询（蓝色）：路由器→根→顶级域名→公司前台，像 “自己跑流程”：“不知道？那你告诉我该问谁！”
区域传送（红色）：公司内网→前台，像 “同步通讯录”：“公司地址更新了，前台你也抄一份！”

一句话总结：

查 DNS 就像 “你想找星巴克，先问家里路由器，路由器问遍根域名、顶级域名、公司前台，最后拿到地址”。
递归是 “让别人全程代办”，迭代是 “自己一步步找线索”，区域传送是 “公司内部同步最新地址”—— 三者配合，才能让你 “输入域名，秒开网站”！

架构示例2：内部客户端查找laoma.cloud

在这里插入图片描述

把内网 DNS 查询比作「公司找会议室」，用生活化场景翻译：

角色对应
- client（员工电脑）：你想找 “3 楼会议室（www.example.com）”，但不知道在哪
- caching-only（公司路由器）：公司前台，能记常用地址，但这次没存 “3 楼会议室” 信息
- secondary/primary（公司DNS服务器）：公司行政部，专门管 “内部会议室地址”
- authoritative (.) / (.com)（公网DNS）：城市市政厅 / 街道办，只负责 “指路”，不管你公司内部的事
流程：找会议室却绕了远路
- 你（client）问公司前台（caching-only）：“3 楼会议室在哪？”（递归查询，你只说需求，让前台包办）
- 前台也不知道，只好跑去问 “市政厅（根服务器.）”：“xx 公司的会议室咋找？” 市政厅说：“找街道办（.com 服务器）问问！”（迭代查询，前台自己跑腿问公网）
- 街道办又说：“找你们公司行政部（secondary）啊！他们自己清楚！”
- 最后前台找到公司行政部（secondary），拿到会议室地址，告诉你结果
“低效” 吐槽
图里标注 “inefficient”，就像「你在公司找会议室，前台却先跑去市政厅问，再绕回公司行政部」—— 明明公司内部就有答案，却绕了公网的远路，实际工作里会直接让行政部（内网 DNS）回答，少折腾！

一句话总结：内网查自己域名，却绕去公网问了一圈，最后又绕回内网，像 “在公司找会议室，却先跑去市政厅问路”，多此一举～

更好的方法是提供内部slave权威服务器。查询本地域的记录时，消除了外部查询，而且更加安全。

配置 BIND

BIND（Berkeley Internet Name Domain）是很常用的 DNS 服务器软件，用 “开 DNS 小超市” 的思路，生动说下配置流程：

1. 安装 BIND：给超市 “搭货架”

就像开超市得先有货架，在 Linux（以 CentOS/RHEL 为例）上装 BIND：

yum install bind bind-utils  # 装软件包，货架搭好啦

（Ubuntu 用 apt install bind9 ，同理～）

2. 配置主配置文件（`named.conf`）：定超市 “规则”

编辑 /etc/named.conf ，核心是允许谁能访问、指定 zone 文件存哪，像给超市定 “营业时间、仓库位置”：

options {
    directory "/var/named";  # zone 文件（域名资料）存在这个文件夹，相当于“仓库地址”
    allow-query { any; };    # 允许任何人来查（小超市对所有人开放）
    recursion yes;           # 支持递归查询（顾客问“xx域名”，帮他查到底）
};

# 定义要管理的域名（zone），比如 example.com
zone "example.com" {
    type master;             # 我是“主超市”，存最权威资料
    file "example.com.zone"; # 这个域名的资料存在 example.com.zone 文件里
};

3. 写 zone 文件（`example.com.zone`）：填 “商品清单”

在 /var/named 里新建 example.com.zone ，录入域名对应的 IP 等信息，像写 “商品→货架号（IP）”：

$TTL 86400          # 地址有效期1天（商品信息1天更新一次）
@       IN  SOA    ns.example.com. admin.example.com. (
                    2025080601    ; 序列号（每次改资料要+1，让从服务器同步）
                    3600          ; 多久查一次主服务器（1小时）
                    1800          ; 查不到时重试间隔（30分钟）
                    604800        ; 数据失效后保留多久（1周）
                    86400 )       ; 负缓存有效期（1天）
        IN  NS     ns.example.com.  # 本域名的DNS服务器是 ns.example.com

ns      IN  A      192.168.1.100   # ns.example.com 对应这个IP（主DNS地址）
www     IN  A      192.168.1.101   # www.example.com 对应这个IP（网站服务器）
mail    IN  MX 10  mail.example.com. # 邮件服务器是 mail.example.com
mail    IN  A      192.168.1.102   # mail.example.com 对应这个IP

4. 启动 + 验证：开门迎客！

systemctl start named   # 启动 BIND 服务（超市开门）
systemctl enable named  # 设置开机启动（每天营业）

# 验证：用 nslookup 或 dig 查域名
dig www.example.com @192.168.1.100  # 问自己的DNS服务器，看能查到 www.example.com 的IP不

5. （可选）配置从服务器（Secondary）：开 “分店”

在另一台服务器装 BIND，主配置文件里定义：

zone "example.com" {
    type slave;                      # 我是“分店”，从主服务器同步资料
    masters { 192.168.1.100; };     # 主服务器地址（从主超市同步资料）
    file "slave/example.com.zone";  # 同步来的资料存在这里
};

启动服务后，分店会自动从主店同步 example.com.zone 的资料～

一句话总结：
配置 BIND 就像 “开 DNS 小超市”：先装软件搭货架（yum/apt install），定好规则（named.conf 允许谁访问、资料存在哪），填好 “域名→IP” 的商品清单（zone 文件），最后启动服务开门迎客（systemctl start），别人就能通过你的 DNS 查域名啦！

安装 BIND

通过安装bind软件包来安装BIND。名称服务器本身作为named服务运行。 bind包将HTML和PDF格式的BIND文档在安装在/usr/share/doc/bind/目录。

[root@server ~]# yum install -y bind bind-utils

软件包说明：

bind，服务器软件包。
bind-utils，客户端软件包

配置 zone

示例：以下named.conf块将服务器配置为承载yyyxx.cloud及其相应的反向查找区域8.1.10.in-addr.arpa的主要区域文件。它使用从ACL标识example.net服务器中检索到的区域文件，充当example.net域的辅助服务器

[root@server ~ 14:54:44]# vim /etc/named.conf
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "yyyxx.cloud" IN {
    type master;
    file "yyyxx.cloud.zone";
};
zone "8.1.10.in-addr.arpa" IN {
    type master;
    file "10.1.8.zone";
};

创建区域文件

[root@server named 14:56:41]# touch yyyxx.cloud.zone 10.1.8.zone
[root@server named 14:57:10]# chmod 640 yyyxx.cloud.zone 10.1.8.zone
[root@server named 14:57:36]# chgrp named yyyxx.cloud.zone 10.1.8.zone
[root@server named 14:58:09]# ll yyyxx.cloud.zone 10.1.8.zone
-rw-r----- 1 root named 0 8月   6 14:57 10.1.8.zone
-rw-r----- 1 root named 0 8月   6 14:57 yyyxx.cloud.zone

这段内容是配置 BIND 服务器时 “划定管理范围并准备资料文件” 的过程，用 “开 DNS 超市” 类比：

1. 编辑 `named.conf`：给超市划 “经营范围”

named.conf 就像超市的 “营业执照”，明确告诉 BIND 服务器：“你负责管理这些域名 / IP 段的解析”：

# 加载默认规则和根服务器信息（相当于遵守行业通用规范）
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

# 第一条：负责 yyyxx.cloud 域名的正向解析（卖“yyyxx.cloud 品牌”的货）
zone "yyyxx.cloud" IN {
    type master;       # 我是这个域名的“总经销商”（主服务器）
    file "yyyxx.cloud.zone";  # 该域名的解析资料存在这个文件里（商品清单）
};

# 第二条：负责 10.1.8.x 网段的反向解析（给“10.1.8 货架区”的商品贴标签）
zone "8.1.10.in-addr.arpa" IN {  # 反向解析的特殊格式（IP段倒写）
    type master;
    file "10.1.8.zone";  # 反向解析的资料存在这个文件里
};

2. 创建区域文件：准备 “商品清单本”

创建 yyyxx.cloud.zone（正向解析清单）和 10.1.8.zone（反向解析清单），并设置权限：

# 新建两个空白文件（买两个空白笔记本）
touch yyyxx.cloud.zone 10.1.8.zone

# 设置权限：只有 root 和 named 组能读写（笔记本只能超市管理员和系统看）
chmod 640 yyyxx.cloud.zone 10.1.8.zone
chgrp named yyyxx.cloud.zone 10.1.8.zone

# 查看结果：权限正确（-rw-r----- 表示 root 可读可写，named 组可读）
ll yyyxx.cloud.zone 10.1.8.zone

一句话总结：
这一步是给 DNS 服务器 “明确管理哪些域名 / IP 段”，并准备好存放解析规则的文件，且确保文件权限正确（只有服务器能读写），为后续填写具体解析规则（域名→IP、IP→域名）打基础。

示例：yyyxx.cloud域

[root@server named 15:00:14]# vim /var/named/yyyxx.cloud.zone
$TTL 3600
@ IN SOA dns.yyyxx.cloud. root.yyyxx.cloud. (
    42 ; serial
    3H ; secondary refresh
    15M ; secondary retry
    1W ; secondary timeout
    15M ; minimum cache TTL for negative answers
)
               IN NS dns.yyyxx.cloud.
dns            IN A 10.1.8.10
server         IN A 10.1.8.10
student        IN CNAME client.yyyxx.cloud.
client         IN A 10.1.8.11
www         30 IN A 10.1.8.200
@              IN MX 10 mail.yyyxx.cloud.
mail           IN A 10.1.8.253

示例说明：

@字符代表区域的名称，避免重复键入，并且在某些情况下允许重复使用。
区域文件中的SOA记录与前面的示例中的SOA记录是等效的。
如果记录的名称为空，则其值与前面的记录相同。

因此，在前面的示例中：

第一个记录是laoma.cloud.的SOA记录
接下来的记录是laoma.cloud.的NS记录
然后有一个dns的A记录。
然后有一个server的A记录。
然后有一个student的CNAME记录。
然后有一个client的A记录。
然后有一个域的MX记录。
然后有一个mail的A记录。

任何不以点号结尾的名称均被视为部分主机名，应将区域名称添加为完全合格的域名。换句话说，server等效于server.laoma.cloud.。

反向记录，将IP地址映射到主机名。该区域文件必须具有：

SOA记录
NS记录
PTR记录。

示例：8.1.10.inaddr.arpa区域

[root@server ~]# vim /var/named/10.1.8.zone
$TTL 3600
@ IN SOA dns.yyyxx.cloud. root.yyyxx.cloud. (
    42 ; serial
    3H ; secondary refresh
    15M ; secondary retry
    1W ; secondary timeout
    15M ; minimum cache TTL for negative answers
)
               IN NS dns.yyyxx.cloud.
10             IN PTR server.yyyxx.cloud.
10             IN PTR dns.yyyxx.cloud.
11             IN PTR client.yyyxx.cloud.
11             IN PTR student.yyyxx.cloud.
100            IN PTR ns1.yyyxx.cloud.
200            IN PTR www.yyyxx.cloud.
253            IN PTR mail.yyyxx.cloud.

客户端测试

方式1：配置dns

[root@client ~ 16:29:59]# nmcli connection modify ens33 ipv4.gateway 10.1.8.2
[root@client ~ 16:30:22]# nmcli connection up ens33 
连接已成功激活（D-Bus 活动路径：/org/freedesktop/NetworkManager/ActiveConnection/8）

root@client ~ 15:50:03]#  ping student.yyyxx.cloud
PING client.yyyxx.cloud (10.1.8.11) 56(84) bytes of data.
64 bytes from client.yyyxx.cloud (10.1.8.11): icmp_seq=1 ttl=64
64 bytes from client.yyyxx.cloud (10.1.8.11): icmp_seq=2 ttl=64
64 bytes from client.yyyxx.cloud (10.1.8.11): ic

方式2：dig工具

[root@client ~ 16:30:34]# yum install -y bind-utils
已加载插件：fastestmirror
# 查询NS记录 
[root@client ~]# dig @10.1.8.10 yyyxx.cloud NS
# 查询MX记录 
[root@client ~]# dig @10.1.8.10 yyyxx.cloud MX
# 查询A记录 
[root@client ~]# dig @10.1.8.10 student.yyyxx.cloud
# 查询PTR记录
[root@client ~]# dig @10.1.8.10 -x 10.1.8.100

这段内容是在演示 用 BIND 配置 yyyxx.cloud 域名的正向 / 反向 DNS 解析，核心是通过 zone 文件 定义域名→IP（正向）和 IP→域名（反向）的映射，帮你拆解成 “开 DNS 小超市” 的 analogy：

一、正向解析（`yyyxx.cloud.zone`）：给域名 “分配货架（IP）”

把 yyyxx.cloud 域名的各种子域名（dns、server、student 等），对应到具体 IP，像 “给商品贴货架号”：

$TTL 3600          # 地址有效期1小时（顾客记住地址1小时，之后可能更新）
@ IN SOA dns.yyyxx.cloud. root.yyyxx.cloud. (  # 定义“超市规则”：主DNS是 dns.yyyxx.cloud，管理员是 root@yyyxx.cloud
    42 ; serial       # 资料版本号（改配置时+1，让从服务器同步新货）
    3H ; secondary refresh  # 从服务器3小时查一次主服务器，看资料是否更新
    15M ; secondary retry   # 查不到时，15分钟重试一次
    1W ; secondary timeout  # 1周没回应，认为主服务器挂了
    15M ; minimum cache TTL for negative answers  # 查不到域名时，让顾客15分钟内别再问
)
               IN NS dns.yyyxx.cloud.  # 本域名的DNS服务器是 dns.yyyxx.cloud（告诉外人“买 yyyxx.cloud 域名的货，找这个服务器”）

dns            IN A 10.1.8.10   # dns.yyyxx.cloud → 10.1.8.10（主DNS的IP，相当于“超市收银台地址”）
server         IN A 10.1.8.10   # server.yyyxx.cloud → 10.1.8.10（另一台服务器的IP）
student        IN CNAME client.yyyxx.cloud.  # student.yyyxx.cloud 是 client.yyyxx.cloud 的别名（顾客找“student”，实际指向“client”）
client         IN A 10.1.8.11   # client.yyyxx.cloud → 10.1.8.11（客户端服务器IP）
www         30 IN A 10.1.8.200  # www.yyyxx.cloud → 10.1.8.200（有效期30秒，临时地址）
@              IN MX 10 mail.yyyxx.cloud.  # 发邮件到 yyyxx.cloud 时，优先投到 mail.yyyxx.cloud（邮件服务器，相当于“快递代收点”）
mail           IN A 10.1.8.253  # mail.yyyxx.cloud → 10.1.8.253（邮件服务器的IP）

关键逻辑：

@ 代表 yyyxx.cloud.（省略重复域名），所以 IN NS dns.yyyxx.cloud. 实际是给 yyyxx.cloud 域名指定 DNS 服务器。
没写 “点号结尾” 的名称（比如 dns、server），会自动拼接 yyyxx.cloud，变成 dns.yyyxx.cloud.、server.yyyxx.cloud.。

二、反向解析（`10.1.8.zone`）：给 IP “贴域名标签”

把 10.1.8.0/24 网段的 IP（10.1.8.10、10.1.8.11 等），对应回域名，像 “给货架号贴商品名”，让别人查 IP 时，知道这是哪个域名的服务器：

$TTL 3600
@ IN SOA dns.yyyxx.cloud. root.yyyxx.cloud. (  # 规则和正向解析类似，定义“反向超市”的规则
    42 ; serial       
    3H ; secondary refresh  
    15M ; secondary retry   
    1W ; secondary timeout  
    15M ; minimum cache TTL for negative answers  
)
               IN NS dns.yyyxx.cloud.  # 反向解析的DNS服务器也是 dns.yyyxx.cloud（告诉别人“查 10.1.8.x 的IP对应哪个域名，找这个服务器”）

10             IN PTR server.yyyxx.cloud.  # 10.1.8.10 → server.yyyxx.cloud（IP对应域名）
10             IN PTR dns.yyyxx.cloud.    # 10.1.8.10 → dns.yyyxx.cloud（一个IP可以对应多个域名，像“货架号10同时放 dns 和 server 商品”）
11             IN PTR client.yyyxx.cloud. # 10.1.8.11 → client.yyyxx.cloud 
11             IN PTR student.yyyxx.cloud. # 10.1.8.11 → student.yyyxx.cloud（因为 student 是 client 的别名，反向解析也能查到）
100            IN PTR ns1.yyyxx.cloud.    # 10.1.8.100 → ns1.yyyxx.cloud 
200            IN PTR www.yyyxx.cloud.    # 10.1.8.200 → www.yyyxx.cloud 
253            IN PTR mail.yyyxx.cloud.   # 10.1.8.253 → mail.yyyxx.cloud

反向解析的特殊点：

区域名是 8.1.10.inaddr.arpa（把 IP 反过来写，10.1.8.x → 8.1.10.inaddr.arpa），对应 10.1.8.0/24 网段。
记录里的数字（10、11、100），是 IP 的最后一段（10.1.8.10 → 最后一段是 10），所以直接写 10 就代表 10.1.8.10。

三、客户端测试：“顾客验证超市商品”

配置完正向 / 反向解析，客户端（client）通过 nmcli 把 DNS 指向 10.1.8.10（你的 DNS 服务器），然后用 ping、nslookup 测试：

# 1. 配 DNS（让客户端找你的“DNS 小超市”查地址）
nmcli connection modify ens33 ipv4.dns 10.1.8.10  
nmcli connection up ens33  

# 2. 测试正向解析：域名→IP
ping student.yyyxx.cloud  # 实际会解析到 client.yyyxx.cloud（10.1.8.11），因为 student 是别名
# 输出：PING client.yyyxx.cloud (10.1.8.11) 56(84) bytes of data...

# 3. 测试反向解析：IP→域名
nslookup 10.1.8.11  
# 输出：11.8.1.10.in-addr.arpa	name = client.yyyxx.cloud.
#       11.8.1.10.in-addr.arpa	name = student.yyyxx.cloud.（因为反向解析里 10.1.8.11 对应两个域名）

四、一句话总结

用 BIND 配置 yyyxx.cloud 的 DNS 解析，就是：

正向 zone 文件：给 yyyxx.cloud 的子域名分配 IP（像 “给商品贴货架号”），支持 A 记录（域名→IP）、CNAME（别名）、MX（邮件服务器）等。
反向 zone 文件：给 10.1.8.x 的 IP 贴域名标签（像 “给货架号写商品名”），让别人查 IP 时知道对应的域名。
客户端把 DNS 指向你的服务器，就能通过域名访问，或通过 IP 查域名啦～
mcli connection modify ens33 ipv4.dns 10.1.8.10
nmcli connection up ens33

2. 测试正向解析：域名→IP

ping student.yyyxx.cloud # 实际会解析到 client.yyyxx.cloud（10.1.8.11），因为 student 是别名

输出：PING client.yyyxx.cloud (10.1.8.11) 56(84) bytes of data…

3. 测试反向解析：IP→域名

nslookup 10.1.8.11

输出：11.8.1.10.in-addr.arpa name = client.yyyxx.cloud.

11.8.1.10.in-addr.arpa name = student.yyyxx.cloud.（因为反向解析里 10.1.8.11 对应两个域名）


### 四、一句话总结

用 BIND 配置 `yyyxx.cloud` 的 DNS 解析，就是：

- **正向 zone 文件**：给 `yyyxx.cloud` 的子域名分配 IP（像 “给商品贴货架号”），支持 A 记录（域名→IP）、CNAME（别名）、MX（邮件服务器）等。
- **反向 zone 文件**：给 `10.1.8.x` 的 IP 贴域名标签（像 “给货架号写商品名”），让别人查 IP 时知道对应的域名。
- 客户端把 DNS 指向你的服务器，就能通过域名访问，或通过 IP 查域名啦～

DHCP 服务器与DNS服务器