linux系统dns解析失效极少由/etc/resolv.conf权限错误直接导致，因glibc仅需文件可读；但若权限为600且非root进程调用、或systemd-resolved socket权限异常（如srw-------）、或selinux/apparmor策略拦截，则可能引发静默失败。
Linux 系统中 DNS 解析失效极少由 /etc/resolv.conf 文件“权限错误”直接导致，因为 glibc 的 NSS 模块（如 libnss_dns.so）读取该文件时只依赖可读性，不校验属主或执行权限。但若权限设置严重异常（如完全不可读、被误设为 root-only 且非 root 进程调用），或与 systemd-resolved、NetworkManager 等服务的运行上下文冲突，则可能引发静默解析失败。
确认 resolv.conf 是否真正可被解析器读取
普通用户进程（如 curl、ping）和系统服务均需能打开并读取 /etc/resolv.conf。即使文件存在，权限不当也可能阻断访问：
- 运行
ls -l /etc/resolv.conf，检查权限是否为-rw-r--r--（644）或至少保证other或group有读权限；若显示-rw-------（600）且属主不是当前用户，非 root 进程将无法读取 - 用普通用户身份测试：
cat /etc/resolv.conf 2>/dev/null || echo "读取失败"—— 若失败，说明权限或 SELinux 上下文已拦截 - 对关键工具验证：
getent ahosts google.com成功与否，可反映整个 NSS 链路是否畅通（它会触发实际读取 resolv.conf）
排查 systemd-resolved 的权限与 socket 访问问题
在启用 systemd-resolved 的系统中，/etc/resolv.conf 往往是符号链接（如指向 /run/systemd/resolve/stub-resolv.conf）。此时真正起作用的是 resolved 的 D-Bus 接口和本地 socket：
- 检查链接目标：
readlink -f /etc/resolv.conf；若指向/run/systemd/resolve/stub-resolv.conf，则需确保该文件权限为644，且所属组为systemd-resolve - 验证 resolved socket 可达：
ls -l /run/systemd/resolve/io.systemd.Resolve应显示 socket 权限为srw-rw-rw-（0666），否则普通用户无法连接 - 若 socket 权限异常（如
srw-------），重启服务通常可恢复：sudo systemctl restart systemd-resolved
检查 SELinux 或 AppArmor 是否阻止读取
在强制访问控制开启的系统（如 RHEL/CentOS/Fedora 或 Ubuntu 启用 AppArmor）中，即使文件权限正常，策略也可能禁止解析器访问：
- RHEL/CentOS：运行
ausearch -m avc -ts recent | grep resolv.conf，查看是否有 AVC 拒绝日志 - 临时测试是否为 SELinux 所致：
sudo setenforce 0后重试解析；若恢复，需调整策略（如sudo restorecon -v /etc/resolv.conf） - Ubuntu：检查
sudo aa-status是否限制了 systemd-resolved 或 dbus-daemon，常见于自定义 profile
验证解析行为是否受权限间接影响
某些场景下，“权限错误”表现为更隐蔽的上下文失效，而非文件本身：
- 容器环境：若容器挂载了
/etc/resolv.conf但宿主机该文件属主为 root:root 且 mode 600，部分容器运行时（如旧版 Docker）可能拒绝继承，导致内部无 DNS 配置 - chroot 或 unshare 环境：进入受限命名空间后，若未正确复制或 bind-mount resolv.conf，或目标路径不可写/不可读，解析即中断
- NetworkManager 覆盖逻辑：NM 默认以 root 身份写入 resolv.conf，若手动改权限为
644但 NM 进程因权限不足无法更新，会导致配置陈旧甚至空白
