Linux网络服务(三)——DNS域名解析服务

前言

域名系统（DNS）是互联网的核心基础设施之一，扮演着“互联网导航员”的关键角色。它实现了人类易于记忆的域名与机器用于寻址的IP地址之间的相互转换，是所有网络应用访问的起点。本文档系统阐述了DNS的工作原理、系统架构、服务器类型及详细的部署配置方法，旨在为网络管理员和技术爱好者提供一份全面、清晰的参考指南。

一、DNS 概述与核心作用

1.1 DNS 的角色（重点）

DNS (Domain Name System) 是互联网的“导航员”。它的核心作用是实现域名与 IP 地址之间的相互映射。

• 正向解析: 根据域名查找对应的 IP 地址（最常用）。
• 反向解析: 根据 IP 地址查找对应的域名（用于特殊用途，如邮件服务器及垃圾验证）。

1.2 端口与协议

• 默认端口：53
• 使用协议：
  • UDP: 用于常规的域名解析查询。速度快，开销小。
  • TCP: 用于区域传送（主从服务器同步数据）。因为TCP更可靠，能保证大数据量的准确传输。

1.3 域名结构：FQDN

• FQDN (Fully Qualified Domain Name，完全合格域名): 全限定域名，完整标识主机在域名树中的位置。
• 格式：主机名、子域、二级域、顶级域、根域。（根域，通常省略）
• 示例：www.sina.com.cn -> www.sina.com.cn. (根域以点表示)

---

图解：域名空间层次结构

二、DNS 查询原理（重点）

2.1 两种查询方式

2.1.1 递归查询 (Recursive Query)

• 客户机与本地DNS服务器之间的查询方式。
• 客户机发出请求后，只需等待最终结果（成功或失败），中间的所有查询过程由DNS服务器代理完成。
• 一句话：“你办事，我放心，我只要结果”。

2.1.2 迭代查询 (Iterative Query)

• 本地DNS服务器与其它各级DNS服务器之间的查询方式。
• 上级服务器不会替下级服务器去查询，而是返回一个最佳查询点（另一台DNS服务器的地址），让请求者自己再去问。
• 一句话：“这个我不直接管，你去问XX办公室吧”。

2.2 完整的正向解析流程

以www.google.com为例解析为IP地址的过程，主要涉及递归查询和迭代查询两种方式，各服务器角色分工明确：

• 步骤1：客户端发起递归查询

  • 客户端向本地DNS服务器发起递归查询请求，查询www.google.com的IP地址。

• 步骤2：本地DNS服务器先自查

  • 本地DNS服务器首先检查自身的本地缓存和hosts文件，看是否有www.google.com对应的IP记录。如果有，直接返回；如果没有，进入下一步。

• 步骤3：本地DNS服务器向根DNS服务器发起迭代查询

  • 本地DNS服务器向根DNS服务器发起迭代查询，询问www.google.com的IP。根DNS服务器没有直接的记录，会建议本地DNS服务器去查询.com顶级域服务器的地址。

• 步骤4：本地DNS服务器向顶级域服务器发起迭代查询

  • 本地DNS服务器根据建议，向**.com顶级域服务器发起迭代查询。顶级域服务器同样没有直接记录，会建议**本地DNS服务器去查询google.com的权威服务器（二级域服务器）地址。

• 步骤5：本地DNS服务器向二级域服务器发起迭代查询

  • 本地DNS服务器再向**google.com二级域服务器**发起迭代查询。这次，二级域服务器有www.google.com的记录，会返回其对应的IP地址。

• 步骤6：本地DNS服务器返回结果并缓存

  • 本地DNS服务器拿到www.google.com的IP后，一方面将结果以递归响应的方式返回给客户端；另一方面，会把这个IP记录缓存起来，方便后续查询使用。

一句话总结：

• 递归查询：
  • 客户端只发一次请求·要求对法直接出最终结果
• 迭代查询：
  • 客户端他发出一次请求，如果对方没有授权回答，他就会返回一个能解答这个査询的其他的服务名称列表(根服务器、顶级域、权威域)，最终他会提供一个解析的结果

缓存清理命令：

• Windows: ipconfig /displaydns (查看缓存), ipconfig /flushdns (清理缓存)
• Linux: 需安装 nscd 服务，使用 nscd -i hosts 清理。

三、DNS服务器架构与类型

3.1 分布式层次结构

全球DNS系统是一个庞大的分布式数据库，由众多服务器共同承担解析任务。

服务器类型	职责	举例
根DNS服务器	管理根域，返回顶级域服务器的地址	全球13个根服务器系统集群（编号A-M）
顶级域DNS服务器	管理特定顶级域，返回权威服务器地址	.com, .cn, .net 服务器
权威DNS服务器	管理特定域名（如google.com），返回其下主机的最终IP	ns1.google.com

重要提示： 所谓的“全球13台根服务器”指的是13个逻辑根服务器系统，每个系统都通过任播技术在全球部署了上百台物理服务器副本，以提高 resiliency (弹性) 和访问速度。中国也有多个根镜像服务器。

3.2 DNS服务器软件（BIND）

• BIND (Berkeley Internet Name Domain)： 是最广泛使用的DNS服务软件。
• 软件包组成：
  • bind: 主程序包
  • bind-utils: 提供 nslookup, dig 等测试工具
  • bind-libs: 提供库文件
  • bind-chroot: 提供一个伪根目录，将DNS服务锁定在 /var/named/chroot/ 中，增强安全性。

3.3 DNS服务器系统类型

根据职能，一台物理DNS服务器可以被配置为以下一种或多种类型：

类型	作用	特点
主域名服务器	维护特定区域的权威数据，数据可修改	type master;
从域名服务器	从主服务器同步区域数据，提供冗余备份和负载均衡	type slave; 需指定 masters{};
缓存域名服务器	不管理任何区域，仅缓存查询结果，加速访问	必须指定根域或转发器
转发域名服务器	将所有非本地查询请求转发给指定的其他DNS服务器	配置 forwarders {};

四、域名备案流程

域名备案的过程 企业备案(个人可以在阿里云做个人备案)：

1、备案前的准备:注册并且实名认证阿里云/腾讯云账号;注册实名认证域名，准备好服务器(公网IP)。

2、提交备案申请:登录阿里云/腾讯云ICP代备案管理系统(填写主办者信息、网站信息等)，上传相关资料，通过阿里云进行实际人核验,并且确认信息无误后提交初审。

3、审核阶段:阿里云审核一般在1天，初审通过后，工信部发送短信验证码，需要在24小时完成核验之后进入管局审核，最长20-30天， 快的10-15天。
4、备案成功:收到短信和邮件通知，获取ICP备案号，需要在网站首页底部悬挂备案号并且生成链接指向工信部网站。

5、公安联网部门:ICP备案成功后，在开通网站之日起30天办理公安联网备案。

五、DNS部署实战

搭建目的：了解根域服务器解析过程

5.1 核心配置文件

1. 主配置文件: /etc/named.conf 定义全局设置，如监听地址、允许查询的网段。
2. 区域配置文件: /etc/named.rfc1912.zones 定义本服务器负责管理的区域（域名）及其属性（如区域数据文件名、类型）。
3. 区域数据文件: /var/named/xxx.zone 存储具体的域名和IP的映射记录，这是最核心的数据库文件。

5.2 记录类型详解

• SOA: 起始授权记录，定义区域全局信息（主服务器、管理员邮箱、序列号、同步参数）。
• NS: 域名服务器记录，指明该区域由哪台DNS服务器负责解析。
• A: 正向解析记录，将域名指向一个IPv4地址。
• AAAA: 将域名指向一个IPv6地址。
• CNAME: 别名记录，将一个域名指向另一个域名。
• MX: 邮件交换记录，定义邮件服务器的域名和优先级。
• PTR: 反向解析记录，将IP地址指向域名。

5.3 配置流程（以BIND为例）：

1、 安装BIND: yum install bind bind-chroot -y

2、 编辑主配置文件 named.conf，设置 listen-on 和 allow-query。
3、 在区域配置文件 named.rfc1912.zones 中定义正向和反向区域。

修改主要配置文件 
vim /etc/named.conf
options {
listen-on port 53 { 192.168.10.110; }; ●监听53端口，ip地址使用提供服务的本地IP，也可用any表示所有
#listen-on-v6 port 53 { ::1; }; #ipv6行如不使用可以注释掉或者删除
directory "/var/named";     #区域数据文件的默认存放位置
dump- file "/var/named/data/cache_dump.db"; #域名缓存数据库文件的位置
statistics-file "/var/named/data/named stats.txt"; #状态统计文件的位置
memstatistics-file "/var/named/data/named mem stats.txt"; # 内存统计文件的位置
allow-query { 192.168.10.0/24; 192.168.100.0/24; };● 允许使用本DNS解析服务的网段，也可用any代表所有
}zone "." IN {#正向解析"."根区域
type hint;#类型为根区域
file "named.ca";#区域数据文件为named.ca，#记录了13台根域服务器的域名和IP地址等信息
}；include "/etc/named.rfc1912.zones"; #包含区域配置文件里的所有配置修改

(3)修改区域配置文件，添加正向区域配置
vim /etc/named.rfc1912.zones  
#文件里有模版，可复制粘贴后修改
zone "simon.com." IN        {●正向解析"simon.com"区域
type master;#类型为主区域
file "simon.com.zone.";    ●指定区域数据文件为simon.com.zone
allow-update { none; } ;
};

配置正向区域数据文件
cd /var/named/
cp -p named.localhost simon.com.zone   #保留源文件的权限和属主的属性复制
vim /var/named/simon.com.zone
$TTL 1D    #有效解析记录的生存周期
@   IN SOA simon.com. admin.simon.com. (   #“@"符号表示当前的DNS区域名0   ; serial              #更新序列号，可以是10位以内的整数1D   ; refresh             #刷新时间,重新下载地址数据的间隔1H   ; retry               #重试延时，下载失败后的重试间隔1W   ; expire              #失效时间,超过该时间仍无法下载则放弃#3H)  ; minimum             #无效解析记录的生存周期，NS     simon.com.                     #记录当前区域的DNS服务器的名称A     192.168.10.110                  #记录主机IP地址
IN   MX 10    mail.simon.com.            #MX为邮件交换记录，数字越大优先级越低
www  IN A     192.168.10.110              #记录正向解析www.simon.com对应的IP
mail IN A     192.168.10.111              #MX为邮件交换记录，数字越大优先级低 
ftp  IN CNAME  www                       #CNAME使用别名，ftp 是www的别名
*    IN A   192.168.10.112               #泛域名解析，“*"代表任意主机名#“@”这里是一个变量，当前DNS区域名
#SOA记录中的更新序列号用于同步主、从服务器的区域数据，当从服务器判断区域更新时，若发现主服务器中的序列号与本地区域数据中的序列号相同，则不会进行下载。
# "simon.com. "此为完全合格域名(FQDN) ，后面有个“."不能漏掉
#“admin.simon.com.”表示管理员邮箱，这里的“@”符号已有其他含义，所以用“.”代替
#IN 表示internet

(5)启动服务，关闭防火墙
systemctl start named
systemctl stop firewalld
setenforce 0
#如果服务启动失败，可以查看日志文件来排查错误
tail -f /var/log/messages
#如果服务启动卡住，可以执行下面命令解决
rndc-confgen -r /dev/urandom -a#对域名语法进行检查（named.conf）
named-checkconf -z /etc/named.conf

(6)在客户端的域名解析配置文件中添加DNS服务器地址
vi /etc/resolv.conf
#修改完后立即生效
nameserver 192.168.10.110
或
vi /etc/sysconfig/network-scripts/ifcfg-ens33
#修改完后需要重启网卡
DNS1=192.168.10.110
systemctl restart network

(7)测试DNS解析
systemctl restart named
host www.simon.com
nslookup www.simon.com
nslookup mail.simon.com
nslookup zhangsan.simon.com

扩展内容：反向解析

vim /etc/named.rfc1912.zones
// 192.168.10.0 反向则是 10.168.192
zone "10.168.192.in-addr.arpa" IN {type master;file "simon.com.zone.local";    //指定反向解析的数据文件，也可以跟正向解析的数据文件相同allow-update { none; };
};

cd /var/named/
cp -p simon.com.zone simon.com.zone.local
vim simon.com.zone.local
$TTL 1D   #有效解析记录的生存周期，默认单位为秒
@       IN SOA  simon.com. admin.simon.com. (    #SOA标记、域名和管理员邮箱，@变量表示域名0       ; serial      #更新序列号，10位以内数字，用于主从同步，主服务器这个数值要大于从服务器否则无法同步1D      ; refresh  #刷新时间1H      ; retry     #重试刷新时间间隔1W      ; expire   #失效时间，超过该时间则放弃3H )    ; minimum   #无效解析记录的生存周期NS     simon.com.A      192.168.10.110
110 IN   PTR    www.simon.com.
111 IN   PTR    mail.simon.com.
# 100是192.168.10.100的意思
# RTP反向指针 功能：反向解析

systemctl restart named   //rndc reload也可以重载配置文件
host 192.168.10.110
// 将会反向解析出域名www.simon.com

六、附录：重要概念补充

• IANA/ICANN: 全球顶级IP地址和域名资源的管理机构。
• CNNIC: 中国互联网络信息中心，管理国家顶级域 .cn。
• 常见公共DNS:
  • 114.114.114.114 (国内)
  • 8.8.8.8 (Google)
  • 223.5.5.5 / 223.6.6.6 (阿里云)
• IPv6与根服务器: IPv6协议和新的DNS架构（如根服务器数量可能增加）为改变全球根服务器分布格局提供了可能性。中国正在积极研究相关技术。

---

七、以百度为例，客户端访问服务端流程

要理解客户端（如电脑或手机浏览器）访问百度服务器的完整流程，可以基于OSI七层模型进行分析。整个过程的核心在于"下行封装"（客户端数据自上而下打包）和"上行解封装"（服务器数据自下而上拆包）。我将按照"整体概述→分层解析→响应流程"的顺序，结合访问百度的实际场景进行详细说明。

7.1 前置知识：OSI七层模型与核心逻辑

OSI七层模型从顶层（用户交互）到底层（硬件传输）依次为：应用层→表示层→会话层→传输层→网络层→数据链路层→物理层。
访问流程的本质是：

• 客户端请求：数据从应用层向下传递，每经过一层，该层会添加“本层头部信息”（封装），最终以“比特流”形式通过物理介质传输；
• 服务端响应：数据从物理层向上传递，每经过一层，该层会剥离“本层头部信息”（解封装），最终到达应用层被服务端处理，再反向重复封装→传输→解封装流程返回客户端。

7.2 客户端访问百度的分层流程（请求阶段）

以“你在电脑浏览器输入www.baidu.com并按下回车”为例，拆解每一层的具体作用：

7.2.1 应用层：发起访问请求

• 核心作用：提供用户与网络的交互接口，定义应用程序间的通信规则（如HTTP/HTTPS）。
• 百度访问实例：
  1. 你输入www.baidu.com（域名），浏览器（应用程序，如Chrome）首先需要将“域名”转换为“IP地址”（因为电脑只能识别IP），这一步依赖DNS协议（域名系统）：
     • 浏览器先查本地DNS缓存（如电脑 hosts 文件），若没有则向路由器DNS、ISP（运营商）DNS服务器请求，最终通过“根DNS→.com顶级域DNS→百度权威DNS”，获取百度服务器的IP（如180.101.50.188，实际IP会动态变化）。
  2. DNS解析成功后，浏览器发起HTTPS请求（当前百度默认用HTTPS，比HTTP更安全），请求内容包括：“获取百度首页的HTML/CSS/JS资源”“浏览器信息（如Chrome版本）”“Cookie”等。
• 数据单元：原始数据（Data）。
• 核心协议：HTTP/HTTPS、DNS。

7.2.2 表示层：处理数据格式与加密

• 核心作用：统一数据格式（如将浏览器的请求数据转为服务端可识别的格式）、实现数据加密/解密（保障传输安全）。
• 百度访问实例：
  HTTPS协议通过TLS/SSL加密机制（HTTPS的核心安全技术）对HTTP请求进行加密保护（例如采用RSA算法生成会话密钥），有效防止传输过程中的数据泄露或篡改风险；同时，浏览器会严格验证百度服务器的SSL证书（确保访问的是"真实百度"，而非仿冒网站）。
• 数据单元：加密后的结构化数据。

7.2.3 会话层：建立与管理通信会话

• 核心作用：建立、维护、终止客户端与服务端的“通信会话”（类似打电话时的“接通→保持通话→挂断”）。
• 百度访问实例：
  会话层会在"浏览器与百度服务器"之间建立专属会话。
• 数据单元：带会话标识的数据。

7.2.4 传输层：确保数据可靠传输

• 核心作用：将上层数据分割为“段”，通过端口号定位应用程序，选择传输协议（TCP/UDP），保障数据“可靠/快速”传输。
• 百度访问实例：
  1. 选择TCP协议（Web服务需“可靠传输”，即数据不能丢、不能乱序；UDP适合直播等实时场景，允许少量丢包）。
  2. 建立TCP三次握手（确保客户端与服务端能双向通信）：
     • 客户端（浏览器）：“我要连你的443端口（HTTPS默认端口），能收到吗？”（SYN包）；
     • 百度服务器：“能收到！我也要连你的随机端口（如54321，客户端随机生成，避免端口冲突），你能收到吗？”（SYN+ACK包）；
     • 客户端：“能收到！开始传数据吧！”（ACK包）。
  3. 给数据添加“TCP头部”：包含源端口（54321） 和目的端口（443） 、序列号（确保数据按顺序重组）、确认号（确认收到数据）。
• 数据单元：TCP段（Segment）。
• 核心协议：TCP（可靠传输）、UDP（不可靠但快速）。

7.2.5 网络层：实现跨网络路由

• 核心作用：为数据分配“IP地址”，通过路由协议找到“从客户端到百度服务器的最优路径”，实现跨网络（如你家内网→运营商网络→百度机房网络）传输。
• 百度访问实例：
  1. 封装IP头部：包含源IP（你的电脑IP，如内网192.168.1.100） 和目的IP（百度服务器IP，如180.101.50.188） 。
  2. NAT转换：由于你的电脑用的是“内网IP”（仅在家庭路由器内有效），无法直接访问互联网，路由器会通过NAT协议将“内网IP:端口”（192.168.1.100:54321）转换为“公网IP:端口”（如202.97.xx.xx:6789），再对外传输。
  3. 路由选择：数据通过路由器、网关、骨干网路由器，根据IP协议和路由表（记录不同IP段的转发路径），逐步靠近百度服务器所在的机房网络。
• 数据单元：IP数据包（Packet）。
• 核心协议：IP（地址分配）、ICMP（网络诊断，如ping www.baidu.com）、ARP（后续数据链路层会用到）。

7.2.6 数据链路层：实现相邻设备通信

• 核心作用：将IP数据包封装为“帧”，通过MAC地址（设备的物理地址，如网卡地址）定位“相邻设备”（如客户端→路由器、路由器→下一级路由器），处理物理层的传输错误（如丢帧重传）。
• 百度访问实例：
  1. 封装帧头部/尾部：包含源MAC地址（你的电脑网卡MAC，如00:1A:2B:3C:4D:5E） 和目的MAC地址（相邻设备的MAC，如路由器的MAC地址） 。
  2. ARP协议获取MAC：若客户端不知道路由器的MAC地址，会发送“ARP广播”：“谁是192.168.1.1（路由器内网IP）？请告诉我你的MAC地址！”，路由器收到后回复自己的MAC，客户端记录到“ARP缓存表”中，后续通信直接使用。
  3. 数据以“帧”的形式在局域网内传输（如你家WiFi是802.11协议，网线是以太网协议）。
• 数据单元：帧（Frame）。
• 核心协议：以太网协议（网线）、802.11协议（WiFi）、ARP（MAC地址解析）。

7.2.7 物理层：传输比特流

• 核心作用：定义物理介质（如网线、光纤、无线电波）的电气特性（如电压、频率），将数据链路层的“帧”转换为“比特流”（0和1的电信号/光信号/无线电信号），通过物理介质传输。
• 百度访问实例：
  • 若你用WiFi：帧会转换为2.4GHz/5GHz的无线电波，通过空气传输到路由器；
  • 若你用网线：帧会转换为高低电平的电信号，通过网线传输到路由器；
  • 数据离开你家后，会通过运营商的“网线→光纤→骨干网光纤”传输到百度机房的交换机/路由器。
• 数据单元：比特流（Bit）。

7.3 服务端处理与响应流程（反向阶段）

当百度服务端的物理层收到客户端的比特流后，会启动“上行解封装”流程，反向处理数据：

1. 物理层→数据链路层：服务端交换机接收比特流，转换为帧，剥离帧头部，获取IP数据包，通过目标MAC地址确认“数据是发给自己的”；
2. 数据链路层→网络层：服务端路由器剥离IP头部，检查目的IP是否为百度服务器的IP，确认后将TCP段传递到传输层；
3. 网络层→传输层：服务端传输层（端口443）检查TCP段的序列号、确认号，验证数据完整性，剥离TCP头部，确认目的端口是自己的，将加密后的HTTP数据传递到表示层；
4. 传输层→表示层：服务端通过TLS/SSL协议解密数据，确认请求合法性（如Cookie验证），将解密后的HTTP请求传递到应用层；
5. 表示层→应用层：百度的Web服务器（如Nginx）处理HTTP请求，生成“百度首页的HTML/CSS/JS资源”作为响应数据；
6. 响应封装与传输：服务端将响应数据从“应用层→物理层”重复客户端的封装流程（加HTTPS加密、TCP头部、IP头部、帧头部），通过物理介质反向传输回客户端；
7. 客户端解封装与渲染：客户端接收响应比特流，从“物理层→应用层”解封装，浏览器最终解析HTML/CSS/JS，渲染出你看到的百度首页。

7.4 流程总结表

OSI七层	核心作用	百度访问关键操作	核心协议/技术	数据单元
应用层	用户交互与应用协议定义	输入域名、DNS解析、发起HTTPS请求	HTTP/HTTPS、DNS	数据（Data）
表示层	数据加密与格式统一	TLS/SSL加密请求、验证百度SSL证书	TLS/SSL	加密数据
会话层	建立与维护通信会话	建立浏览器-百度会话、设置超时重连规则	-（功能内嵌）	会话数据
传输层	可靠传输与端口定位	TCP三次握手、源端口（随机）+目的端口（443）	TCP	段（Segment）
网络层	IP路由与NAT转换	封装IP地址、路由器NAT转换、跨网络路由	IP、ICMP、NAT	包（Packet）
数据链路层	相邻设备通信与MAC解析	封装帧、ARP获取路由器MAC、WiFi/以太网传输	以太网、802.11、ARP	帧（Frame）
物理层	比特流传输与物理介质	电信号/无线电波传输、光纤骨干网传输	网线、WiFi、光纤	比特流（Bit）

---

总结

本文档系统地介绍了DNS域名解析服务的各个方面。从核心作用（正反向解析）和基础概念（端口、协议、FQDN）出发，深入讲解了其查询原理（递归与迭代查询的结合），揭示了全球DNS系统的分布式层次架构（根、顶级域、权威服务器）以及单台服务器可扮演的不同角色（主、从、缓存、转发）。

文档的核心部分通过一个详细的实战案例，演示了如何使用BIND软件部署一台具备正向和反向解析功能的主DNS服务器，涵盖了从安装软件、修改配置文件（主配置、区域配置、数据文件）到语法检查、服务启动和最终测试的完整流程。

最后，本章通过解析访问百度的完整流程，具象化地阐述了OSI七层模型中“下行封装、上行解封”的核心通信机制，揭示了数据从客户端到服务端的跨网络传输原理，这将有助于理解和部署企业级DNS服务，保障网络访问的可靠性和效率。