一次DNS域名解析问题排查记录
这篇讲的是一个线上服务因DNS解析异常导致调用失败的排查过程。作者从同事反馈curl调用另一个服务接口报错“couldn’t connect to host”入手，通过strace追踪发现，连接实际指向了一台实体机的IP地址，而非预期的VIP。 问题的根源在于新安装的阿里自研DNS解析软件vipserver，它错误地将域名解析到了多台实体机IP。与对方工程师沟通后进一步发现，实体机服务端口是2087，而VIP上监听的是2088，端口不匹配直接导致了连接失败。排查中还发现了一个“隐形干扰者”——nscd的DNS缓存。清空缓存后，之前“正常”的机器也暴露出问题，这解释了为何集群内部分机器表现不一。 最终的处理是暂时关闭vipserver，等待对方完成配置修正。这个案例清晰地展示了，当引入新的服务发现组件时，对解析链路、缓存机制以及上下游端口配置进行同步验证是多么必要。