先写出用户准备访问的完整名称
给网站配置解析前，先列出真正需要访问的名称，例如 example.com、www.example.com 和 blog.example.com。它们虽然共享一个父域名，却是不同的 DNS 名称。博客子域名可以访问，并不能证明主域名也配置了相同记录。排查时不要只说域名打不开，应记录浏览器中的完整地址、协议和是否带端口。这样可以区分缺少主域名记录、子域名配置错误和网站入口未匹配三种情况。文中的名称与地址用于演示字段含义，不代表需要修改的真实资源。
还应明确域名由谁注册、当前由谁提供权威解析，以及网站实际部署在哪里。这三项可以属于不同服务商。购买域名的平台不一定是正在生效的解析平台，服务器所在云也不决定 DNS 必须使用它的控制台。先检查域名当前委派的名称服务器，再在对应平台管理记录。如果在没有被委派使用的控制台里添加记录，即使保存成功，互联网查询也不会读取这些记录。把资源归属写清楚，可以减少在多个云平台之间来回修改却没有结果的情况。
@ 在控制台中代表主域名本身
在阿里云的解析表单里，主机记录填写 @ 表示当前管理的主域名本身。若管理的是 example.com，这条记录对应 example.com；填写 www 则对应 www.example.com，填写 blog 则对应 blog.example.com。@ 是控制台采用的表示方式，不是需要放进浏览器网址中的字符。其他平台可能用空白或其他形式表达根名称，应以各自字段说明为准。不要把完整网址连同协议和斜杠一起粘到主机记录框中，它要求的是名称标签。
主域名与 www 可以选择同一网站入口，也可以承担不同用途。配置时应先决定访问策略，再创建对应记录。例如主域名作为静态首页，博客放在 blog 子域名；www 则可以跳转到主域名。DNS 记录负责名称到地址或别名的关系，浏览器跳转由网站服务返回重定向完成。不能只添加一条 www 的 A 记录，就期待用户访问主域名自动得到相同页面；也不能以为 CNAME 本身会改变地址栏中的网址。
A 记录保存 IPv4 地址而不是网址
A 记录的值是 IPv4 地址。应填写实际承载网站入口的公网地址，而不是服务器内网地址、博客页面网址或应用监听端口。对于普通反向代理部署，访问者先连接服务器的标准网站端口，再由代理转发到内部应用。DNS 不会把 A 记录中的地址转换成某个应用端口。如果网站只有内部端口服务，需要在服务器上配置合适的入口；在记录值里附加冒号和端口，不能得到正确的 A 记录。
确认公网地址时，要考虑是否使用负载均衡、内容分发或其他代理。实际入口可能并不是应用服务器自己的地址，而是平台提供的专用名称或地址，此时应按照平台要求选择记录类型。文中使用的文档示例地址不具备真实部署含义，执行时应替换为已经核对的入口。不要根据服务器采购平台推断地址，也不要把旧服务器的地址继续用于新的部署。解析切换之前，最好先验证新入口能正确处理目标域名。
www 可以使用地址记录或别名
若 www 与主域名共用入口，可以分别创建 A 记录，也可以在适用条件下把 www 设置为指向另一个名称的 CNAME。两种方式的维护成本不同：独立 A 记录需要在入口地址改变时同步更新，别名则需要追踪目标名称的解析结果。标准 DNS 对 CNAME 与其他记录的共存有约束，不能在同一名称下随意混用。配置前查看平台的冲突提示，并保留原记录含义，避免为了让一项保存成功就删除仍然需要的记录。
主域名通常还有区域本身必须具有的记录，因此不能把对子域名的普通 CNAME 做法直接套到根名称。某些解析平台提供别名或展开机制，那属于平台能力，需要按它的说明使用。对于只需要绑定一台 IPv4 网站服务器的基础场景，主域名使用明确的 A 记录比较容易检查。不要为了模仿另一个网站的配置引入不必要的链条，也不要把泛解析作为主域名记录的替代。明确列出需要的名称，通常更便于后续验收。
同时核对 IPv6 与缓存条件
如果名称存在 AAAA 记录，支持 IPv6 的访问者可能沿另一条路径访问网站。A 记录已经更新，而 AAAA 仍指向旧服务器，会产生不同网络下结果不一致的现象。应核对两种地址族的入口、监听和证书是否完整。不能一概删除 IPv6 记录，也不能仅根据自己的 IPv4 请求成功就认为所有用户都已恢复。只有实际部署支持该地址族并通过验收时，相关记录才与网站能力一致。
TTL 表示解析记录可以被缓存的时间条件，修改以后并不是所有客户端立即重新查询。之前已经缓存的旧记录可能继续有效一段时间；修改前降低 TTL，也需要让旧缓存先经历其原有窗口。验证时保存查询来源、返回值和剩余时间，不要把控制台已经显示新值当作全球查询同时完成。浏览器还可能采用独立的解析方式，系统查询和浏览器访问结果需要分别检查。发现差异时，应沿缓存来源定位，而不是不断重复保存同一条记录。
让服务器识别每一个入口名称
DNS 返回正确地址以后，服务器还需要根据请求的目标名称选择网站。反向代理配置如果只包含 blog.example.com，访问 example.com 可能落到其他站点或无法获得对应证书。应在代理中明确配置主域名、博客子域名和需要跳转的 www。每个入口都要核对 HTTP 与 HTTPS 的实际行为，证书覆盖的名称应与访问名称一致。把解析与站点配置作为两个检查点，可以解释为什么同一地址上的某个名称工作而另一个失败。
验证新入口可以使用保留目标主机名的请求方式，例如 curl 的 resolve 参数，将一个名称临时指向指定地址。它可以帮助在正式切换前检查服务器的路由和证书，但不能证明权威 DNS 已经更新。直接访问公网 IP 又可能绕过基于域名的选择，也不能替代域名验收。记录测试时应说明是否覆盖了解析，避免把人为指定地址的成功写成普通访问已经成功。对需要身份验证的后台，也应检查公开入口没有意外暴露内部服务。
用查询结果核对记录已经生效
可以分别查询主域名、www 和博客子域名的 A、AAAA 与 CNAME，记录完整回答。首先确认当前权威服务器确实给出预期记录，再比较常用递归解析的回答。如果权威查询仍然错误，应回到委派和控制台配置；如果权威正确而递归仍旧，可以检查缓存时间。验证步骤不应只保留一次 nslookup 的截图，因为它可能显示的是某个局部缓存结果。完整名称、记录类型和查询服务器，是解释结果所需的基本信息。
随后从普通网络访问网站，检查正文、跳转目标和证书。www 的跳转应保持合理的路径规则，主域名静态页中的博客链接应指向正确的完整地址。若站点存在登录、上传或订阅入口，还要确认链接没有误用内网名称和开发端口。DNS 查询只完成了名称这一层，页面可读性和应用行为仍需要实际请求验证。没有进行的检查应保留为待验证，不能仅因为记录保存成功就报告网站已经完成绑定。
变更记录与回退应保持清楚
修改前保存现有记录的名称、类型、值和 TTL，并注明本次变更目标。地址切换可能与证书申请、代理配置和应用上线相互依赖，最好按可验证的顺序进行。回退时也应核对缓存窗口，不能承诺撤销记录以后所有访问立即回到旧服务器。对于多个名称，逐个列出验收状态，可以避免只检查博客子域名就遗漏主域名。配置清单不需要包含账号口令，记录事实和操作时间已经能够提供必要的排查线索。
本文讨论普通公网网站的基础解析，不涵盖企业内网的分区解析和特殊平台的别名实现。服务器接入条件及网站信息展示，需要根据真实部署环境另外核对，不能从一条 A 记录推断已经满足全部要求。最容易记住的关系是：@ 表达主域名，www 与 blog 表达不同子域名，A 保存 IPv4 地址，网站服务负责端口和跳转。把这些职责对应好以后，绑定工作就能逐层验证，而不再依赖一个含糊的域名设置判断。
调整网站记录时，还要保留原有邮件和验证记录的用途说明。主域名下面可能同时存在邮箱路由与平台验证信息，它们并不会因为本次只绑定网站就失去价值。遇到记录冲突，应先确认冲突类型和已有服务，再按平台规则处理，不能把所有旧记录清空以后重新添加网站入口。变更清单只列出本次需要调整的名称与类型，更容易在验收时确认既有邮件和其他子域名仍沿原有路径工作。
实现片段
# 示例记录清单：地址必须换成已核对的真实公网入口
主机记录 类型 记录值
@ A 203.0.113.10
blog A 203.0.113.10
www CNAME example.com
# 独立核对三种名称，不能只检查博客子域名
dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig blog.example.com A
评论 · 0