网络应用层之(2)DNS协议

网络应用层之(2)DNS协议

Author: Once Day Date: 2024年8月12日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 通信网络技术_Once-Day的博客-CSDN博客。

参考文章:

《TCP/IP详解卷一》
【网络协议详解】——DNS系统协议（学习笔记）_学习网络”中的“ dns 协议”-CSDN博客
超详细 DNS 协议解析-腾讯云开发者社区-腾讯云 (tencent.com)
计算机网络 | 图解 DNS & HTTPDNS 原理-阿里云开发者社区 (aliyun.com)
浅尝DNS原理及其应用-腾讯云开发者社区-腾讯云 (tencent.com)
一文了解 DoH（DNS-over-HTTPS）和DoT（DNS-over-TLS）_dns over tls-CSDN博客
DNS 协议详解（适合收藏学习）_dns协议-CSDN博客

文章目录

网络应用层之(2)DNS协议
- - - 1. 概述
    - - 1.1 介绍
      - 1.2 DNS名称空间(域名)
      - 1.3 DNS域名分类
      - 1.4 域名服务器
      - 1.5 域名解析流程
      - 1.6 DNS缓存
      - 1.7 RFC文档
    - 2. 报文格式
    - - 2.1 DNS基本格式
      - 2.2 DNS名称和标签
      - 2.3 TCP和UDP
      - 2.4 DNS查询和资源记录格式
      - 2.5 资源记录类型
    - 3. 实践
    - - 3.1 地址和名称服务器记录
      - 3.2 规范名称(CNAME，canonical name)
      - 3.3 逆向查询(PTR)
      - 3.4 权威记录(SOA)
      - 3.5 邮件交换记录(MX)
      - 3.6 文本记录(TXT)
      - 3.7 选线OPT伪记录
      - 3.8 服务记录(SRV)
      - 3.9 名称授权指针记录(NAPTR记录)
      - 3.10 DNS更新
      - 3.11 DNS区域传输和通知
      - 3.12 DNS64转换
      - 3.13 本地DNS(LLMNR和mDNS)
    - 4. 总结

1. 概述

1.1 介绍

DNS(域名系统)是互联网的核心协议之一，在网络通信中扮演着至关重要的角色。它犹如一部庞大的电话簿，将人类易记的域名映射为计算机易于处理的IP地址。没有DNS的存在，我们就难以在茫茫的网络世界中准确定位所需的资源。

DNS协议的基本工作原理可以简单概括为以下几个步骤：

当用户在浏览器地址栏中输入一个域名时，DNS服务器首先会查询自己的缓存，看是否已经存在该域名与IP地址的对应关系。
如果缓存未命中，DNS服务器则会向根域名服务器发起查询请求。根域名服务器会告诉本地DNS服务器负责该域名的顶级域名服务器的地址。
本地DNS服务器再向顶级域名服务器查询，获取权威DNS服务器的地址。
最后，本地DNS服务器向权威DNS服务器查询，获取该域名对应的IP地址，并将结果返回给用户的浏览器。

整个过程就像是在打电话时，通过总机一级级转接，最终找到我们想要联系的人，如下图所示：

此图源自：浅尝DNS原理及其应用-Wells-腾讯云开发者社区-腾讯云 (tencent.com)

在这里插入图片描述

DNS协议采用分布式的设计架构，全球范围内部署了大量的DNS服务器，形成了一个多层次的查询系统。这种分层的结构有效分担了查询压力，提高了系统的可用性和稳定性。同时，DNS还支持多种类型的资源记录，如A记录、CNAME记录、MX记录等，可以存储丰富的域名相关信息。

除了基本的解析功能外，DNS协议还具备诸多高级特性。例如，DNS服务器可以通过主从复制和负载均衡技术，实现冗余备份和流量分发，从而增强系统的可靠性和性能。此外，DNS还支持动态更新，允许域名的IP地址发生变化时自动更新相关记录，极大地提高了管理的灵活性。

DNS协议的安全性也备受关注。为了防止DNS欺骗和劫持等攻击，人们开发了DNSSEC(DNS安全扩展)技术，通过数字签名和密钥验证机制，确保DNS应答的真实性和完整性。这在很大程度上提升了DNS系统的安全性，保护用户免受网络威胁。

1.2 DNS名称空间(域名)

DNS(域名系统)采用层次化的命名方案，形成了一个倒置的树状结构，称为域名空间(Domain Name Space)。在这个倒置的树中，每一个节点都代表一个域(Domain)，节点的名称就是域名(Domain Name)。其中有两个重要的概念：

IP 地址：一长串能够唯一地标记网络上的计算机的数字。
域名：又称网域，是由一串用点分隔的名字组成的 Internet 上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识（有时也指地理位置）比如 www.baidu.com。DNS域名不区分大小写。

域名空间的最顶层是根域(Root Domain)，用一个点"."表示。根域下面是顶级域(Top-level Domain，TLD)，如.com、.org、.net等通用顶级域，以及.cn、.uk、.jp等国家或地区顶级域，再往下就是二级域、三级域等，每一级域名都隶属于其上一级域。

举例来说，如果我们有一个域名"www.example.com"，按照DNS域名空间的层次结构，它可以被拆分为以下几部分:

根域：用一个点"."表示，位于最顶层。
顶级域(top level domain，TLD)：“.com”，代表通用顶级域中的商业机构。
二级域：“example”，通常用来表示组织或个人的身份标识。
主机名：“www”，代表提供网络服务的主机。

所以，“www.example.com"的完整域名可以表示为"www.example.com.”，最后的那个点代表根域。当我们在浏览器中输入这个域名时，实际上是在向DNS服务器查询该域名下的IP地址。

域名的基本组成规则如下:

域名的结构由若干个分量组成，各分量之间用“点”隔开，分别代表不同级别的域名。
每一级的域名都由英文字母和数字组成，不超过63个字符，不区分大小写字母。
级别最低的域名写在最左边，而级别最高的顶级域名写在最右边。
完整的域名不超过255个字符。

通过这种层次化的命名方案，DNS将全球无数的网络资源组织成了一个有序的、易于管理的结构。每一级域名都代表了不同的管理权限和控制范围，从而实现了对互联网上海量资源的有效管理和灵活配置。

全世界域名的最高管理机构，是一个叫做 ICANN （Internet Corporation for Assigned Names and Numbers）的组织，总部在美国加州。ICANN 负责管理全世界域名系统的运作。

1.3 DNS域名分类

域名可以按照不同的标准进行分类，下面是几种常见的域名分类方式。

(1) 按照域名级别分类:

顶级域名(Top-level Domain，TLD)：如.com、.org、.net等通用顶级域，以及.cn、.uk、.jp等国家或地区顶级域。
二级域名(Second-level Domain，SLD)：位于顶级域名下一级，如example.com、wikipedia.org等。
三级域名及以下：如www.example.com、mail.company.co.uk等。

(2) 按照域名用途分类:

商业域名：用于商业组织或个人，如apple.com、amazon.com等。
政府域名：用于政府机构或部门，如whitehouse.gov、gov.cn等。
教育域名：用于教育机构，如mit.edu、tsinghua.edu.cn等。
非营利组织域名：用于非盈利性组织，如greenpeace.org、redcross.org等。

(3) 按照域名后缀分类:

通用顶级域(Generic Top-level Domain,gTLD)：如.com、.net、.org等，不限国家或地区。
国家或地区顶级域(Country Code Top-level Domain,ccTLD)：如.cn(中国)、.us(美国)、.jp(日本)等，代表特定国家或地区。
新通用顶级域(New gTLD)：如.xyz、.club、.vip等，是近年来新增的顶级域名。

1.4 域名服务器

域名服务器(DNS，Domain Name System)是互联网的一项核心服务，它就像是互联网世界的"电话簿"，负责将人类易记的域名(如www.example.com)翻译成机器使用的IP地址(如93.184.216.34)。下面是几种主要的DNS服务器类型：

根域名服务器(Root DNS Server)，处于DNS层次结构的最顶端，它知道所有顶级域(如.com、.org、.net等)由哪些权威DNS服务器负责解析。全球共有13组根域名服务器，编号从a.root-servers.net到m.root-servers.net。当其他DNS服务器无法解析域名时，就会向根域名服务器求助。
顶级域名服务器(TLD DNS Server) ，负责管理顶级域下的所有域名，比如.com、.org等通用顶级域(gTLD)和.cn、.uk等国家和地区顶级域(ccTLD)。当权威DNS服务器未知时，本地DNS服务器会向顶级域名服务器查询。举例来说，当你访问www.example.com时，本地DNS会先问.com顶级域名服务器，example.com这个二级域是由哪个权威DNS服务器负责的。
权威域名服务器(Authoritative DNS Server)，特定域名的权威信息来源，由域名所有者自己管理或委托给域名注册商维护。比如example.com的权威DNS服务器可能是dns1.example.com和dns2.example.com。权威DNS服务器下可能还有二级域(如www.example.com)的zone文件记录。当本地DNS要查询www.example.com的IP地址时，最终就是由example.com的权威DNS服务器来应答。
本地域名服务器(Local DNS Server)，本地DNS服务器通常由网络服务提供商(ISP)维护，它是大多数网民访问网站的"门户"。每当我们要访问一个网站时，设备上的DNS解析器首先会向本地DNS服务器发起递归式查询。本地DNS服务器先检查缓存，命中就直接返回结果。如果未命中，就代替我们一级一级地询问根、顶级域、权威DNS服务器，得到IP地址后记录到缓存，再返回给请求者。

这几种DNS服务器通力协作，共同完成将域名转换为IP地址的重要任务:

根DNS服务器处于顶端，对整个域名空间负责。
顶级域名服务器管理各自的顶级域，掌握权威DNS服务器地址。
权威DNS服务器拥有特定域名的权威信息，是查询的终点。
本地DNS服务器直接为网民服务，代替我们"串联"以上所有服务器。

1.5 域名解析流程

域名解析是将域名转换为IP地址的过程，这个过程中涉及两种查询方式：递归查询和迭代查询。下面以访问www.example.com为例，介绍本地DNS服务器是如何通过这两种查询方式获取IP地址的。

(1) 递归查询(Recursive Query)，在递归查询模式下，本地DNS服务器就像是用户的"代理人"，它接受用户的请求后，必须自己完成整个域名解析过程，最后将结果返回给用户。递归查询的步骤如下:

检查本地缓存，如果存在www.example.com的记录，就直接返回结果。
如果缓存未命中，本地DNS就向根域名服务器发起查询。
根域名服务器告诉本地DNS，.com顶级域由哪些服务器负责。
本地DNS向.com顶级域名服务器发起查询。
.com顶级域名服务器告诉本地DNS，example.com由哪些权威DNS服务器负责。
本地DNS向example.com的权威DNS服务器发起查询。
权威DNS服务器告诉本地DNS，www.example.com的IP地址是93.184.216.34。
本地DNS将结果返回给用户，并将其缓存一段时间，以备后续查询。

在整个递归查询过程中，用户和本地DNS服务器只进行了一次交互。但本地DNS服务器在"后台"替用户完成了多次查询，最终获得了所需的IP地址。如下图所示：

来自：【网络协议详解】——DNS系统协议（学习笔记）_学习网络”中的“ dns 协议”-HinsCoder-CSDN博客

在这里插入图片描述

(2) 迭代查询(Iterative Query) ，在迭代查询模式下，本地DNS服务器更像是一位"教导主任"，它告诉用户应该去哪里询问，但不会代替用户去询问。迭代查询的步骤如下:

本地DNS向根域名服务器发起查询，询问www.example.com的IP地址。
根域名服务器告诉本地DNS，它不知道www.example.com的IP地址，但.com顶级域由某些服务器负责，你可以去问问它们。
本地DNS向.com顶级域名服务器发起查询，询问www.example.com的IP地址。
.com顶级域名服务器告诉本地DNS，它也不知道www.example.com的IP地址，但example.com由某些权威DNS服务器负责，你可以去问问它们。
本地DNS向example.com的权威DNS服务器发起查询，询问www.example.com的IP地址。
权威DNS服务器告诉本地DNS，www.example.com的IP地址是93.184.216.34。
本地DNS将结果返回给用户，并将其缓存一段时间，以备后续查询。

在迭代查询中，本地DNS逐级询问根、顶级域、权威DNS服务器，最终得到了权威答案，这种模式减轻了上级DNS服务器的负担。如下图所示：

来自：【网络协议详解】——DNS系统协议（学习笔记）_学习网络”中的“ dns 协议”-HinsCoder-CSDN博客

在这里插入图片描述

实际应用中，本地DNS通常向上级服务器发起递归查询，而上级服务器之间则使用迭代查询，这样一来:

对用户来说，只需与本地DNS交互一次，查询过程简单透明。
对DNS服务器来说，递归查询集中在网民身边的本地DNS，迭代查询用于上级DNS服务器之间，分工明确，结构稳健。

1.6 DNS缓存

DNS缓存是一种提高域名解析效率、降低网络延迟的技术。通过在本地或服务器端保存最近解析过的域名和IP地址的对应关系，DNS缓存可以在后续查询时直接返回结果，而无需重复访问根、顶级域、权威DNS服务器，从而加快网页加载速度。

DNS缓存可以分为两类:客户端缓存和服务器端缓存。

客户端缓存：指操作系统或浏览器在本地维护的DNS缓存。例如，Windows系统的DNS Client Service就会在本地缓存最近1024条DNS查询结果。
服务器端缓存：指本地DNS服务器或其他上级DNS服务器上的缓存。例如，常见的开源DNS服务器BIND就提供了内置的DNS缓存功能。

缓存中的每条记录都有一个TTL(Time-to-Live)值，表示该记录的有效时间。在TTL过期之前，本地DNS或应用程序都可以直接从缓存中获取IP地址，而无需重复查询。

在Linux系统中，可以使用nscd(Name Service Cache Daemon)服务来管理DNS缓存。下面是一些常见的操作:

# 安装nscd服务(以Ubuntu为例)
sudo apt-get install nscd
# 启动nscd服务
sudo systemctl start nscd
# 设置开机自启
sudo systemctl enable nscd
# 查看当前DNS缓存状态
sudo nscd -g
# 清空DNS缓存
sudo nscd -i hosts
# 修改nscd配置(如缓存条数、TTL等)，编辑`/etc/nscd.conf`文件
sudo vim /etc/nscd.conf

在Windows系统中，DNS缓存由DNS Client Service管理。可以通过以下方式查看或修改DNS缓存:

# 查看当前DNS缓存内容
ipconfig /displaydns
# 清空DNS缓存
ipconfig /flushdns
# 使用PowerShell查看DNS缓存统计信息
Get-DnsClientCache
# 使用注册表修改DNS缓存设置(如禁用缓存)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v MaxCacheEntryTtlLimit /d 1 /t REG_DWORD /f

1.7 RFC文档

以下是与DNS相关的主要RFC文档列表:

RFC 1034 - Domain Names - Concepts and Facilities (域名系统的基本概念和工具)

RFC 1035 - Domain Names - Implementation and Specification (域名系统的实现和规范)

RFC 1123 - Requirements for Internet Hosts - Application and Support (互联网主机的应用和支持需求)

RFC 1183 - New DNS RR Definitions (新的DNS资源记录定义)

RFC 1348 - DNS NSAP RRs (DNS的NSAP资源记录)

RFC 1637 - DNS NSAP Resource Records (DNS的NSAP资源记录)

RFC 1706 - DNS NSAP Resource Records (DNS的NSAP资源记录)

RFC 1712 - DNS Encoding of Geographical Location (DNS中地理位置的编码)

RFC 1876 - A Means for Expressing Location Information in the Domain Name System (在DNS中表示位置信息的方法)

RFC 1886 - DNS Extensions to Support IP Version 6 (支持IPv6的DNS扩展)

RFC 1995 - Incremental Zone Transfer in DNS (DNS中的增量区域传输)

RFC 1996 - A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (DNS区域变更的及时通知机制)

RFC 2065 - Domain Name System Security Extensions (DNS安全扩展)

RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE) (DNS中的动态更新)

RFC 2181 - Clarifications to the DNS Specification (对DNS规范的澄清)

RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) (DNS查询的负缓存)

RFC 2535 - Domain Name System Security Extensions (DNS安全扩展)

RFC 2671 - Extension Mechanisms for DNS (EDNS0) (DNS的扩展机制)

RFC 2672 - Non-Terminal DNS Name Redirection (非终端DNS名称重定向)

RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG) (DNS的秘密密钥事务认证)

RFC 2930 - Secret Key Establishment for DNS (TKEY RR) (DNS的秘密密钥建立)

RFC 3110 - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (DNS中的RSA/SHA-1签名和RSA密钥)

RFC 3225 - Indicating Resolver Support of DNSSEC (指示解析器对DNSSEC的支持)

RFC 3226 - DNSSEC and IPv6 A6 Aware Server/Resolver Message Size Requirements (DNSSEC和IPv6 A6感知服务器/解析器的消息大小要求)

RFC 3596 - DNS Extensions to Support IP Version 6 (支持IPv6的DNS扩展)

RFC 3645 - Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) (DNS秘密密钥事务认证的通用安全服务算法)

RFC 4033 - DNS Security Introduction and Requirements (DNS安全介绍和需求)

RFC 4034 - Resource Records for the DNS Security Extensions (DNS安全扩展的资源记录)

RFC 4035 - Protocol Modifications for the DNS Security Extensions (DNS安全扩展的协议修改)

RFC 4255 - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints (使用DNS安全发布SSH密钥指纹)

RFC 4343 - Domain Name System (DNS) Case Insensitivity Clarification (DNS大小写不敏感性澄清)

RFC 4398 - Storing Certificates in the Domain Name System (DNS) (在DNS中存储证书)

RFC 4408 - Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 (授权在电子邮件中使用域名的发件人策略框架版本1)

RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (在DNSSEC授权签名者资源记录中使用SHA-256)

RFC 4592 - The Role of Wildcards in the Domain Name System (通配符在DNS中的作用)

RFC 4635 - HMAC SHA TSIG Algorithm Identifiers (HMAC SHA TSIG算法标识符)

RFC 4701 - A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) (用于编码DHCP信息的DNS资源记录)

RFC 4892 - Requirements for a Mechanism Identifying a Name Server Instance (标识名称服务器实例的机制要求)

RFC 5001 - DNS Name Server Identifier (NSID) Option (DNS名称服务器标识符选项)

RFC 5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors (DNSSEC信任锚的自动更新)

RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (DNSSEC哈希认证的存在否定)

RFC 5452 - Measures for Making DNS More Resilient against Forged Answers (使DNS对伪造答案更具弹性的措施)

RFC 5625 - DNS Proxy Implementation Guidelines (DNS代理实现指南)

RFC 5702 - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (在DNSSEC的DNSKEY和RRSIG资源记录中使用RSA的SHA-2算法)

RFC 5936 - DNS Zone Transfer Protocol (AXFR) (DNS区域传输协议)

RFC 6195 - Domain Name System (DNS) IANA Considerations (DNS的IANA注意事项)

RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (基于DNS的命名实体认证的TLS协议: TLSA)

RFC 6840 - Clarifications and Implementation Notes for DNS Security (DNSSEC) (对DNSSEC的澄清和实现说明)

RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) (DNS的扩展机制)

RFC 6895 - Domain Name System (DNS) IANA Considerations (DNS的IANA注意事项)

RFC 7129 - Authenticated Denial of Existence in the DNS (DNS中经过身份验证的存在否定)

RFC 7216 - Use of Third-Party Authorization (TPA) Services for DNSSEC Signing and Provisioning (使用第三方授权服务进行DNSSEC签名和配置)

RFC 7344 - Automating DNSSEC Delegation Trust Maintenance (自动化DNSSEC授权信任维护)

RFC 7477 - Child-to-Parent Synchronization in DNS (DNS中的子级到父级同步)

RFC 7766 - DNS Transport over TCP - Implementation Requirements (通过TCP传输DNS - 实现要求)

RFC 7830 - The EDNS(0) Padding Option (EDNS(0)填充选项)

RFC 7873 - Domain Name System (DNS) Cookies (DNS Cookies)

RFC 8109 - Initializing a New Session with an Authoritative Server (使用权威服务器初始化新会话)

RFC 8198 - Aggressive Use of DNSSEC-Validated Cache (积极使用DNSSEC验证的缓存)

RFC 8499 - DNS Terminology (DNS术语)

RFC 8509 - A Root Key Trust Anchor Sentinel for DNSSEC (DNSSEC的根密钥信任锚标记)

RFC 8624 - Algorithm Implementation Requirements and Usage Guidance for DNSSEC (DNSSEC的算法实现要求和使用指南)

2. 报文格式

2.1 DNS基本格式

DNS查询、通知、更新报文有一个基本的12字节头部，整个消息在IPv4+UDP数据报中运载，限制在512字节大小，但某些特殊的DNS消息(如DNSSEC)会超过512字节限制。

在这里插入图片描述

在固定的12字节后面，跟着4个可变长的区段(section)：查询问题、回答、授权记录和额外记录，查询问题区域一般只有一个资源记录(Resource Record，RR)。

DNS固定头部中各字段含义如下：

事务ID，16位的标识符，用于匹配查询和响应报文。DNS客户端每次发送查询请求都会使用不同的 ID，而服务器在响应中重复这个ID。
QR，1位标志，指示报文是查询（0）还是响应（1）。
Opcode，4位字段，指定查询类型（标准查询、反向查询等）。
AA(Authoritative Answer)，1位标志，表示响应是否来自权威服务器。
TC(Truncated)，1位标志，指示报文是否被截断。如果应答报文超过512字节，使用UDP时只返回前512个字节。
RD(Recursion Desired)，1位标志，表示是否需要递归查询。
RA(Recursion Available)，1位标志，表示服务器是否支持递归查询。
Z：位保留字段，必须为零。
AD，1位标志，表示响应数据是否被认为是可信的(DNSSEC)。
CD，1位标志，表示是否禁用DNSSEC检查。
RCODE，4位字段，指示响应的状态(无错误、查询失败等)。
QDCOUNT，16位无符号整数，指定查询问题区域中的条目数。
ANCOUNT，16位无符号整数，指定回答区域中的资源记录数。
NSCOUNT，16位无符号整数，指定权威区域中的名称服务器记录数。
ARCOUNT，16位无符号整数，指定附加区域中的资源记录数。

以下是DNS响应报文中RCODE字段的几种常见错误码及其含义:

NOERROR(0)，表示成功响应，没有错误。
FORMERR(1)，表示服务器无法解读查询。这可能是因为查询报文的格式不正确或不完整。
SERVFAIL(2)，表示服务器在处理查询时遇到了问题。这可能是由于服务器配置错误、网络问题或其他内部故障引起的。
NXDOMAIN(3)，表示查询的域名不存在。这表明请求的域名在DNS系统中没有对应的记录。
NOTIMP(4)，表示服务器不支持请求的查询类型。这通常发生在服务器无法处理特定类型的查询(如DNSSEC相关查询)时。
REFUSED(5)，表示服务器由于策略原因拒绝执行查询。这可能是因为服务器被配置为不响应某些类型的查询，或者查询被认为是恶意的。
YXDOMAIN(6)，表示查询中的域名不应该存在(用于DNS UPDATE)。
YXRRSET(7)，表示查询中的资源记录集不应该存在(用于DNS UPDATE)。
NXRRSET(8)，表示查询的资源记录集不存在但应该存在(用于DNS UPDATE)。
NOTAUTH(9)，表示服务器不是查询域名的权威服务器(用于DNS UPDATE)。
NotZone(10)，表示在区域中不包含名称(用于DNS UPDATE)。

2.2 DNS名称和标签

DNS名称中的每一部分都称为标签，标签可分为数据标签和压缩标签两类。

数据标签是DNS名称的基本组成部分，它以一个字节的长度值开头，后跟实际的标签内容。标签内容可以是字母、数字或连字符(-)，但不能以连字符开头或结尾(遵守RFC1035)。数据标签的长度不能超过63字节，名称以值为0的字节结束，作为长度为零的标签。

例如，在DNS名称"www.example.com"中，“www”、"example"和"com"都是数据标签，它们分别表示为：

3www|7example|3com|0

压缩标签，为了减少DNS消息的大小，提高传输效率，DNS引入了压缩标签的概念。压缩标签以两个字节的指针形式出现，第一个字节的前两位为"11"，表示这是一个压缩标签，后14位则表示指向消息中某个位置的偏移量(从DNS消息开始位置计算，多达16383个字节)。

当DNS服务器解析压缩标签时，会根据指针指向的位置，跳转到消息中之前出现过的某个数据标签，从而避免了重复传输相同的标签内容。举个例子，假设DNS消息中先后出现了"www.example.com"和"ftp.example.com"两个名称，那么第二个名称可以表示为：

3www(数据标签)|0xC0 0x04(压缩标签，指向偏移量为4的位置，即"example.com"的起始处)

通过使用压缩标签，DNS消息的大小就可以显著减小，提高了传输效率。

2.3 TCP和UDP

DNS(Domain Name System)在传输数据时，根据不同的需求和场景，灵活地使用UDP(User Datagram Protocol)和TCP(Transmission Control Protocol)两种协议。

DNS优先使用UDP，在大多数情况下，DNS查询和响应都是通过UDP进行传输的。这是因为UDP具有以下优点：

速度快：UDP是无连接的协议，不需要建立和维护连接，可以快速地发送数据。
开销小：UDP消息头部较小，占用网络带宽少，适合传输短小的DNS消息。
简单高效：UDP的处理流程简单，服务器可以并发处理大量的DNS查询请求。

因此，对于普通的DNS查询，如A记录、AAAA记录、CNAME记录等，通常都是通过UDP进行传输的。

尽管UDP是DNS的首选传输协议，但在某些特定情况下，DNS也会使用TCP进行数据传输：

响应消息过长：当DNS响应消息的长度超过UDP的最大传输单元(Maximum Transmission Unit，MTU)时，服务器会将响应消息截断，并设置TC(Truncated)标志位。客户端收到截断的响应后，会重新发起一个TCP连接，请求完整的响应消息。
区域传输：当主从DNS服务器之间进行区域传输(Zone Transfer)时，通常使用TCP协议。区域传输涉及大量的DNS记录，使用TCP可以保证数据的完整性和可靠性。
客户端请求：某些DNS客户端或工具可能会显式地请求使用TCP进行数据传输，以满足特定的需求，如安全性、可靠性等。

2.4 DNS查询和资源记录格式

问题区域由以下三个字段组成：

QNAME：查询的域名，以长度+标签的形式编码。
QTYPE：2个字节，查询的资源记录类型，如A、AAAA、CNAME等。
QCLASS：2个字节，查询的类别，通常为IN(Internet)(1)，1表示互联网类，254表示没有类，255表示所有类。

下面是一个问题区域的示例：

|         QNAME         |  QTYPE |  QCLASS |
|0x7|example|0x3|com|0x0|  0x01  |  0x01   |

在这个例子中，QNAME:7example3com0(表示example.com)，QTYPE:0001(表示A记录)，QCLASS:0001(表示IN)。

DNS资源记录都遵循以下通用格式：

|       NAME     | CLASS   | TYPE |  TTL |  RDLENGTH  |   RDATA   |
|www.example.com.|  IN(1)  |   A  | 3600 |     4      | 192.0.2.1 |

其中字段含义如下：

NAME，可变长度，域名，表示该记录所关联的域名。
CLASS，16位，记录的类别，通常为IN(Internet)(1)。
TYPE，16位，记录的类型，如A、AAAA、CNAME等。
TTL，32位，生存时间(Time-To-Live)，指定该记录在缓存中的有效时间，以秒为单位。
RDLENGTH，16位，定义资源数据(RDATA)的长度，单位是字节。
RDATA，记录的数据部分，根据不同的记录类型而有所不同。

2.5 资源记录类型

值	RR类型	参考RFC	描述和目的
1	A	RFC 1035	IPv4地址记录，用于将主机名映射到IPv4地址。
2	NS	RFC 1035	名称服务器，指定负责给定区域的权威DNS服务器。
5	CNAME	RFC 1035	规范名称，为域名创建别名，将一个域名映射到另一个域名。
6	SOA	RFC 1035	授权开始，指定有关DNS区域的权威信息，包括主要名称服务器、管理员电子邮件等。
12	PTR	RFC 1035	指针，提供反向DNS查找，将IP地址映射回域名。
15	MX	RFC 1035	邮件交换器，指定负责接收给定域名电子邮件的邮件交换服务器。
16	TXT	RFC 1035	文本，允许将任意文本信息与域名关联，常用于SPF、DKIM等电子邮件验证机制。
28	AAAA	RFC 3596	IPv6地址记录，用于将主机名映射到IPv6地址。
33	SRV	RFC 2782	服务器选择，指定提供特定服务的服务器的位置（主机名和端口号）。
35	NAPTR	RFC 3403	名称授权指针，支持交替的名称空间。
41	OPT	RFC 2671	伪RR，支持更大的数据报、标签、EDNS0中的返回码。
251	IXFR	RFC 1995	增量区域传输。
252	AXFR	RFC 1035	完全区域传输，通过TCP运载。
255	(ANY)	RFC 1035	请求任意记录。

3. 实践

3.1 地址和名称服务器记录

DNS中最常见的三种资源记录类型：A记录、AAAA记录和NS记录。

A记录(Address Record)，A记录是最基本且最常用的DNS记录类型。它将域名映射到IPv4地址。当在浏览器中输入一个网址时，DNS会查找该域名的A记录，获取对应的IP地址，然后建立连接。
AAAA记录(IPv6 Address Record)，随着IPv6的逐渐普及，AAAA记录变得越来越重要。与A记录类似，AAAA记录将域名映射到IPv6地址。IPv6地址是128位长，使用冒号十六进制记法表示，如2606:2800:220:1:248:1893:25c8:1946。
NS记录(Name Server Record)，NS记录指定了负责管理某个DNS区域的权威DNS服务器。当查询一个域名时，首先会查询根域名服务器，然后根据NS记录的指示，查询负责该域名的权威DNS服务器，最终获得所需的IP地址。

下面是对onceday.work的查询例子，dig命令是一个常用的DNS查询工具，用于从命令行界面查询DNS信息:

ubuntu->~:$ dig +nostats -t any onceday.work; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +nostats -t any onceday.work
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9239
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;onceday.work. IN ANY;; ANSWER SECTION:
onceday.work. 600 IN A 175.24.226.210
onceday.work. 86400 IN NS hairtail.dnspod.net.
onceday.work. 86400 IN NS contract.dnspod.net.
onceday.work. 180 IN SOA contract.dnspod.net. freednsadmin.dnspod.com. 1706248824 3600 180 1209600 180

下面是对输出内容的解释：

第一行显示了dig的版本信息和输入的查询参数：+nostats表示不显示查询统计信息，-t any表示查询所有类型的DNS记录，onceday.work是要查询的域名。
第二行显示了全局选项，+cmd表示显示完整的dig命令。
接下来的几行显示了DNS服务器的响应概要：
- opcode: QUERY表示这是一个标准的DNS查询。
- status: NOERROR表示查询成功，没有错误。
- id: 9239是该查询的唯一标识符。
- flags: qr rd ra表示这是一个响应(qr)，且允许递归查询(rd)，并且服务器支持递归查询(ra)。
- QUERY: 1表示查询段有1个问题。
- ANSWER: 4表示回答段有4个资源记录。
- AUTHORITY: 0表示授权段没有记录。
- ADDITIONAL: 1表示附加段有1个记录。
OPT PSEUDOSECTION显示了EDNS（扩展DNS）的信息，包括EDNS版本和UDP包大小限制。
QUESTION SECTION显示了查询的问题，即查询onceday.work的所有类型(ANY)的DNS记录。

ANSWER SECTION包含了实际的DNS记录答案：

第一行显示了onceday.work的A记录，IP地址为175.24.226.210，生存时间(TTL)为600秒。
第二、三行显示了onceday.work的NS记录，表明负责该域的权威DNS服务器为hairtail.dnspod.net和contract.dnspod.net，生存时间为86400秒。
第四行显示了onceday.work的SOA记录，提供了有关该DNS区域的权威信息，如主要名称服务器、管理员电子邮件、序列号、刷新时间等，生存时间为180秒。

下面是使用Wireshark抓到的DNS查询报文，如下：

在这里插入图片描述

可以看到查询消息非常简单，IP+UDP封装，源端口随机选择，目的地址是DHCP分配的DNS服务器。DNS部分以事务ID(0xe44a)开头，Flags标记里面只设置了RD(需要做递归查询)，并且带有一个问题，其他的区段都是空的。

该查询消息指定查询域名为api.safe.360.cn，类型为A(IP地址)，类型为互联网，响应消息如下：

在这里插入图片描述

响应消息的事务ID和查询消息相匹配，且RD和RA都设置为1，问题区段是查询消息的副本，并且同时包含授权记录和额外记录。额外记录信息中包含dnsx.360safe.com域名对应的IP地址，这些域名是授权名称服务器，用于对360.cn域名提供DNS查询服务(减少重复查询，发出DNS报文需要知道授权名称服务器的IP地址)。该响应消息来自于缓存的数据，因为授权标志并未设立。

3.2 规范名称(CNAME，canonical name)

CNAME(Canonical Name)是DNS(域名系统)中的一种资源记录类型，用于创建域名的别名。它允许将一个域名映射到另一个域名，而不是直接映射到IP地址。当查询一个具有CNAME记录的域名时，DNS服务器将返回CNAME记录指向的另一个域名，然后DNS客户端将继续查询该新域名以获取最终的IP地址。

CNAME记录提供了一种创建域名别名的方法，与A记录和AAAA记录直接将域名映射到IP地址不同，CNAME记录创建的是域名到域名的映射。当查询具有CNAME记录的域名时，DNS服务器将返回CNAME记录指向的另一个域名，而不是IP地址。

例如，如果有一个域名 www.example.com，并且希望它指向 example.com，那么可以为 www.example.com 创建一个 CNAME 记录，指向 example.com。

CNAME记录中指向的域名被称为规范名称（Canonical Name）。规范名称应该是一个真实存在的、具有A记录或AAAA记录的域名。

CNAME记录可以创建一个记录链，其中一个CNAME记录指向另一个CNAME记录，最终指向一个A记录或AAAA记录。但是，为了避免出现无限循环，CNAME记录链不能形成环路。

由于CNAME记录是将一个域名映射到另一个域名，因此在DNS区域的顶级域名（如example.com）上不能使用CNAME记录。此外，如果一个域名已经有了其他类型的DNS记录（如A记录、MX记录等），就不能再为它创建CNAME记录。

一个典型的例子是www.baidu.com，如下所示：

ubuntu->~:$ host -t any www.baidu.com
www.baidu.com is an alias for www.a.shifen.com.
ubuntu->~:$ host -t any www.a.shifen.com
www.a.shifen.com has address 153.3.238.110
www.a.shifen.com has address 153.3.238.102
www.a.shifen.com has IPv6 address 2408:873d:22:18ac:0:ff:b021:1393
www.a.shifen.com has IPv6 address 2408:873d:22:1a01:0:ff:b087:eecc

3.3 逆向查询(PTR)

DNS逆向查询，也称为PTR（Pointer）记录查询，是一种特殊类型的DNS查询，用于将IP地址映射回域名。与常规的DNS查询（将域名转换为IP地址）相反，逆向查询通过IP地址查找相应的域名。

PTR记录存储在一个特殊的DNS区域中，称为"in-addr.arpa"(用于IPv4)或"ip6.arpa"(用于IPv6)。这些特殊区域的域名是IP地址的反向表示形式。例如，IPv4地址"192.0.2.1"的反向DNS查询将在"1.2.0.192.in-addr.arpa"域名下查找PTR记录。

PTR记录提供了一种将IP地址映射回域名的方法。这对于某些网络服务和应用程序非常重要，例如邮件服务器，它们通常需要验证连接客户端的域名以防止垃圾邮件。

在反向DNS区域中，IP地址的表示方式与正常书写方式相反。对于IPv4地址，四个八位字节以相反的顺序表示，并以".in-addr.arpa"结尾。例如，“192.0.2.1"变为"1.2.0.192.in-addr.arpa”。

一个IP地址可能有多个关联的域名，因此在反向DNS区域中，一个IP地址可能有多个PTR记录。然而，通常建议每个IP地址只使用一个PTR记录，以避免混淆。

下面是一个实际例子:

ubuntu->~:$ dig  -x 8.8.8.8; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29880
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.          IN      PTR;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.   7155    IN      PTR     dns.google.;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Aug 15 23:23:48 CST 2024
;; MSG SIZE  rcvd: 73

3.4 权威记录(SOA)

DNS的SOA（Start of Authority）记录是一种特殊的资源记录类型，用于定义DNS区域的权威信息。每个DNS区域都必须有一个SOA记录，它位于区域文件的开头，提供了有关该区域的关键管理细节。以下是SOA记录中包含的主要字段和参数：

主名称服务器：SOA记录指定了该DNS区域的主要名称服务器（Primary Name Server）。这通常是一个完全限定域名（FQDN），表示对该区域具有权威性的DNS服务器。
责任人的电子邮件：SOA记录包含了对该DNS区域负责的管理员的电子邮件地址。然而，出于安全原因，该地址中的"@“符号被替换为”."。
序列号：序列号是一个整数值，用于表示区域文件的版本。每次修改区域文件时，都应增加序列号。从属DNS服务器使用序列号来确定是否需要更新其区域数据。
刷新时间：刷新时间指定了从属DNS服务器应该多久向主DNS服务器查询SOA记录以检查区域文件的更新。这是一个以秒为单位的时间间隔。
重试时间：如果从属DNS服务器无法联系主DNS服务器，重试时间指定了它应该等待多长时间后再次尝试。这也是一个以秒为单位的时间间隔。
过期时间：过期时间定义了从属DNS服务器在无法联系到主DNS服务器的情况下，可以继续提供区域数据的最长时间。当达到过期时间后，从属服务器将停止answering该区域的查询。
默认TTL：默认TTL（Time to Live）指定了在没有明确定义TTL的情况下，区域中所有资源记录的默认缓存时间。这是一个以秒为单位的值。

下面是一个SOA记录的示例：

ubuntu->~:$ nslookup 
> set type=soa
> www.baidu.com
Server:         127.0.0.53
Address:        127.0.0.53#53Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com.Authoritative answers can be found from:
a.shifen.comorigin = ns1.a.shifen.commail addr = baidu_dns_master.baidu.comserial = 2408150045refresh = 5retry = 5expire = 2592000minimum = 3600

SOA记录对于维护DNS区域的一致性和可靠性非常重要，它提供了有关区域管理的关键信息，促进了主DNS服务器和从属DNS服务器之间的同步，并为区域数据的缓存和更新提供了指导。

3.5 邮件交换记录(MX)

DNS的MX(Mail Exchange)记录是一种资源记录类型，用于指定负责处理发送到某个域名的电子邮件的邮件服务器。当向一个域名发送电子邮件时，发送邮件服务器将查询该域名的MX记录，以确定应将邮件传递到哪个邮件服务器。

邮件服务器的标识：MX记录标识了接收发送到某个域名的电子邮件的邮件服务器。这些邮件服务器通常被称为邮件交换服务器或邮件中继服务器。
优先级：每个MX记录都有一个关联的优先级值，该值是一个0到65535之间的整数。较低的数值表示更高的优先级。当有多个MX记录时，优先级用于确定邮件服务器的顺序。
多个MX记录：一个域名可以有多个MX记录，每个记录指向不同的邮件服务器。这提供了冗余和负载平衡的能力。如果优先级最高的邮件服务器不可用，发送邮件服务器将尝试下一个优先级最高的服务器，以此类推。
完全限定域名（FQDN）：MX记录中指定的邮件服务器使用FQDN表示，而不是IP地址。这允许更灵活地更改邮件服务器的IP地址，而不必更新DNS记录。
与A记录和AAAA记录的关系：尽管MX记录使用FQDN来标识邮件服务器，但这些服务器仍然需要A记录（用于IPv4）或AAAA记录（用于IPv6）来解析其IP地址。

下面是一个包含多个MX记录的示例：

> set type=mx
> baidu.com
Server:         127.0.0.53
Address:        127.0.0.53#53Non-authoritative answer:
baidu.com       mail exchanger = 20 jpmx.baidu.com.
baidu.com       mail exchanger = 20 mx50.baidu.com.
baidu.com       mail exchanger = 20 usmx01.baidu.com.
baidu.com       mail exchanger = 10 mx.maillb.baidu.com.
baidu.com       mail exchanger = 20 mx1.baidu.com.
baidu.com       mail exchanger = 15 mx.n.shifen.com.Authoritative answers can be found from:
baidu.com       internet address = 39.156.66.10
baidu.com       internet address = 110.242.68.66

3.6 文本记录(TXT)

DNS的TXT(Text)记录在垃圾邮件防范和电子邮件身份验证方面有重要的作用：

垃圾邮件防范，MX记录指定负责接收发送到域的电子邮件的邮件服务器。垃圾邮件过滤器和邮件服务器通常在接受传入的电子邮件之前检查发件人域的MX记录，以验证发送服务器是否被授权发送该域的电子邮件。

TXT记录用于实现基于DNS的垃圾邮件防范机制，如SPF（Sender Policy Framework）和DMARC（Domain-based Message Authentication, Reporting, and Conformance）。这些机制使用TXT记录来指定允许发送域的电子邮件的IP地址或服务器。
电子邮件身份验证，SPF使用TXT记录来指定允许发送域的电子邮件的服务器。当邮件服务器收到传入的电子邮件时，它会检查发件人域的SPF TXT记录，以验证发送服务器是否被授权发送该域的电子邮件。

DKIM（DomainKeys Identified Mail）使用TXT记录来发布用于对电子邮件进行数字签名的公钥。接收邮件服务器使用此公钥来验证电子邮件的DKIM签名，以确保电子邮件在传输过程中没有被篡改。

DMARC依赖于SPF和DKIM，使用TXT记录来发布域的电子邮件身份验证策略和报告首选项。它指示接收邮件服务器如何处理未通过SPF或DKIM验证的电子邮件。
电子邮件路由和传递，MX记录是电子邮件路由和传递的基础。它们指定负责接收发送到域的电子邮件的邮件服务器，并允许多个邮件服务器以优先级顺序列出，以实现冗余和负载平衡。

TXT记录主要用于身份验证和垃圾邮件防范，此外某些电子邮件服务和协议(如AutoDiscover服务)也使用TXT记录来发布电子邮件配置信息，这可以简化电子邮件客户端的设置过程。

下面是baidu.com的示例：

> set type=txt
> baidu.com
Server:         127.0.0.53
Address:        127.0.0.53#53Non-authoritative answer:
baidu.com       text = "google-site-verification=GHb98-6msqyx_qqjGl5eRatD3QTHyVB6-xQ3gJB5UwM"
baidu.com       text = "v=spf1 include:spf1.baidu.com include:spf2.baidu.com include:spf3.baidu.com include:spf4.baidu.com -all"
baidu.com       text = "9279nznttl321bxp1j464rd9vpps246v"
baidu.com       text = "_globalsign-domain-verification=qjb28W2jJSrWj04NHpB0CvgK9tle5JkOq-EcyWBgnE"

3.7 选线OPT伪记录

DNS选项OPT伪记录是DNS协议的一个扩展机制，用于在DNS查询和响应中传递额外的信息。它不是一个真正的DNS资源记录类型，而是附加在DNS消息中的一个特殊伪记录。OPT伪记录的引入，极大地增强了DNS协议的灵活性和可扩展性。

OPT伪记录的主要作用包括：

指示DNS消息的接收者支持EDNS(Extension Mechanisms for DNS)扩展。通过在DNS请求中包含OPT伪记录，客户端可以告知服务器它支持EDNS。
协商UDP负载大小(UDP payload size)。传统DNS消息通过UDP传输时，报文大小被限制在512字节以内。而通过OPT伪记录协商更大的UDP负载，可以避免使用TCP传输，从而提高DNS解析效率。
传递扩展标志和选项。OPT伪记录提供了一个灵活的框架，可以在DNS请求和响应中携带额外的标志位和选项字段，实现新的功能扩展。例如，DNSSEC(DNS Security Extensions)利用OPT伪记录传递密钥标签和验证结果等信息。

下面是一个包含OPT伪记录的DNS请求报文示例：

;; QUESTION SECTION:
;www.example.com.               IN      A;; ADDITIONAL SECTION:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

在这个例子中，客户端发起了一个针对www.example.com的A记录查询。同时，在附加区域(Additional Section)中包含了一个OPT伪记录。该伪记录指示客户端支持EDNS版本0，设置了DNSSEC OK（DO）标志，并且请求使用4096字节的UDP负载大小。

3.8 服务记录(SRV)

DNS服务记录(Service Record，SRV记录)是DNS协议中的一种资源记录类型，用于指定提供特定服务的服务器的位置(主机名和端口号)。SRV记录允许服务的提供者在DNS中发布服务实例的信息，使得服务的使用者能够通过查询DNS来定位和连接服务。

SRV记录的格式如下：

_服务._协议.名称.TTL IN SRV 优先级 权重 端口 目标

其中：

“服务"表示服务的符号名称，例如"http”、"ldap"等。
“协议"表示服务使用的传输协议，通常是"tcp"或"udp”。
"名称"表示服务所在的域名。
"TTL"表示记录的生存时间（Time-To-Live）。
"优先级"和"权重"用于在多个服务实例间进行负载均衡和故障转移。
"端口"指定服务监听的端口号。
"目标"指定提供服务的服务器的规范主机名（FQDN）。

下面是一个SRV记录的示例：

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 bigbox.example.com.

这个SRV记录表示在example.com域中，使用TCP协议的SIP（Session Initiation Protocol）服务的一个实例位于bigbox.example.com服务器上，监听5060端口。该记录的优先级为10，权重为60。

SRV记录的主要应用场景包括：

服务发现和负载均衡，通过在DNS中发布多个SRV记录，服务提供者可以实现服务的负载均衡和高可用性。服务使用者根据SRV记录中的优先级和权重选择合适的服务实例进行连接。
协议独立性。SRV记录允许服务使用者在不了解服务器IP地址和端口的情况下，通过服务名称和协议类型来定位服务。这提供了一层协议独立性，使得服务的部署和迁移更加灵活。
服务的动态配置。通过在DNS中动态更新SRV记录，服务提供者可以实现服务的动态扩容、缩容和故障转移，而无需修改服务使用者的配置。

3.9 名称授权指针记录(NAPTR记录)

名称授权指针记录(NAPTR记录)：NAPTR记录是一种DNS资源记录类型，用于将一个域名映射到另一个域名或服务。它通过正则表达式和替换规则，将输入的域名转换为目标域名或服务的URI(Uniform Resource Identifier)。NAPTR记录常用于实现服务的动态查找和转换，如电子邮件路由、电话号码映射等。

NAPTR记录的格式如下：

域名 TTL 		IN NAPTR 顺序 优先级 标志 服务      正则表达式                      替换
example.com. IN NAPTR 100 10    "u" "E2U+sip" "!^.*$!sip:info@example.com!" .

这个NAPTR记录表示将example.com域名映射到SIP服务的URI sip:info@example.com。

ENUM(E.164 Number Mapping)：ENUM是一种基于DNS的电话号码映射机制，将传统的电话号码转换为互联网上的资源标识符(如SIP URI、电子邮件地址等)。ENUM使用DNS的NAPTR记录来存储电话号码到URI的映射关系，通过查询DNS，可以将电话号码解析为对应的互联网资源。

ENUM使用特定的域名格式来表示电话号码，例如：

4.3.2.1.5.5.5.1.2.1.2.1.e164.arpa.

其中，4.3.2.1.5.5.5.1.2.1.2.1是将电话号码+1-212-555-1234反转后的数字序列，e164.arpa是ENUM使用的特定域名后缀。

SIP(Session Initiation Protocol)：SIP是一种用于创建、修改和终止多媒体会话（如语音、视频通话等）的应用层协议。SIP使用URI（如sip:user@domain）来标识和定位通信参与者。在DNS中，SIP服务通常使用SRV记录和NAPTR记录来发布服务实例的位置信息，以实现服务的发现和路由。

URI/URN解析：URI(Uniform Resource Identifier)和URN(Uniform Resource Name)是用于标识互联网资源的标准机制。URI包括URL(Uniform Resource Locator)和URN两种子类型。DNS在URI/URN解析中起着重要的作用，通过NAPTR记录和SRV记录，可以将URI/URN映射到具体的服务位置或协议端点。

例如，使用NAPTR记录可以将URN urn:service:example解析为对应的URI http://example.com/service：

example.com. IN NAPTR 100 10 "" "" "!^urn:service:example$!http://example.com/service!" .

3.10 DNS更新

DNS动态更新（Dynamic DNS Update）是一种允许DNS客户端动态添加、修改或删除DNS记录的机制。传统的DNS是静态的，记录的创建和维护通常由管理员手动完成。而DNS动态更新提供了一种自动化的方式，使得DNS记录能够实时地反映网络中主机和服务的变化。

DNS动态更新的主要功能和特点包括：

实时更新：通过DNS动态更新，客户端可以在运行时即时更新DNS记录，而无需管理员的手动干预。这对于动态分配IP地址的网络环境（如DHCP）尤为重要，确保DNS记录与实际的网络配置保持同步。
安全性：DNS动态更新使用TSIG(Transaction Signature)或SIG(0)(Signature 0)等机制对更新请求进行身份验证和完整性保护，防止未经授权的修改。只有通过身份验证的客户端才能执行DNS记录的更新操作。
灵活性：DNS动态更新支持添加、修改和删除各种类型的DNS记录，包括A、AAAA、CNAME、PTR、SRV等。客户端可以根据需要动态更新不同的记录类型，以反映网络中的变化。
集成性：DNS动态更新与其他网络协议和服务紧密集成，如DHCP、Active Directory等。例如，DHCP服务器可以在为客户端分配IP地址的同时，自动触发相应的DNS动态更新，将客户端的主机名和IP地址添加到DNS中。

DNS动态更新的工作流程通常如下：

客户端向DNS服务器发送一个动态更新请求，该请求包含要添加、修改或删除的DNS记录。
DNS服务器接收到更新请求后，对请求进行身份验证，确保客户端有权执行更新操作。
如果身份验证通过，DNS服务器将根据请求中的信息更新相应的DNS记录。
DNS服务器将更新后的记录传播到其他DNS服务器，以确保全网的一致性。

下面是一个使用nsupdate工具执行DNS动态更新的示例：

$ nsupdate
> server dns.example.com
> update add client1.example.com. 3600 IN A 192.168.1.100
> send

在这个例子中，客户端向DNS服务器dns.example.com发送一个动态更新请求，将主机名client1.example.com的A记录设置为192.168.1.100，TTL为3600秒。

3.11 DNS区域传输和通知

DNS区域传输和DNS通知是DNS协议中用于在DNS服务器之间同步和更新区域数据的两种机制。

DNS区域传输(DNS Zone Transfer)：DNS区域传输是一种用于在主DNS服务器和从DNS服务器之间复制整个区域数据的机制。它确保从服务器拥有与主服务器相同的区域数据副本，提供了冗余和负载均衡的能力。

DNS区域传输使用TCP协议，通过AXFR(完全区域传输)或IXFR(增量区域传输)两种方式进行：

AXFR：从服务器向主服务器发送AXFR请求，主服务器将整个区域的所有记录发送给从服务器，从服务器使用接收到的数据完全替换其本地的区域数据。
IXFR：从服务器向主服务器发送IXFR请求，并提供其当前的SOA(Start of Authority)记录。主服务器比较从服务器的SOA记录与自己的SOA记录，并发送自上次区域传输以来发生变化的增量数据。从服务器使用增量数据更新其本地的区域数据。

为了安全起见，DNS区域传输通常使用TSIG(Transaction Signature)对传输的数据进行身份验证和完整性保护，防止未经授权的访问和修改。

DNS通知(DNS Notify)：DNS通知是一种用于在DNS服务器之间实时通知区域变化的机制。当主DNS服务器上的区域数据发生更改时，它会向从服务器发送DNS通知消息，通知它们需要进行区域传输以获取最新的数据。

DNS通知使用UDP协议，主要流程如下：

当主DNS服务器上的区域数据发生变化时，主服务器向从服务器发送一个DNS通知消息，该消息包含了区域的SOA记录。
从服务器接收到DNS通知消息后，比较消息中的SOA记录与自己的SOA记录。如果发现区域数据有更新，从服务器将向主服务器发起一个区域传输请求（AXFR或IXFR）。
主服务器响应区域传输请求，将更新后的区域数据发送给从服务器。
从服务器接收到更新后的区域数据，更新自己的本地数据，完成同步。

DNS通知机制大大缩短了从服务器获取区域更新的时间，提高了DNS系统的实时性和一致性。

3.12 DNS64转换

DNS64是一种机制，用于在仅支持IPv6的网络中实现IPv4服务的访问。它主要解决了在IPv6网络中访问IPv4资源的问题，提供了一种过渡机制，使得IPv6网络能够与IPv4网络进行通信。

DNS64的主要功能是将IPv4地址嵌入到IPv6地址中，并与网络地址转换64(NAT64)配合使用。具体工作原理如下：

当IPv6客户端需要访问IPv4服务时，它会向DNS64服务器发送一个DNS查询请求，请求解析服务的域名。
DNS64服务器收到查询请求后，首先尝试查找该域名的AAAA记录(IPv6地址)。
如果找到了AAAA记录，DNS64服务器将直接返回IPv6地址给客户端。
如果没有找到AAAA记录，DNS64服务器会再查找该域名的A记录(IPv4地址)。
如果找到了A记录，DNS64服务器将IPv4地址嵌入到一个特定的IPv6前缀中，生成一个合成的IPv6地址(称为IPv4-embedded IPv6地址)，并将其返回给客户端。
客户端收到合成的IPv6地址后，将使用该地址与服务端进行通信。
当数据包到达NAT64网关时，NAT64网关将提取出嵌入的IPv4地址，并将IPv6数据包转换为IPv4数据包，然后将其转发到实际的IPv4服务器。
IPv4服务器处理请求并返回响应，NAT64网关将IPv4响应包转换回IPv6格式，并将其发送给客户端。

通过DNS64和NAT64的配合，IPv6客户端可以透明地访问IPv4服务，而无需修改客户端或服务器的配置。

3.13 本地DNS(LLMNR和mDNS)

LLMNR（Link-Local Multicast Name Resolution）和mDNS（Multicast DNS）是两种用于在局域网内解析主机名的协议。它们提供了一种在没有传统DNS服务器的情况下，实现主机名到IP地址映射的方法。

LLMNR(Link-Local Multicast Name Resolution)：LLMNR是一种基于多播的名称解析协议，由Microsoft开发，用于在局域网内解析主机名。其工作原理如下：

当一个主机需要解析另一个主机的名称时，它会在局域网内发送一个LLMNR查询消息，该消息使用的是多播地址224.0.0.252(IPv4)或FF02::1:3(IPv6)。
局域网内的所有主机都会接收到这个多播查询消息。
如果某个主机的主机名与查询的名称匹配，它会响应一个LLMNR应答消息，其中包含自己的IP地址信息。
查询主机接收到应答消息后，就可以获得目标主机的IP地址，并与其进行通信。

LLMNR使用UDP端口5355，并且支持IPv4和IPv6网络。它提供了一种在没有DNS服务器的小规模网络中进行主机名解析的简便方法。

mDNS(Multicast DNS)：mDNS是另一种基于多播的名称解析协议，由Apple公司开发，用于在局域网内实现主机名和服务发现。mDNS也被称为Bonjour或Zeroconf。其工作原理如下：