A 记录将名称映射到 IPv4 地址
DNS A 记录将主机名与 32 位 IPv4 地址关联。它帮助客户端为命名服务找到地址。它不会指定 URL 路径、选择 HTTP 重定向、安装证书，也不会配置目标地址上的应用程序。
在修改任何内容之前，先确定用户实际请求的确切主机名。example.com 和 www.example.com 是两个不同的 DNS 名称。一个名称的正确记录不能证明另一个名称已经配置完成。请查询失败 URL 中实际出现的名称。
将记录作为完整行读取
| 字段 | 示例值 | 含义 |
|---|---|---|
| 名称 | app.example.com. | 正在映射的主机名 |
| 类型 | A | IPv4 地址记录 |
| TTL | 300 | 以秒表示的缓存生命周期 |
| 值 | 192.0.2.10 | 仅用于文档说明的 IPv4 示例，不是部署目标 |
这是一条虚构的教学示例。末尾的点表示完全限定的 DNS 名称。服务商的界面可能会自动添加区域名称；在相对标签字段中输入完整名称可能创建错误记录。请查看服务商的预览或最终的公共查询结果。
同一名称可能存在多个 A 记录。请比较完整的应答集合，不要假设第一个显示的地址是唯一目的地。记录顺序不是可靠的优先级机制。
在修改之前确定当前应答
nslookup -type=A example.com
在生产检查中使用你控制的实际主机名，并将其现有值和 TTL 记录到变更记录中。在 Arcvenza NSLookup 中，权威模式有助于展示通过委派获得的当前已发布应答。递归模式表示解析器看到的结果，其中可能仍包含缓存的应答。
请与托管方或应用程序负责人确认目的地。复制自无关诊断服务的地址可能指向代理、出站网关或共享服务，而不是应该接收访问者请求的主机。
规划可回退的变更
在修改之前，先确认新目的地、预期切换时间、验证方法和回滚值。确保目的地已为该主机名准备好，并配置了相应的 HTTPS 证书。在变更时降低 TTL 并不会立即移除此前按照旧 TTL 缓存的应答。
在运营条件允许的情况下，提前调整 TTL，并等待原缓存生命周期结束。让 DNS 负责人和应用负责人共同参与。DNS 更新可以成功将流量导向应用程序，但该应用仍可能提供错误的网站。
发布后比较应答
| 检查项 | 期望证据 | 如果不一致 |
|---|---|---|
| 权威查询 | 确切名称的预期应答集合 | 检查区域、记录和委派 |
| 允许的递归查询 | 应用缓存后预期的应答 | 记录解析器和剩余 TTL |
| 向主机名发送 HTTPS 请求 | 正确的证书和预期页面 | 调查 TLS 或应用路由 |
| 应用任务 | 所需页面或端点实际可用 | 检查应用日志和内容 |
一个示例迁移将 app.example.com 从 192.0.2.10 移到 192.0.2.20。两者都是文档保留地址，不能作为可用的生产目标。如果权威应答已经更新而递归应答仍然旧，这一现象指向缓存状态。如果两者都已更新但网站仍然错误，说明 DNS 已建立，但应用程序正确性仍未得到保证。
避免混淆相邻的记录类型
AAAA 记录回答同一问题中的 IPv6 部分。CNAME 记录标识另一个 DNS 名称，而不是存储 IPv4 地址。使用 AAAA 指南检查 IPv6 目的地；涉及别名时，使用 CNAME 查询指南。
不要将完整的 https:// URL、端口或页面路径填入 A 记录值。如果服务要求提供主机名别名，请按照其记录的 CNAME 或服务商特定设置操作，不要强行把该名称填入地址字段。
常见问题与下一步
更改 A 记录会将访问者重定向到不同的页面路径吗？不会。请单独配置相关的 HTTP 重定向。
为什么某个位置仍然看到旧地址？请保留确切的解析器、时间和 TTL；缓存以及网络相关的应答可能不同。在 NSLookup 中执行权威对比，然后从受影响的环境验证真实网站。