家里路由器前后换过好几台，从两百元价位TP-Link到五百多元华硕，后台设置翻来覆去核心选项就那么几项。DNS设置页面大多只有自动获取、手动填写IP两个选项，少数型号额外附带DNSSEC开关，几乎看不到DoH或者DoT相关配置。
这件事算不上严重故障，但确实是一个值得留意的现状。
日常上网发起DNS查询，默认走明文UDP 53端口。简单解释，你在设备输入网址，这条查询请求从手机或者电脑发出，经过路由器、运营商网关，链路当中任意设备都可以读取你查询的域名信息，还能篡改返回的解析结果。运营商DNS劫持植入广告，公共WiFi环境跳转钓鱼页面，底层原理都是利用明文DNS的漏洞。加密DNS的作用就是给查询请求加上加密封装，链路中间节点无法读取请求内容，也不能篡改解析返回结果。DoH依托443端口传输，流量混在普通HTTPS请求里面，外部很难识别；DoT使用853专用端口搭建加密通道，容易被识别，但管理操作更加简便。
这两项技术并不是新近研发出来的。Chrome、Firefox、Edge浏览器设置界面都内置DoH开关，Android 9及以上系统自带私有DNS功能，iOS系统同样支持加密DNS配置。终端设备层面本身已经具备加密DNS运行条件。
问题卡点落在路由器设备上。
打开路由器后台查看，国内主流品牌TP-Link、小米、华为、腾达、水星，面向普通消费者售卖的家用型号，后台基本找不到加密DNS配置入口。少数高端机型通过固件更新悄悄增加DoH、DoT选项，默认处于关闭状态，产品说明书也不会标注这项功能，绝大多数用户根本不知道该功能存在。
厂商不愿意内置这项功能，存在几方面原因。
用户感知度很低。绝大多数人买回路由器通电之后就不再改动设置，甚至不清楚DNS是什么。厂商投入开发成本增加加密DNS功能，对产品销量几乎无法带来提升。有知乎用户分析过这个现象，结论很直白，有相关需求的用户会自行在终端设备调试，没有需求的用户就算开放配置选项也不会使用。
硬件成本也是制约因素。加密DNS运行需要TLS握手、证书校验、HTTP/2协议栈运算，会额外消耗路由器CPU以及内存资源。低端路由器硬件性能余量很小，新增加密DNS客户端程序，会增大固件体积，占用运行内存，还有概率降低设备运行稳定性。IANN有文档专门讨论CPE路由器部署加密DNS转发器相关问题，提到证书申请与管理会带来规模化运维负担。
还有一个比较隐蔽的因素。运营商宽带服务捆绑DNS解析服务，DNS查询日志本身具备商业利用价值。加密DNS会阻断这条日志采集路径。虽然没有运营商公开承认这点，但行业内部都清楚这个情况。
不过行业情况正在发生变化。
2024年工信部批准发布YD/T 4712-2024《域名系统解析数据加密传输技术要求》，规范明确加密DNS需要采用TLS 1.2及以上版本，推荐DoT、DoH、DoQ、DoD四类加密方案，标准自2024年7月1日正式实施。该标准适用对象包含DNS服务提供商、网络运营商和管理机构。2025年发布YD/T 6470-2025《基于HTTPS的DNS传输技术要求》，2025年11月1日生效。2026年出台YD/T 7428-2026《加密DNS递归服务器发现技术要求》，规范主机借助DHCP和路由器通告消息自动识别加密DNS服务器的技术方案。
相关标准框架已经落地，但落实到家用路由器产品还有一段距离。
现有标准主要约束DNS服务端以及运营商侧设备，针对路由器厂商没有强制约束力。YD/T 4712-2024适用范围写明DNS服务提供方、网络运营商和管理机构，没有明确覆盖家用路由器这类终端用户设备。加密DNS递归服务器发现技术要求只规范自动发现机制，前提是路由器固件本身支持该功能。
是否可以推动相关规范进一步落地，把路由器厂商纳入规范范围？
从技术实现层面完全可行。路由器搭载加密DNS客户端难度并不高。OpenWrt开源社区很早就开发https-dns-proxy、smartdns、AdGuard Home这类方案，安装几兆大小软件包就可以启用。GL.iNet固件从4.9版本开始全面支持DoT、DoH和DoQ；华硕Wi-Fi7路由器预装AdGuard DNS；TP-Link Deco系列也在2026年初固件更新新增DoH、DoT配置选项。说明不存在技术壁垒，核心取决于厂商是否愿意投入开发。
从用户需求角度来说，普通用户对DNS安全感知偏弱，但运营商DNS劫持属于行业普遍问题。有用户反馈江苏电信DNS劫持现象严重，高峰期无论选用哪种明文DNS，都会被劫持，部分应用无法连接正常节点。这类使用体验问题会倒逼用户寻找解决方案，路由器层面开启加密DNS属于最优方案，一次配置，局域网全部设备都可以享受加密解析。
想要推动规范落地，可以参考几个方向。
在现有通信行业标准当中补充针对用户端CPE设备的相关条款。不用设置强制要求，可以采用推荐性规范，建议路由器厂商固件内置加密DNS配置入口，至少支持DoH或者DoT其中一种。标准当中写明最低实现要求，支持自定义DoH服务器地址，支持DHCP自动获取加密DNS配置。这样厂商拥有明确开发参考，用户选购产品也可以判断设备能力。
路由器入网检测或者产品认证环节，增加加密DNS支持情况标注项。不强制要求产品必须支持，但是产品参数说明里面，必须标注设备是否支持DoH、DoT。让消费者选购产品的时候可以直观看到这项参数，倒逼厂商完善功能。这个思路类似早年手机标注5G支持状态，一开始属于可选配置，后续慢慢变成标配。
鼓励运营商在宽带套餐配套提供加密DNS服务。国内已经存在阿里DNS、DNSPod、360 DNS这类公共加密DNS服务，运营商递归解析服务也可以升级支持DoT、DoH，借助DHCP加密DNS自动发现机制推送配置到用户路由器。用户不用手动修改参数，路由器自动启用加密DNS。这套方案需要运营商投入改造，但YD/T 7428-2026已经给出对应的实现路径。
同时还有现实问题需要权衡。加密DNS会给网络管理带来影响。企业内网、校园机房、家长管控软件，传统内容过滤机制依靠监控DNS查询流量实现。一旦启用DoH，网络管理员无法查看DNS流量。这个问题不是国内独有，全球行业都在讨论。NIST在2025年发布DNS安全部署指南，专门提及可以依靠防火墙规则或者路由器ACL策略拦截未授权DoT流量。加密DNS推广需要兼顾网络管控需求，不能一刀切全面放开。
平衡管控需求不等于放弃推进加密DNS。加密DNS带来的隐私保护价值很明确。传统明文DNS传输，链路中间人能够获取用户访问站点记录，还能篡改解析结果跳转钓鱼网站，公共WiFi环境风险尤其突出。加密DNS至少保护终端设备到递归DNS服务器这一段通信链路。它可以抵御链路中间人篡改，但无法解决权威服务器污染、加密DNS服务节点被阻断这类问题，这项局限性需要客观看待，不能因为无法解决全部风险就放弃部署。
回到普通用户视角。当下可选的解决办法不多，但有总比没有好。路由器支持刷OpenWrt固件，可以安装https-dns-proxy或者AdGuard Home，大概半小时完成部署。路由器不支持刷机，可以单独在电脑、浏览器开启DoH，至少保护单台终端DNS查询。路由器固件更新之后如果出现DoH配置选项，可以直接开启。
规范落地这件事方向可行，落地路径也已经清晰。现有标准框架已经搭建完成，下一步重点打通标准和终端产品之间的衔接。推动路由器厂商加入规范范围，让加密DNS从极客群体手动调试功能，变成路由器出厂自带能力。这个转变不会自动发生，需要持续推动。