DNS流量劫持与篡改在Debian服务器和桌面环境中远比多数人想象的普遍。运营商HTTP劫持弹广告只是最表层的现象，更隐蔽的是中间设备对DNS响应包的静默替换，将你指向恶意镜像源或钓鱼站点。Debian系统默认使用UDP 53端口明文传输DNS查询，这意味着路径上的任何节点都可以看到你访问了哪些域名，甚至伪造响应包抢先返回给客户端。解决这个问题的根本方案不是频繁更换公共DNS地址，而是启用加密DNS传输，让查询内容不可见、响应结果不可篡改。

systemd-resolved的DoT原生支持

Debian 11及之后的版本默认安装了systemd-resolved，这个组件已经内置了DNS over TLS客户端能力，不需要额外安装任何软件包。很多人忽略了这个事实，反而去折腾stubby或dnscrypt-proxy，引入了不必要的复杂度。检查当前resolved状态用命令resolvectl status，你会看到当前使用的DNS服务器和传输协议。默认情况下，即使你手动配置了支持DoT的服务器地址，resolved也不会自动启用加密，需要显式开启DNSOverTLS选项。

编辑/etc/systemd/resolved.conf文件，找到DNS和DNSOverTLS配置项。一个典型的DoT配置如下：

[Resolve]
DNS=1.1.1.1 9.9.9.9 2620:fe::fe
DNSOverTLS=yes
DNSSEC=yes
Cache=yes

这里DNSOverTLS设置为yes表示对所有配置的DNS服务器强制使用TLS加密，如果某个服务器不支持TLS则不会回退到明文。DNSSEC开启后会对响应进行验证，防止中间人篡改。配置完成后执行systemctl restart systemd-resolved使配置生效，再用resolvectl status确认DNS over TLS状态显示为"opportunistic"或"yes"。注意，systemd-resolved默认监听127.0.0.53作为本地存根解析器，/etc/resolv.conf应该软链接到/run/systemd/resolve/stub-resolv.conf才能让所有应用通过这个本地代理进行加密查询。

DoT与DoH的本质区别与选择

DNS over TLS使用独立的853端口，流量特征明显，某些网络环境可能会直接阻断853端口的出站连接。DNS over HTTPS使用443端口，查询流量与普通HTTPS网页浏览完全混合，从流量层面无法区分，抗封锁能力更强。但DoH也有代价：每次查询都要走完整的HTTPS握手和HTTP/2帧封装，延迟比DoT高10到30毫秒。对于服务器场景，稳定性优先于隐蔽性，DoT是更合理的选择。如果你在Debian桌面环境使用，且网络环境对加密DNS有主动干扰，那么DoH更适合。

使用dnscrypt-proxy实现DoH与灵活路由

当systemd-resolved的DoT无法满足需求时，dnscrypt-proxy是Debian生态中最强大的替代方案。它同时支持DoH、DoT、DNSCrypt v2协议，并且内置了域名过滤、日志记录、负载均衡等高级功能。安装命令apt install dnscrypt-proxy，安装过程中会提示选择上游解析器。安装后的配置文件位于/etc/dnscrypt-proxy/dnscrypt-proxy.toml，这个文件使用TOML格式，注释详尽。

核心配置段如下，需要取消注释并修改：

listen_addresses = ['127.0.0.1:53']
server_names = ['cloudflare', 'quad9-dnscrypt-ip4-filter-pri']
max_clients = 250
force_tcp = false
timeout = 5000
keepalive = 30
cert_refresh_delay = 240
fallback_resolvers = ['9.9.9.9:53']
ignore_system_dns = true

server_names指定使用的上游服务器名称，这些名称必须与dnscrypt-proxy自带的公共服务器列表中的名称完全匹配，列表文件在/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv。fallback_resolvers是兜底用的明文DNS，仅在所有加密服务器不可达时使用，建议至少保留一个。listen_addresses改为127.0.0.1:53意味着dnscrypt-proxy直接监听本地53端口，需要先停掉systemd-resolved释放端口：systemctl stop systemd-resolved && systemctl disable systemd-resolved，然后启动dnscrypt-proxy。

dnscrypt-proxy的一个独到功能是匿名中继（Anonymized DNS），它在上游服务器前增加一层中继节点，使得上游服务器无法知道真实客户端IP。在配置文件中设置routes即可启用，但这会显著增加延迟，仅在隐私要求极高的场景使用。

验证加密DNS是否真正生效

配置完成后的验证步骤至关重要，很多人以为配置写对了就万事大吉，实际上可能因为防火墙拦截或上游服务器故障导致回退到明文。最直接的验证方法是抓包分析：tcpdump -i eth0 port 853 or port 443 -n，然后执行几次dig或nslookup查询，观察是否有UDP 53端口的明文包流出。如果只看到853或443端口的TLS/HTTPS流量，说明加密生效。另一个方法是使用Cloudflare的辅助诊断页面，在Debian命令行下执行dig txt whoami.ds.chaika.net @127.0.0.1，返回的文本中会包含解析器看到的你的公网IP和使用的协议类型。

还可以用kdig工具进行更详细的诊断：kdig -d @127.0.0.1 example.com +tls，输出中会显示TLS握手过程和证书信息。如果握手失败，检查系统时间是否准确，TLS证书验证依赖正确的系统时钟，偏差超过5分钟就会失败。Debian下用timedatectl set-ntp true确保NTP时间同步正常工作。

Stubby作为轻量级DoT专用方案

Stubby是getdns项目的一部分，专注于DoT协议，代码量小、攻击面窄。对于只需要DoT的Debian服务器，Stubby比dnscrypt-proxy更轻量。安装apt install stubby，配置文件/etc/stubby/stubby.yml采用YAML格式。一个生产可用的配置：

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
round_robin_upstreams: 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1@53
  - 0::1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"

tls_auth_name是TLS证书验证的关键字段，必须与服务器证书中的SAN名称完全匹配。如果这个字段填错，Stubby会拒绝连接。round_robin_upstreams开启后会在多个上游间轮询，避免单点故障。Stubby启动后同样需要修改/etc/resolv.conf指向127.0.0.1。

避免常见的DNS泄露陷阱

配置加密DNS后，系统中可能还存在多个DNS解析路径，导致部分查询绕过加密通道。最常见的泄露源有三个：一是NetworkManager接管了DNS设置，在连接配置中写入了明文DNS服务器地址；二是DHCP客户端从路由器获取的DNS服务器被直接写入/etc/resolv.conf；三是某些应用（如浏览器、邮件客户端）内置了独立的DNS解析逻辑，不遵循系统设置。

对于NetworkManager，编辑/etc/NetworkManager/conf.d/dns.conf，添加以下内容阻止其修改resolv.conf：

[main]
dns=none

然后重启NetworkManager服务。对于DHCP客户端，编辑/etc/dhcp/dhclient.conf，注释掉或删除request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers这一行中的domain-name-servers，让DHCP不再请求DNS服务器信息。对于应用层泄露，Firefox浏览器需要在设置中搜索"DNS over HTTPS"，选择"关闭"或"使用系统代理"，让它走系统配置的加密DNS而非浏览器内置的DoH。

进阶：用iptables强制所有DNS流量走加密通道

即使系统配置正确，某些恶意软件或配置错误的容器可能直接向8.8.8.8的53端口发送明文查询。用iptables可以拦截所有出站UDP 53流量，只允许本地加密代理向外通信。规则如下：

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53

这两条规则将所有发往外部的DNS查询重定向到本地的加密代理，无论应用如何配置都会被强制加密。但要注意，dnscrypt-proxy或Stubby自身需要向上游发送加密查询，它们的出站目标端口是853或443，不会被上述规则拦截。如果代理本身也需要通过53端口与上游通信（如fallback场景），则需要添加例外规则放行代理进程的流量。

对于使用nftables的Debian新版本，等效规则为：

nft add table nat
nft add chain nat prerouting { type nat hook output priority -100 \; }
nft add rule nat output meta l4proto udp th dport 53 dnat to 127.0.0.1:53
nft add rule nat output meta l4proto tcp th dport 53 dnat to 127.0.0.1:53
故障排查与性能调优

加密DNS偶尔会遇到连接超时或证书验证失败的问题。systemd-resolved的日志通过journalctl -u systemd-resolved查看，dnscrypt-proxy的日志在/var/log/dnscrypt-proxy.log。常见错误包括：TLS handshake timeout通常是因为网络中间设备丢弃了853端口的数据包，尝试切换到DoH或使用443端口的DoT服务器；certificate verify failed说明系统CA证书库过旧或上游服务器更换了证书，执行apt install --reinstall ca-certificates更新证书库。

性能方面，加密DNS的首次查询延迟会比明文高50到100毫秒，因为需要完成TLS握手。启用缓存可以大幅降低后续查询延迟。systemd-resolved默认启用缓存，dnscrypt-proxy在配置文件中设置cache=true且cache_size=4096。对于高并发场景，可以考虑部署本地递归解析器unbound，由unbound完成递归查询并通过DoT转发到上游，这样局域网内所有设备共享缓存，命中率更高。

最后提醒一点，加密DNS保护的是查询内容的机密性和完整性，但它不隐藏你访问的IP地址。SNI（Server Name Indication）在TLS握手阶段仍然是明文传输的，网络中间设备可以看到你连接的目标服务器IP和域名。如果需要隐藏这部分信息，需要使用ECH（Encrypted Client Hello）或代理技术，这超出了DNS加密的范畴。