Oracle 12c RAC中GNS域名解析失败主因是本地resolver链路配置错误：nsswitch.conf hosts行缺失dns或含误判条件、resolv.conf search域冗余导致拼接超时、GNS VIP未在/etc/hosts静态解析或端口冲突，而非DNS服务器故障。
oracle 12c rac 中 gns 配置错误引发的域名解析问题，八成不是 dns 本身挂了，而是系统 resolver 链路卡在 nsswitch.conf 或 resolv.conf 的某个环节，或者 gns vip 自身没被正确识别——gnsctl start 成功不代表 gns 真正在服务。
检查 /etc/nsswitch.conf 的 hosts 行是否合规
GNS 要求 SCAN 名称必须走 DNS 解析，不能靠 /etc/hosts 回退。如果 hosts 行写成 files 就停，那系统查完 /etc/hosts 没命中就直接返回失败，根本不会发 DNS 请求。
-
hosts: files dns是最低可用配置；删掉所有带[NOTFOUND=return]或mdns4_minimal的条件跳转项，RAC 场景下它们容易误判 - 所有 RAC 节点的该行必须完全一致——曾有案例因节点间仅差一个空格，导致部分节点能连 SCAN、部分连不上
- 改完后执行
nscd -i hosts（如果启用了nscd），否则缓存会掩盖修复效果
验证 resolv.conf 中 search 域是否精简且顺序合理
search 域太长或顺序错，会导致客户端对 rac-scan.example.com 反复拼接尝试：rac-scan.example.com.corp.example.com → rac-scan.example.com.example.com → rac-scan.example.com，前两次必 NXDOMAIN，每次超时叠加，整体就“超时”。
- 确保
search行只保留实际需要的域名，且 SCAN 所在域名排最前，例如：search example.com - 绝对避免通配写法（如
search local），GNS 不支持本地域名解析 - 若用 DHCP 分配
resolv.conf，确认 DHCP server 返回的search是否精简；临时可手工覆盖：echo "search example.com" > /etc/resolv.conf
确认 GNS VIP 是否可被系统 resolver 正确识别
gnsctl start 报 “GNS is not running” 往往不是服务没启，而是 grid 用户下缺少 /etc/hosts 中 GNS VIP 的静态条目，或该 IP 被其他进程（比如旧 CRS 实例）占用了端口。
- 在
/etc/hosts中加一条静态解析（哪怕只用于初始启动）：192.168.56.100 gns-vip.example.com gns-vip - 用
netstat -tuln | grep :1521检查端口冲突——GNS 默认监听 1521，和数据库冲突时会静默失败 - 启动后立刻跑
gnsctl status；如果显示UNKNOWN，大概率是 OCR 中 GNS 资源注册异常，需用crsctl stat res -t | grep gns核对状态
用 getent 验证是否走通完整 resolver 链路
dig 快但 nslookup 慢，说明 DNS server 没问题，问题出在本地 resolver 配置上。getent hosts rac-scan.example.com 才等效于 Oracle 客户端行为，它会完整走 nsswitch.conf + resolv.conf 链路。
- 如果
getent慢或失败，但dig rac-scan.example.com瞬间返回，基本锁定是nsswitch.conf或resolv.conf配置问题 - 别用
nslookup验证——它默认走系统 resolver 库，受上述两文件共同影响；而dig是直连 DNS server，绕过了系统配置 - SCAN VIP 和 GNS VIP 必须独立：复用同一 IP 会导致
srvctl add scan拒绝注册，或客户端被重定向到 GNS 监听器而非 SCAN 监听器
最常被忽略的是：GNS VIP 不能从 DHCP 获取自身地址，必须静态配置；而 SCAN VIP 才由 GNS 动态分配。这两者在 IP 规划阶段就混在一起，后续排查会陷入死循环。
