UD5工具箱
专业术语表
以下是与 DNS、DoH 和网络安全相关的核心术语，按字母顺序排列。
DNS（Domain Name System，域名系统）
DNS 是互联网的核心命名系统，负责将人类可读的域名（如 www.example.com）转换为计算机可识别的 IP 地址（如 93.184.216.34）。DNS 采用分层的树状结构，从根域名服务器（root）开始，依次经过顶级域名（TLD）服务器、二级域名服务器，直到最终的权威名称服务器。整个 DNS 系统由全球分布的数百万台 DNS 服务器共同运营。DNS 最初设计于 1983 年，使用 UDP/TCP 53 端口进行明文查询和响应。由于缺乏加密和认证机制，传统 DNS 容易受到各种安全威胁，这促使了 DNSSEC、DoT 和 DoH 等安全增强技术的发展。DNS 不仅用于将域名解析为 IP 地址，还承担着邮件路由（MX 记录）、服务发现（SRV 记录）、安全策略（TXT、CAA 记录）等多种功能。
DoH（DNS over HTTPS）
DoH 是一种通过 HTTPS 协议传输 DNS 查询的加密协议，定义在 RFC 8484 中。DoH 将 DNS 查询和响应封装在标准的 HTTPS 请求和响应中，使用 443 端口进行通信。这使得 DNS 查询流量与普通的 Web 浏览流量无法区分，从而提供了更好的隐私保护和抗审查能力。DoH 支持 GET 和 POST 两种请求方法：GET 方法将 DNS 查询编码到 URL 的查询参数中，POST 方法将 DNS 查询二进制数据放在请求体中。DoH 服务器返回的响应 Content-Type 为 application/dns-message，包含标准的 DNS 响应二进制数据。目前 Chrome、Firefox、Edge 和 Safari 等主流浏览器都已内置了 DoH 客户端支持。DoH 的主要优势在于其与 HTTPS 流量的完全融合，使其难以被网络审查者识别和封锁。
DoT（DNS over TLS）
DoT 是一种通过 TLS 加密传输 DNS 查询的协议，定义在 RFC 7858 中。与 DoH 使用 HTTPS 协议不同，DoT 直接在 TCP 连接上建立 TLS 加密层，使用专用的 853 端口。DoT 的优点是协议简洁，不涉及额外的 HTTP 层封装，与传统 DNS 的概念模型更一致。缺点是使用了独立的端口号（853），容易被防火墙识别和封锁。DoT 通常使用端口 853 进行通信，但也可以通过端口 443 进行" opportunistic TLS"模式的通信。在实际部署中，DoT 的隐私保护效果略优于 DoH，因为 DoH 需要额外的 HTTP 头部信息，而 DoT 只传输纯 DNS 数据。然而，DoH 在抗审查能力方面优于 DoT，因为封锁 443 端口会影响正常的 Web 访问。Google Android 9.0 及以上版本默认使用 DoT 作为系统级 DNS 加密方案。
DNSSEC（DNS Security Extensions，DNS 安全扩展）
DNSSEC 是一组用于保护 DNS 数据完整性的密码学扩展，定义在 RFC 4033-4035 中。DNSSEC 通过数字签名机制确保 DNS 响应数据在传输过程中未被篡改或伪造。其核心机制包括：使用私钥对 DNS 记录进行签名（RRSIG 记录），将公钥以 DNSKEY 记录的形式发布在 DNS 中，通过信任链（Trust Chain）从根域开始逐级验证签名的有效性。DNSSEC 解决了 DNS 缓存投毒和响应伪造等安全问题，但它不提供数据加密（即查询内容仍然是明文的），也不保护用户隐私。DNSSEC 的部署需要域名所有者对 DNS 记录进行签名，并需要 ISP 或递归解析器支持 DNSSEC 验证。目前全球 DNSSEC 的部署率仍然较低，但正在逐步增长。
TLS（Transport Layer Security，传输层安全）
TLS 是互联网上最广泛使用的加密协议，用于保护网络通信的机密性、完整性和认证性。TLS 是 SSL（Secure Sockets Layer）的继任协议，当前的最新版本是 TLS 1.3（定义在 RFC 8446 中）。TLS 在 HTTPS 中发挥着关键作用，它确保浏览器与 Web 服务器之间的通信不被窃听和篡改。TLS 协议的工作流程包括：握手阶段（协商加密算法、交换密钥、验证证书）和数据传输阶段（使用协商的密钥和算法进行对称加密通信）。TLS 1.3 相比之前的版本有显著的性能和安全性改进，包括减少了握手往返次数（支持 1-RTT 和 0-RTT 握手）、移除了不安全的加密算法、以及简化了协议握手过程。在 DoH 和 DoT 中，TLS 提供了 DNS 查询和响应的加密保护。
SPF（Sender Policy Framework，发件人策略框架）
SPF 是一种电子邮件认证协议，允许域名所有者在 DNS 中指定被授权代表该域名发送邮件的服务器 IP 地址。SPF 记录以 TXT 记录的形式发布在 DNS 中（如 v=spf1 include:_spf.google.com ~all）。当接收方邮件服务器收到邮件时，它会检查 SMTP 连接中 MAIL FROM 域名对应的 SPF 记录，验证发送服务器的 IP 是否在授权列表中。SPF 可以防止攻击者伪造发件人地址发送欺诈邮件。在 DNS over HTTPS 解析器中，查询域名的 TXT 记录可以查看 SPF 配置。SPF 的局限性在于它只验证 envelope sender（MAIL FROM），不验证邮件中显示给用户看的 From 头部，这需要 DMARC 来补充。
DMARC（Domain-based Message Authentication, Reporting, and Conformance）
DMARC 是一种电子邮件认证策略和报告协议，建立在 SPF 和 DKIM 之上。DMARC 允许域名所有者在 DNS 中发布策略（通过 _dmarc 子域名的 TXT 记录），指定当 SPF 或 DKIM 检查失败时应该如何处理邮件。DMARC 的核心要求是"对齐"（Alignment）：SPF 验证的域名或 DKIM 签名的 d= 域名必须与邮件中显示的 From 头部域名匹配。DMARC 支持三种策略级别：none（仅监控）、quarantine（放入垃圾箱）和 reject（直接拒绝）。DMARC 还支持通过聚合报告（rua）和取证报告（ruf）机制让域名所有者接收关于其域名邮件认证情况的统计报告。通过 DNS over HTTPS 解析器查询 _dmarc 子域名的 TXT 记录，可以查看和验证域名的 DMARC 策略配置。
A 记录（Address Record）
A 记录是最基本和最常用的 DNS 记录类型，用于将域名映射到 IPv4 地址。每个域名可以有多个 A 记录，实现简单的负载均衡和冗余。A 记录的数据格式为标准的 IPv4 点分十进制地址（如 93.184.216.34）。当用户在浏览器中输入域名时，DNS 解析器首先查找该域名的 A 记录，获取对应的 IPv4 地址，然后浏览器使用该地址建立 TCP 连接。如果域名同时配置了 A 记录和 AAAA 记录，支持 IPv6 的客户端通常会优先尝试 IPv6 连接（根据 Happy Eyeballs 算法）。A 记录的 TTL 值表示该记录在 DNS 缓存中的生存时间，TTL 越短，DNS 变更传播越快，但会增加 DNS 查询的频率。
AAAA 记录（IPv6 Address Record）
AAAA 记录（读作"quad-A"）用于将域名映射到 IPv6 地址，功能与 A 记录类似但针对 IPv6 协议。AAAA 记录的数据格式为标准的 IPv6 地址（如 2606:2800:220:1:248:1893:25c8:1946）。之所以称为"AAAA"是因为 IPv6 地址长度是 IPv4 地址的四倍（128 位 vs 32 位）。随着 IPv6 全球部署的推进，越来越多的网站同时配置了 A 和 AAAA 记录。支持 IPv6 的客户端会根据 Happy Eyeballs 算法（RFC 8305）来决定使用 IPv4 还是 IPv6 连接。通过 DoH 解析器同时查询 A 和 AAAA 记录，可以了解一个域名的 IPv6 部署状况。
MX 记录（Mail Exchange Record）
MX 记录是 DNS 中用于指定接收电子邮件的服务器的资源记录。每个 MX 记录包含两个关键信息：邮件服务器的主机名和优先级数值（优先级数值越小，优先级越高）。当发送方邮件服务器需要向用户@example.com 发送邮件时，它首先查询 example.com 域名的 MX 记录，获取目标邮件服务器列表，然后按照优先级从高到低尝试连接服务器。如果优先级最高的服务器不可用，会尝试下一个优先级的服务器，实现故障转移。一个域名可以配置多个 MX 记录来实现邮件服务的负载均衡和高可用性。MX 记录的数据格式为"优先级 主机名"，如"10 mail1.example.com 20 mail2.example.com"。通过 DoH 解析器查询 MX 记录，可以了解域名的邮件服务器配置。
TXT 记录（Text Record）
TXT 记录是一种通用的 DNS 记录类型，用于存储任意的文本信息。TXT 记录最初设计用于人类可读的注释信息，但现在被广泛用于各种自动化协议和安全机制。TXT 记录最常用于以下场景：SPF 记录（邮件发件人授权）、DKIM 公钥（邮件签名验证）、DMARC 策略（邮件认证策略）、域名验证（证明域名所有权）、ACME DNS-01 挑战（Let's Encrypt 自动证书签发）。每个域名可以有多个 TXT 记录，每条记录最长 255 个字符（可以分为多个字符串段）。TXT 记录的值通常遵循特定的格式规范（如 SPF 的 "v=spf1 ..." 格式）。通过 DoH 解析器查询 TXT 记录，可以全面了解域名的安全和服务配置。
CNAME 记录（Canonical Name Record）
CNAME 记录用于将一个域名（别名）指向另一个域名（规范名称）。当 DNS 解析器遇到 CNAME 记录时，它会继续解析指向的规范名称，最终获取到 A 或 AAAA 记录。CNAME 记录常用于将子域名指向第三方服务，例如将 www.example.com 指向 example.github.io（GitHub Pages），或将 api.example.com 指向 example.herokuapp.com（Heroku）。CNAME 记录的一个重要限制是不能与其他记录类型共存——如果一个域名有 CNAME 记录，它就不能同时拥有 A、AAAA、MX 等其他类型的记录（但有例外情况，如 CNAME 在区域顶点的应用，即 RFC 6761 定义的特殊用法）。通过 DoH 解析器查询 CNAME 记录，可以追踪域名的别名链，了解域名的实际指向。
SOA 记录（Start of Authority Record）
SOA 记录是 DNS 区域文件中的起始授权记录，包含关于该 DNS 区域的管理信息。每个 DNS 区域必须有且仅有一个 SOA 记录。SOA 记录包含以下关键字段：主名称服务器（MNAME）：负责该区域的主要 DNS 服务器；管理员邮箱（RNAME）：区域管理员的联系邮箱（用 @ 替换为 .）；序列号（Serial）：区域数据的版本号，每次修改后递增；刷新间隔（Refresh）：从服务器向主服务器请求更新的频率；重试间隔（Retry）：刷新失败后重试的等待时间；过期时间（Expire）：从服务器在无法联系主服务器后继续提供服务的最长时间；最小 TTL（Minimum）：负缓存 TTL，即 DNS 查询失败后结果被缓存的时间。SOA 记录对于理解 DNS 区域的管理和更新机制非常重要。
CORS（Cross-Origin Resource Sharing，跨域资源共享）
CORS 是一种浏览器安全机制，用于控制网页 JavaScript 代码对不同来源（Origin）资源的访问权限。在默认情况下，浏览器的同源策略（Same-Origin Policy）禁止网页 JavaScript 访问不同来源的资源。CORS 通过在 HTTP 响应中添加特定的头部字段（如 Access-Control-Allow-Origin）来放松这种限制。在 DoH 的语境中，CORS 对浏览器端的 DoH 客户端有重要影响。当网页 JavaScript 尝试直接向 DoH 服务器发送 HTTPS 请求时，如果 DoH 服务器没有在响应中设置合适的 CORS 头部，浏览器会阻止 JavaScript 读取响应内容。因此，公共 DoH 服务器（如 Google DNS、Cloudflare DNS）都需要在响应中配置 Access-Control-Allow-Origin: * 等 CORS 头部，以允许浏览器端的 JavaScript 客户端正常工作。