要使systemd-resolved的DoT配置生效，必须禁用NetworkManager自动写入DNS：在/etc/NetworkManager/NetworkManager.conf的[main]段添加dns=none并重启NetworkManager，同时确保/etc/resolv.conf正确软链至/run/systemd/resolve/stub-resolv.conf。
能直接用 systemd-resolved 配置 DoT，但必须关掉 NetworkManager 的自动写入，否则配置会被覆盖。
systemd-resolved 启用 DoT 的最小必要配置
修改 /etc/systemd/resolved.conf，只保留关键项：
[Resolve] DNS=1.1.1.1 9.9.9.9 DNSOverTLS=yes DNSSEC=yes FallbackDNS=8.8.8.8 1.0.0.1
注意以下三点：
-
DNSOverTLS=yes不会自动降级；若目标服务器不支持 DoT（比如没开 853 端口或证书无效），查询会失败，不会 fallback 到明文 -
DNS列表中的地址必须真实支持 DoT：Cloudflare（1.1.1.1）、Quad9（9.9.9.9）、Google（8.8.8.8不支持 DoT，不能放这里） -
FallbackDNS是明文备用链路，仅在所有DNS条目完全不可达时才启用，不参与 DoT 失败后的重试
NetworkManager 必须设为 dns=none
默认情况下，NetworkManager 会无视 resolved.conf，直接把 DHCP 返回的 DNS 写进 /etc/resolv.conf，导致 DoT 配置失效。
执行以下操作：
- 编辑
/etc/NetworkManager/NetworkManager.conf，在[main]段下添加：dns=none - 重启服务：
sudo systemctl restart NetworkManager - 验证是否生效：
systemctl status systemd-resolved应显示 Active，且resolvectl status中 Global DNS 行应列出你配置的 DoT 地址
如果跳过这步，resolvectl status 里看到的 DNS 可能是 DHCP 给的，不是你配的 DoT 地址。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
验证 DoT 是否真正在工作
不能只看 resolvectl status 显示了 DoT 地址，要确认流量实际走 TLS 853：
- 抓包验证：
sudo tcpdump -i any port 853 -c 2，然后执行dig example.com @1.1.1.1，应捕获到 TLS 握手包 - 检查日志：
journalctl -u systemd-resolved -n 20 --no-pager | grep -i "tls\|dot"，应出现Using DNS-over-TLS或类似提示 - 故意配一个不支持 DoT 的地址（如
8.8.8.8）测试：若仍能解析，说明 DoT 没生效；若超时或报错connection refused，说明 TLS 连接确实在尝试
很多人卡在“配置写了但没生效”，根本原因是 NetworkManager 没禁用，或者用了不支持 DoT 的 DNS 地址却误以为失败是配置问题。
别忽略 /etc/resolv.conf 的软链接状态
systemd-resolved 正常工作依赖 /etc/resolv.conf 指向 /run/systemd/resolve/stub-resolv.conf。如果它是独立文件或指向别处，DoT 查询会绕过 resolved。
检查并修复：
- 运行
ls -l /etc/resolv.conf，应输出类似：lrwxrwxrwx 1 root root 39 ... /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf - 如果不是软链接，先备份原文件，再重建：
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf - 切勿手动编辑
/etc/resolv.conf—— 它是只读 stub，内容由 resolved 动态生成
这个软链接状态容易被脚本、容器初始化或旧版发行版破坏，是 DoT 配置后无响应的高频盲点。
