GNS解析失败根本原因是集群命名服务链断裂，需依次验证GNS运行状态、DHCP响应、DNS转发链路及OCR配置一致性。
gns 解析失败在 oracle 19c rac 中不是 dns 配置错那么简单，而是整个集群命名服务链断裂——gns（grid naming service）本身不提供 dns 解析，它依赖后端 dhcp + dns 转发协同工作。一旦客户端连不上 gns 或解析返回空，srvctl、crsctl 命令可能静默失败，scan vip 无法漂移，甚至节点加入集群超时。
确认 GNS 是否真在运行且监听正确地址
GNS 是 Grid Infrastructure 的可选组件，但启用后必须绑定到专用网卡（不能是 localhost 或 public 网卡），否则所有转发请求都会被拒绝或丢弃。
- 运行 crsctl stat res -t | grep gns，状态应为 ONLINE；若为 OFFLINE 或 INTERMEDIATE，先别动配置，先查日志
- 查看 $GRID_HOME/log/<hostname>/gnsd/gnsd.log，重点搜 "Failed to bind" 或 "No suitable interface"
- 执行 netstat -tlnp | grep :1535（GNS 默认端口），输出中必须含实际私网 IP（如 10.10.10.115:1535），而非 127.0.0.1:1535 或 *:1535检查 DHCP 服务是否响应 GNS 请求
GNS 不自己分配 IP，它把地址请求转发给后端 DHCP 服务器。如果 DHCP 未启用、ACL 拦截或作用域耗尽，GNS 就会返回 NXDOMAIN 或超时。
- 登录 DHCP 服务器，确认已启用并监听 UDP 67 端口，且允许来自 GNS 所在子网（通常是私网段，如 10.10.10.0/24）的请求
- 在任一 RAC 节点执行：echo -n -e "\x01\x01\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" | nc -u -w1 dhcp-server-ip 67（简单探测，不依赖完整 DHCP 流程）
- 若无响应，检查防火墙：iptables -L -n | grep 67 或 firewall-cmd --list-ports | grep 67，确保 UDP 67 对 GNS 主机开放
验证 DNS 转发链路是否打通
GNS 收到客户端 DNS 查询（如 rac-scan）后，会将非集群域名（如 www.example.com）转发给上游 DNS；集群内域名（如 rac1-vip）则由自身缓存或查询 OCR 返回。
- 编辑 $GRID_HOME/network/admin/gns.ora，确认 FORWARDERS 指向可用 DNS（如 192.168.31.1），且该 DNS 能被 GNS 进程所属用户（grid）访问
- 手动测试转发：在 GNS 所在节点用 nslookup rac-scan $(cat $GRID_HOME/network/admin/gns.ora | grep FORWARDERS | awk '{print $3}')，看能否返回 SCAN VIP
- 若转发 DNS 不可信，可临时改用公网 DNS（如 8.8.8.8）做最小验证，排除本地 DNS 故障干扰
OCR 中 GNS 配置与实际部署不一致
GNS 启动参数（IP、端口、DHCP 地址）全部来自 OCR，不是靠 gns.ora 文件实时加载。修改配置后必须用 srvctl 刷新 OCR 记录，否则重启也无效。
- 查当前 OCR 记录：srvctl config gns，输出应含 GNS VIP 和 DHCP Server 地址
- 若不匹配，先停服务：srvctl stop gns -f
- 重新配置（示例）：srvctl modify gns -i 10.10.10.115 -p 1535 -d dhcp-server-ip
- 再启动：srvctl start gns，然后立刻 crsctl stat res -t | grep gns 确认状态
GNS 解析失败最常被忽略的点是：它不报错，只沉默丢包。你看到 tnsping rac-scan 超时，nslookup rac-scan 返回 server failed，或者 srvctl status scan 显示 UNKNOWN —— 这些都不是网络不通的信号，而是 GNS 根本没收到请求，或收到后因 DHCP/DNS 链路断开而放弃响应。
