Ubuntu DNS服务器地址

Ubuntu系统中配置DNS服务器地址，通常通过修改/etc/resolv.conf文件（临时）或使用netplan（推荐，永久生效）来实现，resolv.conf中添加nameserver 8.8.8.8等条目可指定DNS；但若使用systemd-resolved或NetworkManager，该文件可能被自动覆盖，更可靠的方式是编辑Netplan配置文件（如/etc/netplan/*.yaml），在nameservers字段下设置IP列表，然后运行sudo netplan apply生效。

Ubuntu 系统中 DNS 服务器地址的配置原理、故障诊断与企业级优化实践指南

在现代网络架构中,DNS（Domain Name System，域名系统）远不止是互联网的“电话簿”——它是整个TCP/IP协议栈中首个也是最关键的信任锚点，它将人类可读的域名（如 archive.ubuntu.com）精准映射为机器通信所需的IP地址（如 12.23.10），对 Ubuntu 用户而言，DNS 服务器地址的配置质量，直接决定：软件源是否可更新（apt update）、容器服务能否拉取镜像、SSH 连接是否稳定、HTTPS证书验证是否通过，甚至影响系统级日志审计与安全事件溯源的完整性，实践中，大量用户遭遇“能 ping 通 IP 却打不开网页”“curl: Could not resolve host”或“systemd-resolved 持续返回 127.0.0.53”等现象，根源常非网络中断，而是对 Ubuntu 多层 DNS 控制机制缺乏系统认知，本文摒弃碎片化命令罗列，从内核网络栈到用户空间服务，逐层解构 DNS 服务器地址的**实际生效路径、优先级冲突本质、静默覆盖风险及生产环境加固策略**，全文严格围绕“Ubuntu DNS 服务器地址”这一核心命题展开，提供具备架构视野与一线运维价值的技术闭环方案。

自 Ubuntu 18.04 LTS 起，系统默认启用 systemd-resolved 作为统一 DNS 解析守护进程，并与 Netplan（YAML 驱动的声明式网络配置工具）深度协同，这一演进彻底终结了传统 /etc/resolv.conf 的静态写入模式——该文件在绝大多数新版 Ubuntu 中仅为指向 /run/systemd/resolve/stub-resolv.conf 的符号链接，其内容由 systemd-resolved 动态生成。**手动编辑 /etc/resolv.conf 不仅无效，且会在下次网络重载（netplan apply）或系统重启后被强制覆盖**，真正的 DNS 服务器地址控制权，分布于四个具有明确继承关系的层级：
① Netplan 配置层（/etc/netplan/*.yaml 中的 nameservers 字段）——最高优先级，直接绑定至物理/虚拟接口；
② NetworkManager 层（图形界面设置或 nmcli dev modify eth0 ipv4.dns "114.114.114.114"）——适用于桌面环境，但会覆盖 Netplan 的部分接口配置；
③ systemd-resolved 全局层（/etc/systemd/resolved.conf 中的 DNS= 或 FallbackDNS=）——作为兜底策略，仅当上层未指定时生效；
④ 容器运行时层（Docker 的 --dns 参数或 /etc/docker/daemon.json）——完全独立于宿主机解析链，需单独配置。
**四者并非并列，而是存在严格的覆盖链：Netplan > NetworkManager > resolved.conf；忽略此优先级，是 90% 以上“配置后不生效”问题的根本症结。**

验证当前真正生效的 DNS 服务器地址，绝不可依赖 cat /etc/resolv.conf——该文件仅反映 stub 解析器的本地端口（0.0.53），而非上游真实 DNS，正确方法为：
✅ resolvectl status（Ubuntu 20.04+ 推荐，输出清晰分组各接口 DNS）
✅ systemd-resolve --status | grep -A5 "DNS Servers"（兼容旧版）
例如输出：Link 2 (ens33): DNS Servers: 223.5.5.5 223.6.6.6，表明网卡 ens33 正使用阿里公共 DNS；若显示 DNS Servers: 127.0.0.53 且无其他条目，则说明 systemd-resolved 未配置上游，需检查 /etc/systemd/resolved.conf 中 DNS= 行是否被注释或留空，并确认 sudo systemctl restart systemd-resolved 已执行。

典型故障场景深度排查：
🔹 “能 ping 通 IP，但浏览器打不开网站”
本质是应用层 DNS 解析失败，应立即执行：
nslookup github.com 223.5.5.5（测试指定 DNS 连通性）→ 若成功，问题在本机 DNS 配置；若失败，再查 ufw status 是否拦截 UDP 53 端口、路由器是否启用 DNS 重定向、或 ISP 是否存在 DNS 劫持（可用 tcpdump -i any port 53 抓包验证响应来源）。
🔹 “apt update 报错 ‘Could not resolve archive.ubuntu.com’”
运行 getent ahosts archive.ubuntu.com（比 getent hosts 更可靠，支持 IPv4/IPv6 双栈）；若无输出，说明解析链断裂，重点核查：
– Netplan YAML 中 nameservers 是否遗漏或拼写错误（如误写为 name_servers）；
– 是否在纯 IPv4 网络中错误配置了 IPv6 DNS（如 2001:4860:4860::8888），导致 systemd-resolved 因双栈协商超时而降级失败。
🔹 “内网域名（如 intranet.corp）无法解析”
需启用条件转发（Split DNS），操作步骤：
1. 在 /etc/systemd/resolved.conf 中设 DNSStubListener=no（禁用 stub 监听）；
2. 安装并配置 dnsmasq（轻量）或 bind9（企业级），将其监听于 0.0.1:53；
3. 在 dnsmasq 中添加：server=/corp/10.1.1.10，将 .corp 域请求定向至内网 DNS；
4. 更新 Netplan，将 nameservers 指向 0.0.1，完成闭环。

安全与性能必须同步考量,公共 DNS（如 8.8.8）虽便捷，但明文 DNS 查询易遭窃听与污染，且运营商 DNS 可完整记录用户所有访问行为，生产环境强烈建议：
✅ 启用 DNS-over-TLS（DoT）：在 /etc/systemd/resolved.conf 中设置 DNSOverTLS=yes，并指定支持 DoT 的服务器（如 DNS=1.1.1.1#cloudflare-dns.com）；
✅ 部署本地递归解析器：使用 unbound 替代转发模式，实测数据（Ubuntu 22.04 + Intel i5-8250U）：
– 平均