ubuntu域名有哪些陷阱

Ubuntu 域名解析的常见陷阱与规避

一 配置入口与持久化陷阱

• 在现代 Ubuntu（如18.04+）上，很多场景使用 systemd-resolved，其本地存根监听 127.0.0.53；直接编辑 /etc/resolv.conf 往往会在重启或网络变更后被覆盖，甚至该文件本身是一个指向 /run/systemd/resolve/stub-resolv.conf 的符号链接，手动改它通常无效。正确做法是修改 /etc/systemd/resolved.conf 或通过 Netplan/NetworkManager 进行持久化配置。另一个常见问题是 Netplan 配置未设置 search 域，导致短名称（如 service 主机名）在企业内网无法解析。建议在企业环境中同时配置 search 并使用 resolvectl status 核对实际生效的 DNS 与搜索域。

二 解析路径与优先级陷阱

• 多网卡或多网络环境下，DNS 服务器可能来自不同接口，若未正确设置优先级，系统可能优先使用公共 DNS，导致内网域名解析失败。应避免把仅有公网解析能力的 DNS 放在前面，必要时在 /etc/systemd/resolved.conf 中使用 Domains=~company.com 将私有域“粘”在内网 DNS 上，确保私有域名只走内网解析器。验证时可用 resolvectl status 查看 Current DNS Server，并用 dig +trace prefix.company.com 确认首跳是否为内网 DNS，这是判断配置是否生效的“黄金标准”。

三 缓存与存根解析器陷阱

• 使用 systemd-resolved 时，查询结果会被本地缓存；遇到变更或异常，需执行 sudo systemd-resolve --flush-caches（或在新版本中使用 resolvectl flush-caches）清理缓存，并重启服务以重建状态。若看到 /etc/resolv.conf -> stub-resolv.conf 且所有查询都发往 127.0.0.53，说明仍在使用存根解析器，此时应去检查 resolved.conf 或上游配置，而不是继续改 /etc/resolv.conf。

四 名称解析栈与本地映射陷阱

• 即使 DNS 配置正确，仍可能因 /etc/nsswitch.conf 中 hosts 行缺少 dns 导致域名不走 DNS；或 libnss_dns.so.2 缺失/路径错误引发解析失败。排查时检查 cat /etc/nsswitch.conf | grep hosts 是否包含 dns，并确认 libnss_dns.so.2 存在且可被加载。此外，/etc/hosts 的静态映射若写错或过期，也会造成“看似 DNS 问题”的表象，需一并核对。

五 网络连通性与安全策略陷阱

• 常见现象是 ping IP 通但域名不通，这基本可判定为 DNS 问题；也可能是 DNS 端口（UDP/TCP 53） 被本地防火墙或云安全组拦截，导致查询超时。排查顺序建议：先用 ping 8.8.8.8 验证连通性，再检查 /etc/resolv.conf 与 resolvectl status，随后用 nslookup/dig 验证解析，最后核对 ufw/安全组 是否放行 53 端口的出站流量。容器与虚拟机环境中，还需注意虚拟网卡、NAT 与 DNS 转发配置是否一致。