网络

主机名查询首先由具体程序发起。在 Linux 上，使用 glibc 名称服务接口的应用，可以依照 /etc/nsswitch.conf 中 hosts 项列出的服务查询；使用自有 DNS 客户端的程序则可能走另一条路径。并不存在所有应用都遵守的“先缓存、再 hosts、最后互联网”固定顺序。定位问题的起点是实际调用方，而不是凭操作系统名称假定完整流程。 坏掉的样子 当 files 位于 dns 前面时，hosts 文件条目可以覆盖正确的 DNS 回答。修改权威区域不会删除这个本地覆盖。直接 DNS 查询可能已经看到新地址，应用却仍使用本地文件中的旧值；这两项观察可以同时正确，因为它们实际回答的是不同来源的查询。仅凭 dig 正常就认定应用一定使用同一个地址，会漏掉最直接的配置原因。 NSS 的结果动作与服务顺序同样重要。在 files 后写 [NOTFOUND=return]，表示文件服务没有找到条目时就停止。即使 DNS 中存在有效记录，也不会继续询问。把这类失败归咎于上游不可用，可能让人反复修改区域或者重启解析服务，却始终没有修正真正阻断查询的策略。应完整读取方括号规则，不能只摘出 files 和 dns 两个单词。 地址族筛选还会制造另一种差异。使用 AI_ADDRCONFIG 时，glibc 根据本地已配置的非回环地址决定返回哪些地址族；只有回环接口的容器因此可能不同于普通主机。两个工具即便都调用 libc，也未必请求相同地址族或标志。空结果不能立即解释为域名不存在，尤其在隔离实验、极简容器和刚启动的网络环境中，应先核对调用参数。 快速验证 将脚本保存为 check-resolution.py，准备 Docker 后执行 python3 check-resolution.py。脚本构建固定的 Debian 环境，使用 BIND 9.18.49、dnsmasq 2.90 和 glibc 2.36。可丢弃容器只有回环网络；hosts、NSS 与解析器配置修改全部发生在容器内部，不把宿主文件作为实验可写状态。每次创建独立实例，并在结束后清理自己的容器和镜像标签： ...