DNS
DNS 记录类型
DNS 记录是域名与各类服务信息的映射表，解析时按记录类型返回不同答案。常见类型：
| 类型 | 作用 | 典型用法 |
|---|---|---|
| A | 域名 → IPv4 地址 | 最基础的解析记录 |
| AAAA | 域名 → IPv6 地址 | IPv6 场景 |
| CNAME | 域名 → 另一个域名 | 把子域名指向服务商提供的接入域名，服务商换 IP 时无需改记录 |
| MX | 指定接收该域名邮件的服务器 | 邮件路由，带优先级数字，越小越优先 |
| TXT | 存放任意文本 | 承载 SPF、DKIM、DMARC、域名归属验证 |
| NS | 指定该域名由哪些权威服务器解析 | 域名迁移时修改 |
| SRV | 域名 → 主机+端口 | 指定特定服务的服务端点 |
两条实用规则：
- CNAME 与其他记录互斥：同一域名不能同时有 CNAME 和 TXT/MX，所以邮件认证记录必须挂在专门的前缀下（如
send.、_dmarc.）。 - 下划线前缀是服务专用记录的惯例：
_dmarc.（DMARC 策略）、_domainkey.（DKIM 公钥）、_acme-challenge.（证书验证），避免与业务子域名冲突。
TXT 记录还常被用作控制权证明：能成功添加指定记录即证明对该域名有控制权。两个典型用途：
- 域名归属验证：服务商要求添加一条指定内容的 TXT 记录（搜索引擎站长工具、CDN 认领都是这个思路）
- ACME DNS-01 签证书（证书自动签发协议的 DNS 验证方式）：在
_acme-challenge.下添加验证记录，不依赖 80/443 端口可达，因此是内网服务和通配符证书的首选验证方式
邮件认证三件套
SPF、DKIM、DMARC 通过 TXT 记录协同工作，解决邮件伪造问题——收件方按这三条记录验证"这封邮件是否真的来自该域名"。
| 记录 | 回答的问题 | 验证方式 |
|---|---|---|
| SPF | 哪些服务器有权以我的域名发信 | 收件方比对发信 IP 是否在 SPF 声明的列表里 |
| DKIM | 这封邮件有没有被篡改 | 发信方用私钥对邮件签名，收件方用 DNS 里发布的公钥验签 |
| DMARC | 验证失败时怎么处理 | 声明处置策略（放行/隔离/拒收）和报告接收邮箱 |
SPF 语法 v=spf1 include:xxx ~all：include 引入服务商的授权列表；~all 表示列表外的发信方标记为软失败（可信度降低但不直接拒收），-all 是硬拒收。
DKIM 公钥以 TXT 记录发布在 选择器._domainkey.域名 下，选择器由发信服务商指定——同一域名可以同时挂多个服务商的 DKIM（各自一个选择器），互不冲突。
DMARC 的 p=none 表示只观察不处置（收件方仅发报告），生产环境确认无误后应逐步升级为 p=quarantine（可疑邮件投递到垃圾箱）或 p=reject（直接拒收）。
入站与出站邮件记录要合并管理
若主域 MX 指向收件服务（如邮件转发），而发信走第三方服务商子域，主域的 SPF 必须同时 include 双方——只写收件方时，从主域发出的邮件会 SPF 校验失败，只能靠 DKIM 域名对齐满足 DMARC。
仅 DNS 与已代理
Cloudflare 中每条记录有两种代理状态，决定流量是否经过 Cloudflare 中转：
| 模式 | DNS 解析返回 | 效果 |
|---|---|---|
| 仅 DNS（灰云） | 目标服务器真实地址 | 只做解析，无缓存、无防护，源站 IP 暴露 |
| 已代理（橙云） | Cloudflare 边缘节点 IP | 流量经 Cloudflare 中转，获得 CDN、HTTPS 卸载（边缘节点完成 TLS 解密，减轻源站计算）、DDoS 防护，源站 IP 隐藏 |
Cloudflare Tunnel 是已代理模式的进一步延伸：内网服务不暴露公网 IP、不开任何入站端口，由 cloudflared 守护进程主动建立出站隧道，Cloudflare 把流量沿隧道送回内网。记录类型显示为"隧道"，内容填隧道 ID。
站点级设置只对已代理记录生效：TLS 与 HSTS 等机制见 网络，缓存见 缓存，DDoS 与 Bot 防护见 流量安全。