概述
DNS服务产生原因
- IP 地址是互联网上计算机的唯一逻辑地址，通过它实现不同计算机之间的通信。每台联网计算机都依赖 IP 地址进行相互联系与识别。然而，由于 IP 地址由一串易混淆的数字组成，人们很难记住所有计算机的 IP 地址，这给日常访问不同网站带来了不便
- 为了解决这个问题，人们在 IP 地址的基础上发展出了一种更易识别的符号化标识，这种标识由字母和数字组成，用户可以自由选择。相较于 IP 地址，域名更容易被识别和记忆，逐渐成为互联网用户访问网站的主要方式
- 尽管域名在用户中更受欢迎，但计算机只能识别由数字组成的 IP 地址，无法直接处理域名。因此，为了实现有效的访问，必须将域名转换为相应的 IP 地址。DNS（域名系统）负责执行这种转换，使得用户能够顺利访问互联网上的各种资源
作用：
- DNS（Domain Name System） 是互联网上的一项核心服务，用于将域名与 IP 地址相互映射，使用户能够更方便地访问互联网。
- 正向解析：将域名转换为 IP 地址（域名 → IP）
- 反向解析：将 IP 地址转换为域名（IP → 域名）
连接方式（端口）
- DNS 使用 53 端口 监听网络请求。
- 查看方法：DNS 默认使用 UDP 协议进行快速查询，但如果未能获取完整信息，则会切换到 TCP 协议进行重试。启动 DNS 服务时，会同时启动 TCP 和 UDP 的 53 端口监听。
域名结构/域名层级
拓扑
- 由于因特网用户数量庞大，因特网采用 层次树状结构 的命名方式
- 域名 (domain name)：每个连接到因特网的主机或路由器都有一个唯一的层次结构名称
- 域 (domain)：是命名空间中一个可管理的划分结构
- 注意：域名是一个逻辑概念，并不反映计算机的物理位置
域名结构示意图
#这是一个常见的4层域名结构
xxx.yyy.zzz.com.
| | | | |——> 根域名（通常不需要输入，计算机默认帮我们输入）
| | | |————> 顶级域名（TLD）：`.com`
| | |————————> 二级域名（Second-Level Domain）：`zzz`(用户可注册购买)
| |————————————> 子域名（Subdomain）：`yyy`（用户自行分配）
|————————————————> 主机名（或子域名）：`xxx`以上内容对么
顶级域名的分类
- 国家顶级域名：依据 ISO 3166 标准，例如：
cn代表中国，us代表美国，uk代表英国等。国家域名通常称为 CCTLD（country code top-level domains，cc 表示国家代码） - 通用顶级域名：常见的通用顶级域名包括：
com（公司企业）net（网络服务提供商）org（非营利组织）int（国际组织）gov（美国政府部门）mil（美国军事部门）edu（教育机构）
- 基础结构域名/反向域名 (infrastructure domain)：这一类顶级域名只有一个，即
arpa，用于反向域名解析，因此也称为反向域名
域名服务器类型划分
按照层级结构划分
域名服务器与域名一样属于层级结构，按照层级由高到低通常分为以下几大类：
| 分类 | 作用 |
|---|---|
| 根域名服务器 | 最高层次的域名服务器，所有的根域名服务器存储着所有的顶级域名服务器的域名和IP地址。本地域名服务器解析不了的域名就会向其求助 |
| 顶级域名服务器 | 负责管理在该顶级域名服务器下注册的二级域名 |
| 权限域名服务器 | 负责一个“区”的域名解析工作 |
| 本地域名服务器 | 当主机发出DNS查询请求时，这个查询请求首先发给本地域名服务器 |
关于根服务器的小知识
在与现有IPv4根服务器体系架构充分兼容基础上，由我国下一代互联网国家工程中心领衔发起的“雪人计划”于2016年在美国、日本、印度、俄罗斯、德国、法国等全球16个国家完成25台IPv6（互联网协议第六版）根服务器架设，事实上形成了13台原有根加25台IPv6根的新格局，为建立多边、民主、透明的国际互联网治理体系打下坚实基础。中国部署了其中的4台，由1台主根服务器和3台辅根服务器组成，打破了中国过去没有根服务器的困境
按照服务器功能划分
为了提高DNS解析服务的效率和可靠性， DNS 服务器可以按照功能划分以下几种类型
| 分类 | 作用 |
|---|---|
| 主服务器 | 在特定区域内具有唯一性，管理该区域的权威服务器，存储着该域名的完整DNS记录，包括A记录处理域名的注册和更新请求 |
| 从服务器 | 也称为辅助域名服务器，主要用于备份主域名服务器的数据，定期从主域名服务器同步DNS记录，必要时接替主域名服务器，确保DNS服务的连续性 |
| 缓存服务器 | 通常也称为递归解析器或本地DNS服务器，主要用于缓存DNS查询结果，减少DNS查询延迟，提高访问速度，一般部署在企业内网的网关位置 |
| 转发服务器 | 不直接存储DNS记录，将收到的查询请求转发给其它服务器（通常是上级DNS服务器或特定的DNS解析服务），将查询请求路由到正确的服务器，通常用于实现特定的DNS解析策略或优化查询性能 |
DNS域名解析过程
分类：
- 递归解析：DNS 服务器在收到用户发起的请求时，必须向用户返回一个准确的查询结果。如果 DNS 服务器本地没有存储与之对应的信息，则该服务器需要询问其他服务器，并将返回的查询结果提交给用户
- 迭代解析（反复）：DNS 服务器在收到用户发起的请求时，并不直接回复查询结果，而是告诉另一台 DNS 服务器的地址，用户再向这台 DNS 服务器提交请求，依次反复，直到返回查询结果
解析流程图：
过程分析
-
第一步：在浏览器中输入www . google .com 域名，本地电脑会检查浏览器缓存中有没有这个域名对应的解析过的 IP 地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过 TTL 属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的 IP 有变化，会导致被客户端缓存的域名无法解析到变化后的 IP 地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名
-
第二步：如果浏览器缓存中没有数据，浏览器会查找操作系统缓存中是否有这个域名对应的 DNS 解析结果。其实操作系统也有一个[域名解析]的过程，在 Linux 中可以通过 / etc/hosts 文件来设置，而在 windows 中可以通过配置 C:\Windows\System32\drivers\etc\hosts 文件来设置，用户可以将任何域名解析到任何能够访问的 IP 地址。例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地 DNS 解析的规程，所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的 IP 地址上，导致这些域名被劫持
-
第三步：前两步是在本地电脑上完成的，若无法解析时，就要用到我们网络配置中的 “DNS 服务器地址” 了。操作系统会把这个域名发送给这个本地 DNS 服务器。每个完整的内网通常都会配置本地 DNS 服务器，例如用户是在学校或工作单位接入互联网，那么用户的本地 DNS 服务器肯定在学校或工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。大约 80% 的域名解析到这里就结束了，后续的 DNS 迭代和递归也是由本地 DNS 服务器负责
-
第四步：如果本地 DNS 服务器仍然没有解析结果返回，就直接到根 DNS 服务器请求解析
-
第五步：根 DNS 服务器返回给本地 DNS 域名服务器一个顶级 DNS 服务器地址，它是国际顶级域名服务器，如. com、.cn、.org 等，全球只有 13 台左右
-
第六步：本地 DNS 服务器再向，上一步获得的顶级 DNS 服务器，发送解析请求
-
第七步：接受请求的顶级 DNS 服务器查找并返回此域名对应的 Name Server 域名服务器的地址，这个 Name Server 服务器就是我要访问的网站域名提供商的服务器，其实该域名的解析任务就是由域名提供商的服务器来完成。 比如我要访问 www.baidu.com，而这个域名是从 A 公司注册获得的，那么 A 公司上的服务器就会有 www.baidu.com 的相关信息
-
第八步：本地域名服务器向Name Server服务器发起查询请求
-
第九步：Name Server 服务器收到查询请求后再其数据库中进行查询，找到映射关系后将其IP地址及TTL值返回给本地DNS服务器，本地 DNS 服务器会缓存这个域名和 IP 的对应关系，缓存时间由 TTL 值控制
-
第十步：本地DNS服务器把解析的结果返回给本地电脑，本地电脑根据 TTL 值缓存在本地系统缓存中，域名解析过程结束
-
注意：
-
在实际的 DNS 解析过程中，可能还不止这 10 步，如 Name Server 可能有很多级，或者有一个 GTM 来负载均衡控制，这都有可能会影响域名解析过程
-
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间使用的交互查询就是迭代查询
-
114.114.114.114是国内移动、电信和联通通用的DNS，手机和电脑端都可以使用，解析成功率相对来说更高，国内用户使用的比较多，而且速度相对快、稳定，是国内用户上网常用的DNS。
-
223.5.5.5和223.6.6.6是阿里提供的免费域名解析服务器地址
-
8.8.8.8是GOOGLE公司提供的DNS，该地址是全球通用的，相对来说，更适合国外以及访问国外网站的用户使用
-
本地域名服务器要对因特网上任何一个域名进行解析，只要自己无法解析，就首先求助根域名服务器。则根域名服务器是最重要的域名服务器。假定所有的根域名服务器都瘫痪了，那么整个DNS系统就无法工作。所以根域名服务器并不直接把待查询的域名直接解析出IP地址，而是告诉本地域名服务器下一步应当找哪一个顶级域名服务器进行查询。
DNS配置文件解析
概述
- BIND：Berkeley Internet Name Domain ，伯克利因特网域名解析服务是一种全球使用最广泛的、最高效的、最安全的域名解析服务程序
bind服务中三个关键文件
1. /etc/named.conf（服务的主/核心配置文件）
-
作用：这是 BIND（Berkeley Internet Name Domain），此文件是BIND服务的核心配置文件，用于定义全局设置和区域配置。
-
内容：它包含了服务器的运行模式、安全策略、日志记录、访问控制以及区域文件的定义等关键信息。通过编辑此文件，管理员可以配置BIND服务器以监听特定的IP地址和端口，允许或拒绝特定客户端的查询请求，以及设置其他全局参数。
-
示例：
options { directory "/var/named"; // 数据文件存储目录 allow-query { any; }; // 允许任何人查询 }; zone "example.com" IN { type master; file "example.com.zone"; // 区域数据文件 };
2. /etc/named.rfc1912.zones（区域配置文件）
-
作用：管理员可以在此文件中添加正向解析和反向解析的区域配置，以便BIND服务器能够正确地解析域名和IP地址。该文件类似于目录，可以快速查找到各个域名与 IP 地址的映射文件。
-
内容：该文件用于保存域名和IP地址对应关系的配置信息，但并不直接包含具体的域名和IP地址数据。它指定了域名与IP地址解析规则保存的文件位置以及服务类型等内容。
-
示例：
zone "example.com" IN { type master; file "example.com.zone"; // 指向主区域文件 }; zone "26.168.192.in-addr.arpa" IN { type master; file "reverse.openlab.com"; // 指向反向区域文件 };
3. /var/named （数据配置文件目录）
-
作用：此目录用于存放实际的域名和IP地址对应关系的数据文件。这些数据文件通常具有“.zone”或“.db”后缀，以区域文件的形似和存在，包含了具体的域名和IP地址映射信息。BIND服务器会根据区域配置文件中的指示来读取这些数据文件，并提供DNS解析服务。
-
内容：该目录下存放的文件包含实际的 DNS 记录，如 A、CNAME、PTR 等记录。
-
示例：
/var/named/example.com.zone文件可能包含：
$TTL 86400 @ IN SOA ns1.example.com. admin.example.com. ( 2024103101 ; Serial 3600 ; Refresh 1800 ; Retry 604800 ; Expire 86400 ; Negative Cache TTL ) ; Name servers @ IN NS ns1.example.com. ; A records @ IN A 192.168.26.130 www IN A 192.168.26.131
主配置文件详细解析
-
主配置文件共4部分组成， 下面是对 BIND 主配置文件
/etc/named.conf的分析，主要包含其结构、常用指令和配置选项的详细说明。 -
options：用于定义全局配置选项，影响所有区域。
-
zone：定义特定的区域，包括其名称、类型（master/slave）、数据文件等
-
logging：设置日志记录的方式和存储位置，方便进行故障排查和监控。
-
include：可以引用其他文件的配置内容，作为/etc/named.conf文件的补充，有助于简化配置文件的管理
### 主配置文件结构
1. **全局选项**
- 设置 DNS 服务器的全局行为，比如默认的目录、查询权限等。
options {
directory "/var/named"; // DNS数据文件存储的默认目录
allow-query { any; }; // 允许所有用户进行查询
listen-on port 53 { any; }; // 监听所有地址的53端口
recursion no; // 禁止递归查询（可选），删除则为迭代查询
};
2. **区域定义**
- 定义 DNS 区域（zone），指定该区域的类型（主、从）及其对应的数据文件。
zone "example.com" IN {
type master; // 主区域
file "example.com.zone"; // 区域数据文件
};
zone "26.168.192.in-addr.arpa" IN {
type master; // 反向解析区域
file "reverse.openlab.com"; // 反向区域数据文件
};
3. **日志设置**
- 指定日志记录选项，用于调试和监控。
logging { //指定日志记录的分类及其存储目录
channel default_log { // 设置日志输出方式
file "/var/log/named/named.log"; // 日志文件保存路径
severity info; // 日志级别
print-time yes; // 打印时间戳
};
category default { default_log; }; // 将所有日志记录到 default_log
};
4. **内容补充**
- 可以引用其他文件的配置内容，作为/etc/named.conf文件的补充，有助于简化配置文件的管理
include "/etc/named.rfc1912.zones"; # 表示当前DNS服务器的区域配置文件位置
include "/etc/named.root.key"; # 密钥存储文件位置
#其余常用参数
options {
listen-on-v6 port 53 { ::1; };# 重要，监听允许访问的ipV6与端口
dump-file "/var/named/data/cache_dump.db"; # 默认缓存文件位置，默认即可
statistics-file "/var/named/data/named_stats.txt"; # DNS状态文件保存文件，默认即可
memstatistics-file "/var/named/data/named_mem_stats.txt"; # 内存状态文件保存文件，默认即可
secroots-file "/var/named/data/named.secroots"; # 安全根服务器保存位置，默认即可
recursing-file "/var/named/data/named.recursing"; # 递归查询文件保存位置，默认即可
dnssec-validation yes; # 开启加密，默认即可
managed-keys-directory "/var/named/dynamic"; # 指定目录中文件保存位置，用于管理密钥（DNSSEC）
pid-file "/run/named/named.pid"; # pid文件保存路径，默认即可
session-keyfile "/run/named/session.key"; # 会话密钥存储路径，自动生成，默认即可
zone "." IN { # zone 表示区域， "." 表示根，此处设置DNS根服务器的相关内容
type hint; # 表示服务器的类型为根
file "named.ca"; # 用于保存dns根服务器信息的文件，存储路径/var/named/named.ca,一共有13台ipv4和13台ipv6根服务器信息
};
访问控制
- 配置谁可以访问 DNS 服务器，设置 ACL（访问控制列表），控制不同 IP 地址或子网的访问权限。
acl "trusted" {
192.168.26.0/24; // 信任的网络
10.0.0.0/8; // 另外的信任网络
};
options {
allow-query { trusted; }; // 只允许受信任的网络查询
};
5. **其他设置**
- 可以添加其他特定的配置选项，例如缓存、转发设置等。
forwarders {
8.8.8.8; // Google Public DNS
8.8.4.4; // Google Public DNS
};
forwarders：指定转发 DNS 查询的服务器，通常用于没有完整的 DNS 数据库
区域配置文件
作用：
- /etc/named.rfc1912.zones文件为bind服务程序的区域配置文件，用来保存域名与IP地址映射关系文件的位置，是一系列功能模板的集合
区域配置文件示例分析
- 正向解析
zone "localhost.localdomain" IN { # 正向解析域名
type master; # 服务类型：master表示主服务器，slave表示从服务器，hint根服务器
file "named.localhost"; # 域名与IP地址规则文件存储位置
allow-update { none; }; # 不允许客户端动态更新本机域名解析的数据
};
# allow-update：允许更新解析库内容，一般关闭
# allow-query： 允许查询的主机，白名单
# allow-tranfter ： 允许同步的主机，白名单，常用
# allow-recursion： 允许递归的主机
- 反向解析：
zone "0.0.127.in-addr.arpa" IN { # 表示127.0.0.1的反向解析配置，IP地址需要倒置书写，只需书写网段即可
type master;
file "named.loopback"; # 反向解析的规则文件保存位置
allow-update { none; };
};
数据资源文件模板解析
正向解析资源文件
$TTL 1D # 设置生存周期时间，为1天，$表示宏定义
@ IN SOA @ rname.invalid. (
# @ ：表示zone域，现在表示域名，如baidu.com
# IN SOA ： 授权信息开始
# rname.invalid. ： 域名管理员的邮箱（不能使用@，使用点替代邮件分隔符@）
0 ; serial # 序列号，10位以内的整数
1D ; refresh # 更新频率为1天
1H ; retry # 失败重试时间为1小时
1W ; expire # 失效时间1周
3H ) ; minimum # 缓存时间为3小时
IN NS ns.域名.
ns IN A 域名解析服务器IP地址
www IN A 域名解析服务器IP地址
bbs IN A 域名解析服务器IP地址
mail IN A 域名解析服务器IP地址
# A：表示IPv4地址， AAAA表示IPv6地址
反向解析资源文件
[root@server ~]# vim /var/named/named.loopback
$TTL 1D
@ IN SOA @ rname.invalid. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
; Name Server Record
IN NS ns.域名. ; 域名服务器记录，注意结尾的点
; Name Server A Record
ns IN A 域名解析服务器的IP地址
; PTR Record for Reverse Lookup
IP地址 PTR 域名. ; PTR 指针记录，用于反向解析
| 序列号(Serial namber) | 每次修改区域记录时，都会增加序列号的值，它是辅授权DNS服务器更新数据的依据 |
|---|---|
| 刷新时间(refresh) | 辅授权DNS服务器根据此时间间隔周期性地检查主授权DNS服务器的序列号是否改变，若有改变则更新自己的区域记录（以秒为单位） |
| 重试延时(Retry) | 当辅授权DNS服务器因与主授权DNS无法连通而导致更新区域记录信息失败后，要等待多长时间会再次请求刷新区域记录（以秒为单位） |
| 失效时间(Expire) | 若辅授权DNS服务器超过该时间仍无法与主授权DNS连通，则不再尝试，且辅授权DS服务器不再响应客户端要求域名解析的请求（以秒为单位） |
| 无效缓存时间(Minimum) | 无效解析记录（查找名称且名称不存在的资源记录）在缓存中持续的时间（以秒为单位） |
配置文件验证命令
named-checkconf 和 named-checkzone 是用于 DNS 配置文件验证的两个命令，通常在使用 BIND（Berkeley Internet Name Domain）作为 DNS 服务器时使用。
1. named-checkconf
作用：
named-checkconf 用于检查 BIND 配置文件的语法，确保配置文件没有错误。这对于避免在启动或重新加载 DNS 服务器时出现故障非常重要。
示例：
named-checkconf /etc/named.conf
如果配置文件没有错误，命令将不返回任何内容。如果有语法错误，它将显示相关的错误信息和行号。
2. named-checkzone
作用：
named-checkzone 用于检查特定区域（zone）的 DNS 区域文件的语法。它确保区域文件的格式正确，并可以识别潜在的问题。
示例：
named-checkzone example.com /var/named/example.com.zone
在这个例子中，example.com 是要检查的区域名，而 /var/named/example.com.zone 是该区域的区域文件。如果没有错误，命令将返回 “OK”。如果有错误，将显示错误信息和行号。
总结
named-checkconf用于检查全局配置文件（如named.conf）的语法。named-checkzone用于检查特定 DNS 区域文件的语法。
DNS资源记录类型
| 记录类型 | 编码 | 用途 |
|---|---|---|
| A**（Address Record）** | 1 | 将域名映射到 IPv4 地址 |
| NS**（Name Server Record）** | 2 | 指定负责该域名的名称服务器 |
| CNAME**（Canonical Name Record）** | 5 | 将一个域名别名指向另一个真实的域名 |
| SOA**（Start of Authority Record）** | 6 | 表示区域的起始授权信息，包含管理信息（如序列号、刷新时间等） |
| PTR**（Pointer Record）** | 12 | 用于反向解析，是 A 记录的逆向记录，将 IP 地址映射到域名。 |
| MX**（Mail Exchange Record）** | 15 | 指定处理邮件的邮件服务器。 |
| TXT**（Text Record）** | 16 | 存储任意文本信息，如 SPF 记录或验证信息。 |
| AAAA**（IPv6 Address Record）** | 28 | 将域名映射到 IPv6 地址。 |
| SRV**（Service Record）** | 33 | 定义提供特定服务的主机及其端口。 |
| DS**（Delegation Signer Record）** | 43 | 与 DNSSEC 相关，提供子域的信任链。 |
| DNSKEY | 48 | 用于 DNSSEC，包含公钥信息。 |
| NSEC | 47 | 用于 DNSSEC，提供域名的存在性证明。 |
| NSEC3 | 50 | 一种改进的 NSEC，增强了安全性 |
常用域名解析记录类型详解
1. A 记录（Address Record）
-
定义：A 记录用于将域名映射到一个 IPv4 地址。
-
功能：当用户在浏览器中输入域名时，DNS 会查找 A 记录以获取相应的 IP 地址，从而将请求路由到正确的服务器。
-
示例：假设
item.taobao.com被解析到115.238.23.xxx，而switch.taobao.com被解析到121.14.24.xxx，DNS 会根据这些 A 记录将访问请求发送到指定的 IP 地址。item.taobao.com. IN A 115.238.23.xxx switch.taobao.com. IN A 121.14.24.xxx
2. NS 记录（Name Server Record）
-
定义：NS 记录指定负责某个域名的 DNS 解析服务器。
-
功能：这告诉 DNS 查询者，解析该域名的请求应该发送到哪些名称服务器。
-
示例：如果
example.com的 NS 记录指向ns1.example.com，则所有对example.com的 DNS 查询都将发送到ns1.example.com，由它来处理该域名的解析。example.com. IN NS ns1.example.com.
3. CNAME 记录（Canonical Name Record）
-
定义：CNAME 记录允许将一个域名指向另一个域名（别名解析）。
-
功能：这使得多个域名可以指向同一个实际的服务器地址，便于管理和维护。
-
示例：可以将
aaa.com和ccc.com都解析为bbb.net。访问这两个域名时，DNS 将返回bbb.net的 A 记录，指向同一 IP 地址。aaa.com. IN CNAME bbb.com. ccc.com. IN CNAME bbb.com.
4.PTR 记录（Pointer Record）
-
定义：PTR 记录用于反向 DNS 查询，将 IP 地址映射到域名。它的主要作用是提供域名的反向解析功能。
-
功能：当给定一个 IP 地址时，可以通过 PTR 记录查找该地址对应的域名，这在网络管理和安全检查中非常重要。反向解析可以帮助确认一个 IP 地址是否与特定的域名相匹配，有助于防止伪造和垃圾邮件。
-
示例：如果有一个 IP 地址
192.0.2.1，可以设置一个 PTR 记录如下：
在这个示例中，查询192.0.2.1时，DNS 将返回example.com作为对应的域名。1.2.0.192.in-addr.arpa. IN PTR example.com.主要用途：
- 邮件服务器验证：许多邮件服务器会检查发件人的 IP 地址的 PTR 记录，以验证发件人的身份，帮助防止垃圾邮件。
- 安全性：通过反向解析，网络管理员可以确认连接到网络的设备和其对应的域名，从而加强网络安全。
5. MX 记录（Mail Exchange Record）
-
定义：MX 记录指定邮件服务器，用于处理与特定域名相关的电子邮件。每个域名可以有多个 MX 记录，以便在邮件服务器不可用时实现冗余或负载均衡。
-
功能：当发送邮件到某个域名时，DNS 会查找 MX 记录以确定邮件应该发送到哪个服务器。MX 记录的优先级决定了邮件发送的顺序**（数字越小越优）**
-
示例：如果
example.com的 A 记录 IP 地址是115.238.25.xxx，可以设置 MX 记录为115.238.25.xxx。这样，发送到xxx@example.com的邮件会被路由到这个 IP 地址的邮件服务器，而 web 请求则依然通过 A 记录解析到相同的 IP 地址。example.com. IN MX 10 mail1.example.com. example.com. IN MX 20 mail2.example.com.
6. TXT 记录（Text Record）
- 定义：TXT 记录用于存储任意文本信息，通常用于描述或提供额外的信息。
- 功能：这类记录可以用于域名验证、邮件安全（如 SPF 记录）和其他用途。
- 示例：可以为
ddd.net设置 TXT 记录为"这是 XXX 的博客"，这可以帮助用户或其他服务了解该域名的性质或功能。
7. SOA 记录（Start of Authority Record）
-
功能：表示区域的起始授权信息，包含管理信息（如序列号、刷新时间等）。NS 记录说明了有多台服务器在进行解析，但哪一个才是主服务器，NS 并没有说明，SOA 记录了说明在众多 NS 记录里哪一台才是主要的服务器
-
示例：
$TTL 1D //全局生存时间 @（代表当前区域） IN SOA (主DNS服务器域名) admin.com.（管理员邮箱） ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum
nslookup和dig工具
两者区别
- Dig工具可以从该域名的官方dns服务器上查询到精确的权威解答，而nslookup只会得到DNS解析服务器保存在cache中的非权威解答,查询结果可能过期，面对分布式部署的服务器，查询结果可能不同
nslookup解析
命令格式
nslookup [-option] [name | -] [server]
常用选项
| 选项 | 说明 |
|---|---|
| -querytype | 指定查询类型，默认为A记录 |
| -timeout | 指定查询超时时间 |
| -debug | 显示调试信息 |
[name]：这是您要查询的域名或 IP 地址。例如，example.com。如果您想进行反向查询，可以提供 IP 地址。[-]：使用短横线表示查询根域名。[server]：这是可选的参数，您可以指定要查询的 DNS 服务器的 IP 地址或域名。如果不指定，nslookup将使用系统配置的默认 DNS 服务器。
部分示例
[root@localhost ~]# nslookup -querytype=ns openlab.com 192.168.26.130
Server: 192.168.26.130
Address: 192.168.26.130#53
openlab.com nameserver = ns1.openlab.com.
openlab.com nameserver = ns2.openlab.com.
[root@localhost ~]# nslookup -querytype=A openlab.com 192.168.26.130
Server: 192.168.26.130
Address: 192.168.26.130#53
Name: openlab.com
Address: 192.168.26.130
dig解析
以下是dig的命令格式，肉眼dig相对nslookup，功能复杂且详细很多
dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p port#] [-q name] [-t type] [-v]
[-x addr] [-y [hmac:]name:key] [ [-4] | [-6] ] [name] [type] [class] [queryopt...]
参数说明
| 参数 | 说明 |
|---|---|
@server | 可选参数，指定要查询的 DNS 服务器。例如 @8.8.8.8 |
-b address | 指定使用的本地地址。用于绑定到特定的 IP 地址 |
-c class | 指定查询的 DNS 类。常用的类是 IN（Internet），但可以使用其他类（如 CH、HS） |
-f filename | 将查询的结果保存到文件中。此选项用于将输出重定向到指定文件 |
-k filename | 指定一个文件，通常用于提供 TSIG 密钥，以进行安全的 DNS 更新 |
-m | 启用最小 DNS 解析，适合于简化和优化查询 |
-p port# | 指定用于 DNS 查询的端口，默认为 53 |
-q name | 指定要查询的域名，通常在命令行最后部分提供 |
-t type | 指定要查询的 DNS 记录类型，例如 A、MX、NS 等 |
-v | 启用详细模式，提供更多输出信息 |
-x addr | 进行逆向 DNS 查询，将 IP 地址转换为域名。例如 -x 8.8.8.8 |
-y [hmac:]name:key | 用于 TSIG 安全更新，指定密钥和名称。hmac 是加密算法（例如 HMAC-SHA256） |
[-4]、[-6] | 选择使用 IPv4 或 IPv6 进行查询。-4 强制使用 IPv4，-6 强制使用 IPv6 |
[name] | 要查询的域名，通常在命令行中最后指定 |
[type] | 要查询的记录类型（例如 A、MX），如果不提供，默认查询 A 记录 |
[class] | 查询的 DNS 类，默认是 IN |
[queryopt...] | 附加的查询选项，用于进一步定制查询 |
常用参数及示例
以下是一些常用的 dig 参数及其示例：
| 参数 | 说明 | 示例 |
|---|---|---|
@server | 指定要查询的 DNS 服务器 | dig @8.8.8.8 example.com |
-t type | 指定要查询的 DNS 记录类型 | dig example.com MX |
-q name | 指定要查询的域名 | dig -q example.com |
-x addr | 进行逆向 DNS 查询，将 IP 地址转换为域名 | dig -x 8.8.8.8 |
+short | 简化输出，只显示结果 | dig +short example.com |
-p port# | 指定用于 DNS 查询的端口 | dig -p 5353 example.com |
+stats | 显示查询的统计信息 | dig example.com +stats |
-c class | 指定查询的 DNS 类 | dig -c CH example.com |
结果示例
[root@localhost ~]# dig @localhost openlab.com
; <<>> DiG 9.16.23-RH <<>> @localhost openlab.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60868
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 4fa207dc7d8c11d9010000006726434acc257d6723622ca3 (good)
;; QUESTION SECTION:
;openlab.com. IN A
;; ANSWER SECTION:
openlab.com. 86400 IN A 192.168.26.130
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Nov 02 23:20:42 CST 2024
;; MSG SIZE rcvd: 84
[root@localhost ~]# dig @localhost +short openlab.com
192.168.26.130
修改默认DNS服务器
上面我们提到，使用nslookup/dig解析域名或IP时可以指定DNS服务器IP地址，如果不指定的话将使用配置文件中的默认DNS服务器，例如
[root@localhost ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 114.114.114.114
注意：配置文件优先级高于网卡优先级，重启后配置文件会读取网卡的DNS地址
[root@localhost ~]# nmcli device show
GENERAL.DEVICE: ens160
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 00:0C:29:D9:3F:A3
GENERAL.MTU: 1500
GENERAL.STATE: 100（已连接）
GENERAL.CONNECTION: 以太网连接 1
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/2
WIRED-PROPERTIES.CARRIER: 开
IP4.ADDRESS[1]: 192.168.26.132/24
IP4.ADDRESS[2]: 192.168.26.131/24
IP4.ADDRESS[3]: 192.168.26.130/24
IP4.GATEWAY: 192.168.26.2
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.26.2, mt = 100
IP4.ROUTE[2]: dst = 192.168.26.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[3]: dst = 192.168.26.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[4]: dst = 192.168.26.0/24, nh = 0.0.0.0, mt = 100
IP4.DNS[1]: 114.114.114.114
IP6.ADDRESS[1]: fe80::efde:b638:1b1c:d5df/64
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 1024
GENERAL.DEVICE: lo
GENERAL.TYPE: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATE: 100（连接（外部））
GENERAL.CONNECTION: lo
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
lines 1-28
增量/全量区域传送
全量区域传送（Full Zone Transfer, AXFR）和增量区域传送（Incremental Zone Transfer, IXFR）是 DNS 中用于同步 DNS 区域数据的两种方式。它们的主要区别在于数据传输的方式和内容。以下是对这两种区域传送的详细介绍：
全量区域传送（AXFR）
- 定义：全量区域传送是将整个 DNS 区域的所有记录一次性传送到从 DNS 服务器的过程。这种方式通常用于从主 DNS 服务器向从 DNS 服务器同步整个区域数据。
- 工作原理：
- 从 DNS 客户端（通常是从 DNS 服务器）发起 AXFR 请求。
- 主 DNS 服务器响应请求，发送该区域的所有 DNS 记录。
- 从 DNS 服务器接收并更新本地区域文件。
- 优点：
- 简单直接，易于实现。
- 保证从 DNS 服务器获得区域的完整性和一致性。
- 缺点：
- 对带宽的需求较高，特别是当区域记录较大时。
- 在区域频繁变动的情况下，传输效率较低，因为每次变更都需要重新传送整个区域。
增量区域传送（IXFR）
- 定义：增量区域传送是一种仅传送自上次同步以来发生更改的记录的方式。它只发送在主 DNS 服务器上修改、添加或删除的记录，而不是整个区域。
- 工作原理：
- 从 DNS 客户端发起 IXFR 请求，通常是从 DNS 服务器。
- 主 DNS 服务器根据请求发送自上次同步以来发生变化的记录。
- 从 DNS 服务器接收增量更新并应用这些变更。
- 优点：
- 节省带宽，仅传送发生变化的记录。
- 更加高效，尤其是在区域数据较大且频繁变更的情况下。
- 缺点：
- 实现相对复杂，涉及记录版本控制。
- 可能导致从 DNS 服务器在应用增量更新时出现不一致性，尤其是在传输过程中出现故障。
主要区别总结
- 数据传送方式：
- AXFR：从服务器每次请求全量数据，主服务器将整个区域的所有记录传送
- IXFR：从服务器仅请求自上次同步以来发生变化的记录
- 配置需求：
- AXFR 的配置相对简单，主要确保从服务器可以访问
- IXFR 需要主服务器和从服务器都支持增量更新，且序列号必须准确维护
- 性能：
- AXFR 在区域数据较大时会消耗更多带宽，适合较少变动的情况
- IXFR 更加高效，适合频繁变动的区域数据，节省带宽和资源
配置示例
在主从 DNS 服务器的配置中，全量区域传送（AXFR）和增量区域传送（IXFR）的主要区别体现在从服务器的配置和对主服务器的设置
全量区域传送（AXFR）
1. 主服务器配置
- 配置：主服务器通常没有特别的配置要求，只需确保允许从服务器进行全量区域传送。
- 设置示例：
zone "example.com" {
type master;
file "example.com.zone";
allow-transfer { 192.168.26.129; }; # 从服务器的 IP 地址
};
2. 从服务器配置
-
配置：从服务器配置为
slave类型，并指定主服务器的 IP 地址 -
设置示例：
zone "example.com" { type slave; file "slaves/example.com.zone"; # 设置保存区域的路径 masters { 192.0.2.1; }; # 主服务器的 IP 地址 };
增量区域传送（IXFR）
1.主服务器配置
-
配置：同样，主服务器的配置需要允许 IXFR 请求。IXFR 通常不需要特别的设置，但要确保记录的序列号在区域文件中保持更新，以便从服务器能够识别变化
-
设置示例：
zone "example.com" { type master; file "example.com.zone"; allow-transfer { 192.168.26.129; }; # 从服务器的 IP 地址 also-notify { 192.168.26.129; }; # 可选，通知从服务器 };
2.从服务器配置
-
配置：从服务器的配置与 AXFR 类似，但其请求会根据主服务器的记录变化情况来决定是使用全量还是增量传送。通常，使用 IXFR 时，从服务器会自动发送 IXFR 请求，如果主服务器支持增量传送
-
设置示例：
zone "example.com" { type slave; file "slaves/example.com.zone"; # 保存区域的路径 masters { 192.168.26.130; }; # 主服务器的 IP 地址 // 可能添加的 IXFR 支持设置 notify yes; # 接收主服务器的通知 also-notify { 192.168.26.130; }; # 可选，向主服务器确认 IXFR 请求 };
总结及注意事项
- 主服务器：
- AXFR的配置上，主服务器只要确保从服务器可以访问即可
- IXFR 的配置上，主服务器除了确保
allow-transfer允许从服务器可以访问，还要确保记录的序列号更新，以便从服务器能够识别变化
- 从服务器：
- 在 AXFR 和 IXFR 的配置上，从服务器的
zone声明基本一致，但在处理请求时，IXFR 会自动选择传输方式，依赖于主服务器的变化情况 - 一般来说从服务器会优先尝试使用IXFR请求，只获取自上次同步以来变化的记录。如果主服务器不支持 IXFR，或者从服务器的请求失败，它将回退到 AXFR，请求全量数据
- 在 AXFR 和 IXFR 的配置上，从服务器的
日志简单查看
查看 DNS 服务器日志是排查问题和监控活动的重要步骤。不同的 DNS 服务器（如 BIND、PowerDNS、Unbound 等）可能会将日志记录到不同的文件中。
以下是使用 BIND DNS 服务器时的一些常见日志查看方法：
1. 查找日志文件
- 默认日志位置：
BIND 的默认日志文件通常位于/var/log/messages或/var/log/named/named.log，具体位置取决于您的系统配置和 BIND 的设置。
2. 查看日志内容
使用 tail 命令可以实时查看日志文件的最新条目：
tail -f /var/log/messages
3. 使用 grep 过滤日志
如果您想查找特定的日志条目，可以使用 grep 命令。例如，要查找与某个域名相关的记录：
grep "example.com" /var/log/messages
日志其它设置
4. 日志级别配置
在 BIND 配置文件中（通常是 /etc/named.conf 或 /etc/bind/named.conf），可以设置不同的日志级别：
logging {
channel default_log {
file "/var/log/named/named.log";
severity info;
print-time yes;
};
category default { default_log; };
category queries { default_log; }; # 记录查询日志
};
您可以根据需要调整 severity 的级别，例如使用 debug 级别获取更多详细信息。
5. 日志轮转
确保日志文件不会无限增长，设置日志轮转可以使用 logrotate。配置通常位于 /etc/logrotate.d/named，示例如下：
/var/log/named/named.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 0640 named named
}
6. 检查系统日志
如果您在 BIND 日志中找不到相关信息，可以查看系统日志：
tail -f /var/log/syslog # Debian/Ubuntu
tail -f /var/log/messages # CentOS/RHEL
