引言

域名能打开，网站却访问不了；明明改了解析记录，用户看到的还是旧内容；ping域名通了，浏览器却提示"无法解析"——DNS解析失败，堪称云上运维最令人抓狂的"隐形杀手"。据行业统计，超过六成的网站访问故障并非源于服务器宕机或网络中断，而是卡在了DNS解析这道关卡上。天翼云云解析作为承载全网域名解析的核心服务，其稳定性直接决定了业务的在线率。然而，TTL设置不当、记录类型选错、区域同步延迟这三座大山，足以让再资深的运维工程师陷入泥潭。本文将从TTL策略、记录类型配置、区域同步机制三大维度出发，给出一套可直接执行的系统化排查方案，让你的DNS解析故障不再"查无头绪"。

一、TTL设置：生效速度与缓存一致的平衡艺术

1.1 TTL到底在控制什么？

TTL（Time To Live，生存时间）是DNS解析记录在各级DNS服务器上的缓存时长。当你修改了一条A记录，全球各地的递归DNS服务器并不会立刻同步最新结果——它们会继续使用缓存中的旧记录，直到TTL到期后才重新向权威服务器发起查询。这意味着，TTL值直接决定了你的解析变更"多久才能让全世界看到"。

天翼云云解析提供四档TTL规格：5分钟（300秒）、1小时（3600秒）、12小时（43200秒）、1天（86400秒）。

1.2 TTL选错的两种典型灾难

灾难一：TTL设置过长，变更如同石沉大海。 某电商平台在大促前紧急切换了CDN节点IP，但由于解析记录TTL设置为1天，旧IP在全球递归服务器中缓存了整整24小时。结果大促首日，仍有大量用户被导向已下线的旧节点，页面直接404。

灾难二：TTL设置过短，解析服务被打垮。 天翼云内网DNS对单IP的解析流量设有QPS上限——每秒最多2000次，超出部分将被直接清洗。如果你将TTL设为5分钟且业务QPS极高，大量客户端会在缓存过期后同时发起解析请求，瞬间突破QPS阈值，导致解析请求被丢弃，表现为"间歇性无法解析"。

1.3 TTL的最佳实践

关键原则：服务地址经常更换，TTL设小些；地址稳定不动，TTL设大些。 修改解析记录后若需尽快生效，第一件事就是把TTL临时调小，生效后再改回正常值。

二、记录类型：选错类型，解析必然翻车

2.1 六大记录类型，各有各的坑

天翼云云解析支持A、AAAA、CNAME、MX、TXT、SRV六种记录类型，内网DNS还额外支持PTR反向解析。每种类型都有明确的适用场景，选错了不是"不生效"，而是"生效了但结果不对"。

A记录：将域名指向IPv4地址，最常用也最容易出错。当记录值中填写多个IP时，天翼云会随机返回所有IP，浏览器默认取第一个。这意味着如果你配置了负载均衡，但A记录中IP顺序不对，流量可能全打到同一台后端，导致严重的负载不均。

CNAME记录：别名解析，将一个域名指向另一个域名。最常见的错误是在根域名（如example.com）上配置CNAME——这违反DNS规范，会导致整个域名解析失败。CNAME只能用于子域名（如www.example.com）。

AAAA记录：IPv6解析。天翼云支持A和AAAA同时配置，实现IPv4/IPv6双栈解析。但如果只配了AAAA没配A，大量不支持IPv6的客户端将完全无法访问。

MX记录：邮件交换记录。当存在多条MX记录时，邮件发送方会优先选择优先级数字最小的服务器。如果你配置了多条MX但忘记设置优先级，邮件可能被随机投递，甚至丢失。

TXT记录：常用于域名验证和SPF反垃圾邮件配置。在申请SSL证书选择DNS验证时，需要将平台提供的验证值以TXT记录形式填写到云解析中。记录类型、主机记录、记录值三项必须完全匹配，错一个字符都会导致验证失败。

PTR记录：反向解析，将IP映射回域名。天翼云内网DNS支持配置PTR记录，格式为x.x.x.x.in-addr.arpa。如果不配置PTR，内网DNS在收到反向解析请求时会向公网递归服务器发起查询，由于内网地址在公网无对应记录，会导致ping域名时出现明显延迟甚至卡顿。

2.2 智能解析线路：不设默认线路，等于自断一臂

天翼云云解析支持按运营商、地域等维度配置智能解析线路。但有一个致命细节被大量用户忽略：必须设置默认线路。如果访客的IP不属于你已配置的任何一条线路，且没有默认线路，云解析系统不会为其分配任何IP，该用户就会看到"域名不可达"。

排查方法：进入云解析控制台，检查你的域名是否配置了"默认"线路。如果没有，立刻补上，否则永远会有一部分用户无法解析。

三、区域同步：为什么改了记录，一半人能看到一半人看不到？

3.1 云解析的生效机制：配置实时，客户端不实时

天翼云云解析的服务端配置是实时生效的——你在控制台添加或修改一条记录，权威DNS服务器立即更新。但客户端什么时候能看到新结果，取决于本地DNS缓存中旧记录的TTL何时到期。

这意味着，即使你刚改完解析，用户电脑里可能还存着5分钟前、1小时前甚至1天前的旧缓存。在这段时间内，用户访问的依然是旧IP。

内网DNS的情况更特殊：内网DNS服务器配置实时生效，但客户端解析生效时间取决于本地DNS缓存的TTL到期时间，一般默认为10分钟。如果你的VPC子网DNS服务器地址没有正确指向内网DNS地址（100开头的大网地址），客户端根本不会查询内网DNS，自然也就无法获取内网域名的解析结果。

3.2 内外网DNS冲突：同一个域名，两套解析结果

如果你的公网DNS和内网DNS存在相同的域名但对应了不同的IP，客户端会以哪个为准？答案是：看客户端在哪里、用的哪个DNS服务器。

• 客户端在VPC内，且主机DNS设置为内网DNS地址 → 以内网DNS解析结果为准
• 客户端使用公共DNS服务器 → 以公网DNS记录解析结果为准

这就是为什么你在VPC内能访问内网服务，但用手机开流量就访问不了——手机用的是运营商公共DNS，查到的是公网解析结果，而公网根本不知道你的内网域名。

3.3 区域同步延迟的排查步骤

当你怀疑解析记录没有同步到所有区域时，按以下步骤验证：

第一步：用nslookup指定权威DNS查询。 在DOS窗口执行nslookup -qt=A 目标域名 权威DNS地址，直接问天翼云权威服务器，而非经过本地缓存。如果返回的IP是你刚配置的，说明权威端已生效，问题出在客户端缓存。

第二步：用dig命令查看完整解析路径。 执行dig +trace 目标域名，可以看到从根域名服务器到权威服务器的完整查询链路，帮你定位解析在哪一跳断了。

第三步：检查VPC子网DNS配置。 登录天翼云控制台，进入VPC服务页面，检查子网的DNS服务器地址是否已修改为内网DNS地址（100开头）。这是内网域名解析不生效的头号原因——配置了内网域名，但子网DNS还指向公网，等于白配置。

四、五步快速排查清单：从现象到根因

当DNS解析失败时，不要漫无目的地乱改，按这五步走：

五、高级技巧：让解析又快又稳

技巧一：泛域名解析统一管理。 天翼云内网DNS支持通配符*作为主机名创建泛解析记录。与其为每个子域名单独配置A记录，不如一条泛解析搞定所有子域名，后续新增服务时无需再改DNS配置。

技巧二：IPv4+IPv6双栈并行。 为同一主机名同时添加A记录和AAAA记录，天翼云会根据客户端网络环境自动选择。测试方法：nslookup 目标域名，如果同时返回IPv4和IPv6地址，说明双栈配置成功。

技巧三：PTR反向解析必须配。 尤其是内网环境，不配PTR会导致ping域名时出现明显延迟。在内网DNS中创建in-addr.arpa域名，添加对应的PTR记录集，将延迟从秒级降至毫秒级。

写在最后

DNS解析失败从来不是"玄学"——它有规律、有工具、有方法。TTL决定了变更多久生效，记录类型决定了解析结果对不对，区域同步决定了所有人能不能同时看到新结果。这三者构成了DNS解析的铁三角，缺一个都会翻车。

从今天起，打开你的天翼云云解析控制台，逐项检查：TTL是不是该小的地方设大了？记录类型是不是根域名上误配了CNAME？智能线路是不是忘了设默认线路？VPC子网DNS是不是还指着公网？这四个问题的答案，决定了你的DNS是"秒级生效、全球一致"，还是"改了半天、一半人还在访问旧地址"。

解析不是配完就完的一次性操作，而是一套需要持续调优的动态系统。真正的稳定，从来不靠运气，靠的是每一个TTL值、每一条记录类型、每一次区域同步都经得起推敲。