一、DNS(域名系统)详解
1. 核心功能与特点
| 特性 | 说明 | 
|---|---|
| 核心作用 | 将域名(如 www.example.com)转换为 IP 地址(如192.168.1.1),实现人类可读地址与机器可读地址的映射。 | 
| 端口与协议 | - 默认端口:53(同时支持 UDP 和 TCP)。 - UDP:快速查询(适用于大部分场景)。 - TCP:数据量较大时(如 DNSSEC 查询或区域传输)使用。 | 
| 分布式数据库 | 全球分布式部署,无单点故障,由根服务器、顶级域服务器、权威服务器等层级构成。 | 
| 查询类型 | - 递归查询:客户端向本地 DNS 服务器发起请求,由服务器完成全部查询。 - 迭代查询:服务器仅返回下一级服务器地址,由客户端逐步查询。 | 
2. DNS 查询流程示例
-  用户输入域名:访问 www.example.com。
-  本地 DNS 查询:客户端向本地 DNS 服务器(如 ISP 提供)发起请求。 
-  根域名服务器:本地 DNS 向根服务器查询 .com顶级域服务器的地址。
-  顶级域服务器:根服务器返回 .com服务器的地址,本地 DNS 向.com服务器查询example.com的权威服务器。
-  权威服务器:顶级域服务器返回 example.com的权威 DNS 地址,本地 DNS 向其查询www子域的 IP。
-  返回结果:权威服务器返回 www.example.com的 IP,本地 DNS 缓存并返回给客户端。
3. DNS 记录类型
| 记录类型 | 作用 | 示例 | 
|---|---|---|
| A | 将域名指向 IPv4 地址。 | www.example.com → 192.168.1.1 | 
| AAAA | 将域名指向 IPv6 地址。 | www.example.com → 2001:db8::1 | 
| CNAME | 域名别名(指向另一个域名)。 | blog.example.com → www.example.com | 
| MX | 邮件服务器地址。 | example.com → mail.example.com | 
| TXT | 存储文本信息(如 SPF、DKIM 记录)。 | v=spf1 include:_spf.example.com ~all | 
| NS | 指定域名的权威 DNS 服务器。 | example.com → ns1.example-dns.com | 
4. 安全问题与防护
| 威胁 | 防护措施 | 
|---|---|
| DNS 劫持 | 篡改 DNS 响应,引导用户至恶意网站。解决方案:使用 DNSSEC(数字签名验证响应真实性)。 | 
| DNS 污染 | 伪造 DNS 查询结果。解决方案:配置可信的 DNS 服务器(如 Google DNS 8.8.8.8)。 | 
| DDoS 攻击 | 攻击 DNS 服务器导致服务瘫痪。解决方案:部署 Anycast 网络分散流量压力。 | 
二、因特网域名结构
1. 域名层次结构
域名采用树状分层结构,从右到左层级递增,格式为:子域名.二级域名.顶级域名.根域
 示例:mail.server.example.com.
在 “mail.server.example.com.” 里,“mail” 和 “server” 都是子域名,“example” 是 二级域名,“.com” 就是顶级域名,根域名以一个点 “.” 来表示。
例如,我们常见的域名 “baidu.com”,其完整的写法其实是 “bidu.com.”,最后的点代表根域名,只是在日常使用和书写时习惯性省略。
-  根域:隐含的 .(通常省略)。
-  顶级域(TLD):如 .com、.cn。
-  二级域:用户注册的域名(如 example.com)。
-  子域:用户自定义的分支(如 mail.example.com)。
2. 顶级域名(TLD)分类
| 类别 | 说明 | 示例 | 
|---|---|---|
| 国家顶级域(ccTLD) | 基于 ISO 3166 国家代码,表示特定国家或地区。 | .cn(中国)、.us(美国)、.jp(日本) | 
| 通用顶级域(gTLD) | 面向全球的通用类别,早期仅限特定用途,现扩展至数千种。 | .com(商业)、.org(组织)、.net(网络)、.edu(教育机构) | 
| 新通用顶级域(nTLD) | 2012 年后开放申请,涵盖行业、品牌、兴趣等。 | .app(应用)、.blog(博客)、.io(科技公司) | 
| 基础结构域 | 唯一反向解析域,用于 IP 到域名的映射。 | .arpa(反向解析,如1.168.192.in-addr.arpa) | 
3. 域名管理架构
| 机构/角色 | 职责 | 
|---|---|
| ICANN | 全球域名系统的最高管理机构,负责分配顶级域名和 IP 地址。 | 
| 注册局(Registry) | 管理特定顶级域(如 Verisign 管理 .com),维护域名数据库。 | 
| 注册商(Registrar) | 向用户提供域名注册服务(如 GoDaddy、阿里云)。 | 
| 注册人(Registrant) | 域名实际拥有者,支付费用并配置 DNS 记录。 | 
4. 域名解析示例
以 www.example.cn 为例:
-  根服务器:指引查询 .cn顶级域服务器。
-  顶级域服务器(.cn):指引查询 example.cn的权威服务器。
-  权威服务器(example.cn):返回 www子域的 A 记录 IP 地址。
三、域名服务器的类型划分

1、根域名服务器(Root Name Server)
-  核心作用: -  管理根域( .),存储所有顶级域名服务器(TLD)的地址信息。
-  指导本地域名服务器下一步应查询的顶级域服务器,不直接解析最终IP。 
 
-  
-  全球分布: -  IPv4根服务器:共13台(1台主根在美国,其余12台辅根分布美、欧、日)。 
-  IPv6根服务器(雪人计划):新增25台,中国部署4台(1主根+3辅根),打破无根服务器历史。 
 
-  
-  管理权: -  由 ICANN 统一管理,负责全球互联网域名与IP地址的协调。 
 
-  
-  重要性: -  根服务器瘫痪将导致全球DNS系统失效,是互联网核心基础设施。 
 
-  
2、顶级域名服务器(TLD Name Server)
-  职责: -  管理特定顶级域(如 .com、.cn、.org),返回对应二级域名的权威服务器地址。
-  分类: -  国家顶级域(ccTLD):如 .cn(中国)、.us(美国)。
-  通用顶级域(gTLD):如 .com(商业)、.edu(教育)。
 
-  
 
-  
-  协作流程: -  根服务器 → 顶级域名服务器 → 权威域名服务器 → 完成解析。 
 
-  
3、权威域名服务器(Authoritative Name Server)
-  功能: -  管理特定区(Zone)的完整DNS记录(如 example.com区的A、MX、CNAME记录)。
-  “区”与“域”: -  一个域(Domain)可划分为多个区(Zone),每个区由独立的权威服务器管理。 
 
-  
 
-  
-  部署模式: -  通常以主从架构运行,主服务器负责数据修改,从服务器同步数据提供冗余。 
 
-  
4、本地域名服务器(Local DNS Server)
-  角色: -  直接接收客户端查询请求(如浏览器、手机),执行递归解析。 
-  不属于层次结构,但作为查询入口,向根、顶级、权威服务器发起迭代查询。 
 
-  
-  常见类型: -  ISP提供的公共DNS(如 8.8.8.8)、企业内网DNS、家庭路由器内置DNS。
 
-  
5、主从DNS服务器(Master/Slave Server)
| 类型 | 职责 | 特点 | 
|---|---|---|
| 主DNS服务器 | 存储区数据的原始副本,允许管理员修改记录。 | - 数据变更后触发区域传输(AXFR/IXFR)。 - 唯一可写节点。 | 
| 从DNS服务器 | 从主服务器同步数据,提供只读解析服务。 | - 自动同步,保障高可用性。 - 主故障时可接管查询。 | 
-  同步机制: -  全量传输(AXFR):首次同步或强制更新时复制全部数据。 
-  增量传输(IXFR):仅同步变更部分,减少带宽消耗。 
 
-  
关键协作流程示例
-  用户访问 www.example.cn:-  本地DNS服务器向根服务器查询 .cn顶级域服务器地址。
-  根服务器返回 .cn服务器地址,本地DNS转向查询.cn服务器。
-  .cn服务器返回example.cn的权威服务器地址。
-  本地DNS向权威服务器查询 www子域IP,返回结果并缓存。
 
-  
-  主从同步: -  主服务器更新记录后,通知从服务器发起IXFR请求同步数据。 
 
-  
四、DNS域名解析的过程

DNS域名解析过程如下 :
-  客户端浏览器接收到IP地址后,使用这个IP地址与目标主机建立连接。 
-  浏览器向目标主机发送一个HTTP请求,然后接收并显示目标主机返回的网页内容。 
-  这个过程涉及到多个层次的域名服务器之间的交互和查询,目的是将用户输入的域名转换成可访问的IP地址。 
-  在整个过程中,缓存的存在大大提高了解析效率,减少了网络流量和查询时间。 
-  客户机向本地域名服务器的查询一般采用递归查询。 
-  当本地的域名服务器收到请求之后,就先查询本地的域名缓存,如果有该记录项,则本地的域名服务器就直接把查询的结果返回。 
-  如果本地的缓存中没有该及录项,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域的主域名服务器的IP。 
-  本地服务器再向上一步返回的域名服务器发送请求,然后接受请求的服务器查询自己的域名缓存,如果没有该记录项,则返回相关的下一级域名服务器的地址。 
-  重复步骤八,直到找到正确的记录。 
-  本地域名服务器把返回的结果保存到域名缓存,以备下一次使用,同时将结果返回给客户机。 
五、DNS的分布式特性
DNS(域名系统)的分布式特性是其设计的核心,旨在高效、可靠地将域名解析为IP地址。以下是DNS分布式架构的详细解析:
1. DNS的层次化分布式结构
DNS通过分层结构实现分布式管理,主要分为以下层级:
-  根域名服务器(Root Servers):全球共13组根服务器(逻辑上非物理),存储顶级域(如.com、.org)的服务器地址。 
-  顶级域名服务器(TLD Servers):管理特定顶级域(如 .com、.cn)下的权威服务器信息。
-  权威域名服务器(Authoritative Servers):直接管理具体域名的IP地址记录(如 example.com的A记录)。
-  本地DNS服务器(递归解析器):由ISP或企业提供,负责接收用户查询并递归遍历层级获取结果。 
分布式优势:
-  负载均衡:查询请求分散到不同层级的服务器,避免单点过载。 
-  冗余容灾:每个层级有多个服务器实例,故障时自动切换。 
-  本地化解析:本地DNS缓存常用查询结果,减少跨层级请求。 
2. DNS缓存机制
-  本地缓存:本地DNS服务器和客户端(如浏览器)会缓存解析结果,有效期内直接返回,减少查询延迟。 
-  TTL控制:每条DNS记录设置生存时间(Time-to-Live),超时后重新查询以保持数据更新。 
示例:
-  用户首次访问 example.com,本地DNS服务器向根服务器、TLD服务器、权威服务器逐级查询,获取IP地址并缓存。
-  后续请求直接从本地缓存返回,直至TTL过期。 
3. 分布式DNS的优势
-  高可用性:全球分布的服务器集群确保即使部分节点故障,解析服务仍可用。 
-  快速响应:就近访问原则,用户请求优先由地理或网络位置最近的服务器处理。 
-  灵活扩展:新增域名只需在权威服务器配置,无需修改全局架构。 
4. 分布式DNS的挑战
-  安全性问题: -  DNS劫持:攻击者篡改解析结果(如中间人攻击)。 
-  DDoS攻击:通过大量查询请求瘫痪服务器。 
-  解决方案:DNSSEC(DNS安全扩展)通过数字签名验证数据真实性。 
 
-  
-  数据一致性: -  修改DNS记录后,全球缓存需要等待TTL过期才能同步,可能导致短暂不一致。 
 
-  
-  隐私泄露: -  DNS查询可能暴露用户访问记录,可通过DoH(DNS over HTTPS)加密传输。 
 
-  
5. DNS与其他分布式系统的对比
| 特性 | DNS | 区块链 | CDN | 
|---|---|---|---|
| 数据存储 | 分层分布式数据库 | 去中心化账本 | 分布式内容缓存 | 
| 一致性模型 | 最终一致性(依赖TTL) | 强一致性(共识算法) | 最终一致性(缓存更新) | 
| 主要目标 | 高效域名解析 | 不可篡改的交易记录 | 加速内容分发 | 
| 典型应用 | 互联网基础服务 | 加密货币、智能合约 | 视频流媒体、网站加速 | 
六、DNS服务器的配置
1、安装 BIND(Berkeley Internet Name Domain)DNS 服务器
BIND 是一款广泛应用的开源 DNS 服务器软件。
说明:root@dns1的IP地址为192.168.52.50/24;root@dns2的IP地址为192.168.52.60/24


2、在防火墙的永久配置里添加 DNS 服务,并且让 named 服务(即 BIND DNS 服务器)立即启动,同时设置了系统启动时自动运行。
 
然后使用 systemctl status named 查看 named 服务的运行状态。
服务处于 active (running) 状态,说明 BIND DNS服务器 已成功启动并正在运行。


3、修改dns的配置文件

注:修改完dns的配置文件后,需要重启 named 守护进程,才能立即使配置文件生效。
具体操作看下图中前两行命令。
下面两图分别为查询成功和查询的域名不存在的示例。


4、dns高速缓存的测试
在两台测试主机---dns1和dns2中指定DNS服务器地址都为主机dns1的IP地址。


测试过程(如下图):


 dns高速缓存解析
 
在这两台主机上指定相同的 DNS 服务器地址后,第二台主机测试域名解析耗时为 0 毫秒,实现加速,主要有以下原因:
缓存机制
-  DNS 服务器缓存:DNS 服务器通常会缓存之前解析过的域名 - IP 地址映射信息。当第一台主机( dns1)向192.168.52.50这个 DNS 服务器查询www.qq.com时,DNS 服务器完成解析后会将结果缓存起来。当第二台主机(dns2)紧接着查询www.qq.com时,DNS 服务器直接从缓存中读取结果并返回,无需再次进行复杂的递归查询过程(从根域名服务器开始逐级查找 ),极大缩短了解析时间,所以耗时可能显示为 0 毫秒 。
-  本地客户端缓存:在某些情况下,如果客户端(主机上的操作系统等 )也启用了 DNS 缓存机制,第一台主机查询后,相关缓存可能也会被第二台主机利用(比如在同一网络环境且有共享缓存机制等 ),或者第二台主机自身的缓存刚好命中了该域名的解析结果,也能加快解析速度 。 
报错信息解析:dns高速缓存测试报错信息
报错1:
可能导致的原因:
1.named服务没开,或没安装
2.火墙
3、dns本身设置未开放网络功能(端口未在ip上开放)报错2:
可能导致的原因:1.dns的配置中限制了当前主机访问服务的请求
七、搭建DNS正向解析
1、添加配置片段
首先,在 BIND DNS服务器的主配置文件 /etc/named.conf 和 子配置文件 /etc/named.rfc1912.zones 中添加配置片段。
主流做法是只在子配置文件中添加区域配置片段,这里是为了演示才在两个文件中都进行了配置。



主配置文件 vs 子配置文件:在哪个文件中添加区域配置片段的优缺点对比
| 场景 | 直接在主配置文件中添加 | 通过子配置文件引入 | 
|---|---|---|
| 配置复杂度 | 适合简单场景(如单区域)。 | 适合多区域场景,便于模块化管理。 | 
| 可读性与维护性 | 配置集中在一个文件,可能显得冗长。 | 按功能拆分文件(如 zones、acls),结构清晰。 | 
| 默认实践 | 非标准做法(主流发行版默认使用子文件)。 | 符合 BIND 最佳实践,便于系统升级和管理。 | 
| 权限与安全性 | 无本质区别,但主文件修改需谨慎(误操作可能影响全局配置)。 | 子文件可单独控制权限(如仅允许特定用户修改区域配置)。 | 
为什么主流做法使用子配置文件?
1. 配置模块化
- 将区域配置(zone)、访问控制(acl)、日志规则等拆分到不同文件,避免主文件过于臃肿。
 例如:// 主配置文件 `/etc/named.conf` include "/etc/named.options"; // 全局选项 include "/etc/named.zones"; // 区域配置 include "/etc/named.acls"; // ACL 规则
2. 系统兼容性
- 多数 Linux 发行版(如 CentOS、Ubuntu)默认通过 include指令引用/etc/named.rfc1912.zones作为区域配置文件。
- 直接修改主文件可能与系统升级或包管理工具(如 yum)产生冲突(工具可能覆盖主文件)。
3. 权限隔离
- 子文件可单独设置权限(如 chmod 640 /etc/named.zones),限制非管理员用户修改特定区域配置。
2、编写相应的区域文件
其次,要创建timinglee.org.zone这个文件,确保这个区域文件存在而且格式正确,所以下面我们选择直接将 BIND 的本地回环区域文件(通常用于 localhost 解析)复制为 timinglee.org 的区域文件,然后对这个区域文件再进行进一步修改以适配实际需求。
具体操作如下:
因为,/var/named/named.localhost的权限比较特殊,所以我们使用cp命令复制的时候要加上-p选项,将原文件的权限、所有者、组、时间戳等元数据等也一同复制。这对于复制系统配置文件(如 BIND 的区域文件)非常重要。

下图为刚复制过来的文件,实际配置还是为/var/named/named.localhost的配置,还未根据实际需求进行修改。
下图中的refresh、retry、expire 和 minimum 分别代表 刷新时间、重试时间、过期时间 和 A记录最短有效期,如果$TTL被设定那么以设定值为准。

下面将对区域文件/var/named/timinglee.org.zone进行修改,修改为下图这样子。

3、最后,重启服务,然后进行dns正向解析的测试
最后,我们使用systemctl restart named命令重启服务,然后进行dns正向解析的测试。
发现被写入区域文件的www.timinglee.org和bbs.timinglee.org可以进行访问,而没有写进区域文件的haha.timinglee.org则显示查询的域名不存在。
测试主机dns1 指定的 DNS 服务器的 IP 地址为自身的IP地址。

测试过程如下图:



八、辅助dns
1、部署辅助dns的方法
这里我们使用测试主机dns2来进行辅助dns的部署


测试主机dns1和dns2分别为主DNS和辅助DNS,将它们各自的DNS服务器指定为自己的IP地址。


在 BIND(Berkeley Internet Name Domain)DNS 服务器中,/var/named/slaves/ 目录是 辅助 DNS 服务器(Slave DNS) 用于存储 从主服务器同步的区域数据文件 的默认路径。



2、辅助dns的数据同步优化
进行辅助dns数据同步优化的原因:
当主dns在更新域名的A记录辅助dns默认是不同步的,这样就会出现数据差异,使用辅助dns服务器作为解析服务器的用户得到的地址就是错误的。
解决方法:
让主dns主动通知辅助dns,让辅助dns知道主dns的A记录已经被更改,请同步数据到辅助dns上即可。
在进行完下图的配置后,要前往 /etc/named.conf 这个主配置文件将关于 timinglee.org 的区域配置删除,否则会让DNS 配置出现 区域重复定义 的问题,导致 BIND 无法启动。

使用区域配置文件中的serial值来进行同步数据,此值变化代表A记录更新。
serial值只能做增量变化,最大10位数。


在主dns中重启服务,再访问 www.timinglee.org ,发现域名解析出来的IP地址变成了192.168.52.100。
而辅助dns中连重启服务都不需要,直接就会向主dns同步数据,所以域名解析出来的IP地址也会变成192.168.52.100。























