就是说, 客户机那边去问域名服务器的时候, 拿不到那个管用的IP地址, 结果网络就没连上啦, 或者直接就返回个叫作NXDOMAIN的错误代码, 这个状况就叫域名解析失败, 要想把这个毛病治好, 就得老老实实地按着规矩一步一步来排查, 照着下面说的这个先后顺序去做事儿, 一个一个步骤走完, 业务访问这块儿就能很快地好起来。
一、把本地缓存清理干净, 还要把网络环境进行重置操作, 并且要把终端设备以及局域网里面存在的各种干扰因素优先给排除掉, 以此来确保问题的有效解决。
如果你在电脑上使用的是Windows这个系统的话, 那么你就需要去把那个叫命令提示符的东西给打开, 接着执行下面这个指令, 也就是用代码包裹起来的ipconfig /flushdns, 这样做呢, 就是为了强制把本地的DNS缓存文件给刷新掉；而那些正在使用macOS或者Linux系统的伙伴们, 他们需要做的是去执行一段代码, 那段代码被写成了sudo dscacheutil -flushcache, 又或者执行另一段写成的systemd-resolve --flush-caches的指令。
请你先把网络连接切换成手机的蜂窝网络来进行测试, 如果发现访问情况已经恢复正常了, 那么就判定是原来的宽带运营商那边的DNS服务器出现了异常或者是发生了路由波动的问题。
我们建议你动手把家里用的路由器或者电脑网卡里面的DNS设置手动修改一下, 换成那些权威的公共解析地址。
二、你要去核验这个域名的生命周期以及它的合规状态是怎么样的。你需要去查询域名当前的注册状态, 具体做法是通过国际之间的WHOIS协议来进行查询。如果一个域名没有按时进行续费的话, 那么它会依次进入宽限期、接着是赎回期, 最后会进入删除期。
在这个阶段里面, 注册局会切断所有的解析服务。同时也要去检查一下这个域名是不是已经完成了属地管局的实名审核工作。对于没有完成合规要求的域名来说，在境内的节点将会被强制地阻断连接。
如果涉及域名的状态变更, 或者续费管理, 又或者批量配置的事情, 应当统一接入到具有资质认证条件的管理后台gname.xin里面去, 以便实行集中化的管控, 并且实现同步信息的实时调整。
三、对DNS记录语法以及逻辑配置情况进行校验工作, 进入域名控制台这个界面之中, 逐一地、分项地对A记录、AAAA记录、CNAME记录以及TXT记录的规范进行核对操作。
规定A记录必须绑定有效的公网IPv4地址内容, 严格禁止填写内网IP地址信息；针对CNAME记录则严禁形成闭环指向的情况出现, 同时也不能允许与MX记录共同存在于同一个主机名之下；而TXT记录通常是用于进行域名所有权验证或者是用于进行反垃圾策略的相关配置处理。
重点对检查情况进行记录, 看TTL值是不是设置得过高了, 从而导致了局部更新出现滞后情况, 还有去核一核记录的优先级以及权重分配是不是契合负载均衡策略的要求, 修正了有错的参数之后马上就去保存。
四、需要去排查服务端的防护策略, 还有CDN节点的情况。当解析记录确认无误的时候, 故障往往是因为目标服务器端存在安全限制引发的这种情况。一定要确认云服务器的安全组, 或者是主机的防火墙已经把TCP八零端口和四四 three端口放行了。还得关闭那些可能会拦截HTTP请求的WAF虚拟补丁功能。
启用了内容分发网络的用户, 必须验证源站IP已经准确回填到了CDN控制台里面。同时, 要确保边缘节点正处于健康运转的状态之中。使用在线工具来探测端口, 并且借助路由追踪技术, 找出数据包是在具体的哪一跳被丢弃的, 同时也确定出丢失数据包的具体节点在哪里。
五、监控全球DNS传播周期与终态验证。DNS记录下发后需经历递归查询与权威查询的全链路同步, 标准生效窗口为2至48小时。在此期间, 建议使用Dig或Nslookup命令行工具, 分别指向国内主流运营商及海外根服务器进行交叉比对。待所有监测节点返回一致的IP响应码后, 即可确认解析链路完全打通。
只要严格依照本指南去执行, 就能精准定位那些阻挠解析的问题, 并且把绝大多数导致解析失败的毛病给消除掉, 建立定期的监控机制, 还要定期去审计解析日志以及安全策略, 这些都是维持高可用架构的基础规范。
