从一次内网访问失败说起：手把手教你排查麒麟KYLINOS的DNS配置（附systemd-resolved详解）
麒麟KYLINOS内网访问故障全流程诊断指南：从DNS失效到systemd-resolved深度解析
上周三凌晨2点15分，运维团队的电话突然响起——财务部门的月度结账系统无法访问内网报表服务器。当我远程连接到那台运行麒麟KYLINOS的终端时，ping report.internal的返回结果赫然显示"未知的名称或服务"。这个看似简单的DNS解析故障，最终演变成一场持续6小时的系统级诊断。本文将完整还原这次故障排查的技术细节，并深入解析systemd-resolved服务的工作机制。
1. 故障现象与初步诊断
内网域名解析失败往往表现为以下几种典型症状：
- 终端报错"未知的名称或服务"（Name or service not known）
- 浏览器显示"DNS_PROBE_FINISHED_NXDOMAIN"
- 特定内网服务突然无法连接，但IP直连正常
基础诊断三板斧应按照以下顺序执行：
# 1. 基础连通性测试 ping 8.8.8.8 # 2. DNS服务器可达性测试 ping 10.211.55.1 # 假设这是内网DNS服务器 # 3. 解析功能测试 nslookup report.internal当基础测试出现矛盾结果时（如能ping通DNS服务器但解析失败），就需要检查解析链路。在麒麟KYLINOS V10 SP1上，关键诊断命令包括：
# 查看当前生效的DNS配置 systemd-resolve --status | grep "DNS Servers" # 检查resolv.conf的符号链接状态 ls -l /etc/resolv.conf注意：在systemd-resolved服务正常工作的系统中，/etc/resolv.conf应该是指向/run/systemd/resolve/resolv.conf的符号链接
2. systemd-resolved服务深度剖析
现代Linux发行版中，DNS解析已从传统的静态配置演进为动态管理系统。麒麟KYLINOS采用的systemd-resolved服务架构包含三个核心组件：
| 组件路径 | 类型 | 作用描述 |
|---|---|---|
| /run/systemd/resolve/ | 运行时目录 | 包含动态生成的DNS配置文件和网络接口状态 |
| /etc/resolv.conf | 符号链接 | 指向运行时目录下的当前配置 |
| /lib/systemd/systemd-resolved | 守护进程 | 处理所有DNS请求，提供缓存、DNSSEC验证等功能 |
服务异常时常见的故障点包括：
- 符号链接断裂：/etc/resolv.conf指向不存在的路径
- 运行时目录丢失：/run/systemd/resolve/被意外删除
- 服务崩溃：守护进程异常退出
通过以下命令可以验证服务状态：
# 检查服务运行状态 systemctl status systemd-resolved -l # 查看服务日志 journalctl -u systemd-resolved --since "1 hour ago"3. 三级修复方案与实施步骤
根据故障严重程度，我们提供三种递进式解决方案：
3.1 初级方案：服务重启
适用于临时性故障，操作步骤：
- 重启systemd-resolved服务：
sudo systemctl restart systemd-resolved - 验证目录重建：
ls -l /run/systemd/resolve/ - 检查解析功能恢复：
resolvectl query example.com
3.2 中级方案：手动重建运行时环境
当服务重启无效时，需要手动修复：
# 创建运行时目录 sudo mkdir -p /run/systemd/resolve # 生成基础配置 cat <<EOF | sudo tee /run/systemd/resolve/resolv.conf nameserver 10.211.55.1 search internal.example.com EOF # 重建符号链接 sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf关键点：必须保持目录权限为systemd-resolve用户所有，否则服务无法修改配置
3.3 高级方案：系统级修复
对于顽固性故障，需要深度清理并重建配置：
完全停止服务：
sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved清理残留配置：
sudo rm -rf /run/systemd/resolve sudo rm -f /etc/resolv.conf重建基础配置：
sudo systemctl enable --now systemd-resolved sudo systemd-resolve --interface=eth0 --set-dns=10.211.55.1 --set-domain=internal
4. 防御性配置与监控策略
预防胜于治疗，推荐以下长效保障措施：
永久性配置方案：
# 创建持久化配置目录 sudo mkdir -p /etc/systemd/resolved.conf.d # 添加备用DNS配置 cat <<EOF | sudo tee /etc/systemd/resolved.conf.d/fallback.conf [Resolve] FallbackDNS=8.8.8.8 8.8.4.4 EOF监控方案建议：
定时检查脚本（crontab -e）：
*/5 * * * * /usr/bin/test -L /etc/resolv.conf || systemctl restart systemd-resolvedPrometheus监控指标：
- job_name: 'dns_health' metrics_path: '/metrics' static_configs: - targets: ['localhost:9153'] # systemd-resolved exporter端口
网络配置最佳实践：
- 避免直接修改/etc/resolv.conf
- 使用resolvectl管理各接口的DNS配置
- 为关键服务配置静态DNS记录：
resolvectl dns eth0 10.211.55.1 resolvectl domain eth0 ~internal
在完成所有修复后，建议运行完整的诊断测试套件：
#!/bin/bash # 完整DNS测试脚本 check_resolution() { if ! host "$1" >/dev/null; then echo "[ERROR] $1 resolution failed" return 1 fi return 0 } check_resolution "report.internal" && \ check_resolution "gateway.internal" && \ check_resolution "archive.internal" && \ echo "All DNS tests passed"