DNS资源A、MX、TXT、NS 记录详解

原创于 2025-09-17 09:09:43 发布 · 1.1k 阅读

CC 4.0 BY-SA版权

文章标签：

23 篇文章

订阅专栏

DNS（域名系统）可以理解为互联网的“电话簿”，它将人类可读的域名（如 www.google.com）转换为机器可读的 IP 地址（如 142.251.42.206）。资源记录（Resource Records, RRs）就是这个电话簿中的一条条具体条目。

作用：将域名指向一个 IPv4 地址。这是最基础、最常用的记录类型，用于告诉浏览器或应用程序某个域名对应的服务器在哪里。

功能：实现最基本的域名解析，让用户可以通过域名访问到网站、服务器或其他网络服务。
记录值：一个 IPv4 地址（例如：192.0.2.1）。
常见场景：
- 将 example.com 指向你的网站服务器 IP 192.0.2.1。
- 将 www.example.com 也指向同一个 IP 192.0.2.1。
- 将子域名 blog.example.com 指向另一个独立的服务器 IP 203.0.113.5。
示例：
- 主机记录：@ (或留空)
- 记录类型：A
- 记录值：192.0.2.1
- TTL：3600 (单位：秒)
- 解释：访问 example.com 将会解析到 IP 地址 192.0.2.1。

相关记录：

作用：指定负责接收发送到该域名的电子邮件的邮件服务器。当你发送一封邮件到 user@example.com 时，对方的邮件服务器会查询 example.com 的 MX 记录来决定该把这封邮件投递到哪台服务器。

功能：指引邮件路由，确保电子邮件能够送达正确的邮件服务器。
记录值：一个邮件服务器的主机名（如 mail.example.com）。注意：这里必须是一个域名，不能直接是 IP 地址。该域名通常需要有一个对应的 A 记录来解析出 IP。
优先级：MX 记录有一个额外的参数——优先级（Priority/Pref），是一个数字（0-65535）。数字越小，优先级越高。
- 你可以设置多个 MX 记录作为备份。邮件发送方会首先尝试投递到优先级最高的服务器；如果失败，则会尝试优先级较低的服务器。
常见场景：
- 使用 Google Workspace 或 Microsoft 365 的企业邮箱，需要配置 MX 记录指向他们的邮件服务器。
- 自建邮件服务器，配置 MX 记录指向自己的服务器域名。
示例：
- 主机记录：@ (表示根域名本身)
- 记录类型：MX
- 优先级：10
- 记录值：aspmx.l.google.com (Google 的主邮件服务器)
- 解释：发送到 @example.com 的邮件，将优先尝试投递到 aspmx.l.google.com。

作用：为域名提供文本信息。最初设计用于人工注释和说明，但现在主要用于各种验证和安全策略的传递，功能非常广泛。

功能：存放任意文本信息，但主要由机器读取，用于验证域名所有权、防止垃圾邮件、增强安全策略等。
记录值：一段文本字符串。
常见场景：
1. SPF (Sender Policy Framework)：一种反垃圾邮件技术，用于声明哪些邮件服务器有权代表你的域名发送邮件，以防止他人伪造你的域名发信。
  - 示例值：v=spf1 include:_spf.google.com ~all (表示允许 Google 的邮件服务器代表 example.com 发信)
2. DKIM (DomainKeys Identified Mail)：为发出的电子邮件添加数字签名，让接收方验证邮件确实来自你的域名且在传输过程中未被篡改。
3. DMARC (Domain-based Message Authentication, Reporting & Conformance)：建立在 SPF 和 DKIM 之上的策略，告诉接收方当认证失败时该如何处理邮件（如拒收或放入垃圾箱），并请求发送报告。
4. 域名所有权验证：许多第三方服务（如 Google Search Console, SSL 证书颁发机构等）会要求你在域名下添加一条特定的 TXT 记录内容，以证明你拥有该域名的管理权。
5. 其他用途，如 SSL 证书验证（如 Let‘s Encrypt的DNS-01挑战）、企业微信等应用配置也需要TXT记录验证。
示例：
- 主机记录：@
- 记录类型：TXT
- 记录值："v=spf1 include:spf.protection.outlook.com -all" (Microsoft 365 的 SPF 记录示例)

作用：指定由哪个权威DNS服务器来负责解析该域名。它定义了谁是你的域名的“终极权威答案来源”。

功能： Delegates a domain or subdomain to a set of name servers. 将域名的解析权委托给另一组DNS服务器。
记录值：一个DNS服务器的主机名（例如：ns1.example.com, dns1.hoster.com）。
层级关系：
- 全球根DNS服务器只负责返回顶级域（如 .com）的NS记录。
- .com 的DNS服务器则负责返回 example.com 的NS记录（你设置的）。
- 任何想解析 www.example.com 的递归DNS服务器，最终都必须去查询你在 example.com 的NS记录中指定的那组权威DNS服务器，才能得到正确的A记录答案。
常见场景：
- 当你购买域名后，需要在域名注册商那里设置NS记录，指向你的DNS托管服务商（如 Cloudflare, DNSPod, AWS Route 53 等）。
- 为子域名（如 sub.example.com）设置独立的解析服务（例如使用CDN提供商提供的NS服务器）。
示例：
- 主机记录：@
- 记录类型：NS
- 记录值：ns1.cloudflare.com
- 解释：这意味着 example.com 域名的权威解析服务器是 ns1.cloudflare.com，所有关于 example.com 及其子域名的查询最终都会被指引到 Cloudflare 的服务器。

它们如何协同工作？
以一个简单的网站和邮箱配置为例：

用户输入 www.example.com，递归DNS服务器首先查找 example.com 的 NS 记录，找到权威DNS服务器。
向该权威服务器查询 www.example.com 的 A 记录，获得IP地址，浏览器得以访问网站。
有人发送邮件到 @example.com，发送方服务器查询 example.com 的 MX 记录，找到邮件服务器地址（如 mail.example.com）。
发送方再查询 mail.example.com 的 A 记录，获得邮件服务器的IP，完成邮件投递。
接收方服务器可能会查询 example.com 的 TXT 记录（SPF/DKIM）来验证邮件的真实性。