DNS (传统DNS) DoH (DNS over HTTPS) DoT (DNS over TLS) ，DNS、DoH 和 DoT 之间区别的表格：DoH（DNS over HTTPS） DoT（DNS over TLS）DoQ（DNS over QUIC）

DNS / DoT / DoH / DoQ 时间线演进（按年代排序，含 RFC、关键事件）

DNS / DoT / DoH / DoQ 按年代演进时间线

主线逻辑：明文 DNS → 加密 DNS 第一版 DoT (TCP+TLS) → 穿墙优化 DoH (HTTPS) → 传输层重构 DoQ (QUIC)

1983 年｜原始 DNS（明文）

  • RFC882/RFC883，1983 年 11 月；后续 1987 年 RFC1034/RFC1035 定型现代 DNS 规范IETF
  • 传输：UDP 53 为主，超长报文切 TCP 53，全部明文
  • 痛点：任何中间网络都能看到域名，易劫持、窃听、篡改
  • 背景：早期互联网规模小，只考虑域名解析功能，无隐私 / 安全设计

补充：后续出现 DNSSEC（2005 RFC4035），DNSSEC 是对 DNS 应答内容签名，不是加密传输，和 DoT/DoH/DoQ 不是一类（很多人混淆）。

2016 年 5 月｜DoT — DNS over TLS，RFC7850（RFC7858）正式标准化IETF

  • 全称：DNS over TLS
  • 传输：TCP 之上建立 TLS 隧道，专用端口 853
  • 设计目标：对 DNS 传输加密，解决明文 DNS 窃听劫持；DNS 原生报文，不封装 HTTP
  • 短板：底层 TCP 存在队头阻塞；853 是独立端口，防火墙很容易识别并封禁
  • 落地：路由器、Linux、Stub resolver 优先支持；公共 DNS 开始部署 DoT 服务

2018 年 10 月｜DoH — DNS over HTTPS，RFC8484 标准化RFC Editor

  • 全称：DNS Queries over HTTPS
  • 传输：DNS 报文封装进 HTTP，跑在标准 443 HTTPS 端口；底层 HTTP/2（TCP）
  • 设计目标：解决 DoT 的端口容易被封的问题；443 和普通网页 HTTPS 流量混在一起，隐蔽性强
  • 短板：HTTP 头部带来额外开销；底层 TCP 依旧存在队头阻塞；会绕过企业内网 DNS，引发企业侧争议
  • 落地：Chrome、Firefox 浏览器内置支持，Cloudflare、阿里、腾讯公共 DNS 大规模上线 DoH，成为目前普及率最高的加密 DNS

2022 年 5 月｜DoQ — DNS over QUIC，RFC9250 正式标准化IETF

  • 全称：DNS over Dedicated QUIC Connections
  • 传输：UDP 之上的 QUIC，内置 TLS1.3，无 HTTP 层；推荐端口复用 853，也可使用 443
  • 设计目标：保留 DoT 简洁报文，同时干掉 TCP 队头阻塞；QUIC 自带多路复用、快速握手、连接迁移
  • 短板：QUIC 属于较新协议，防火墙、中间盒对 QUIC 识别 / 拦截较多；部署成本高
  • 落地：Cloudflare、AdGuard、Quad9 等公共 DNS 支持 DoQ；操作系统、客户端逐步适配，属于下一代加密 DNS 方向

时间线简表

年份 协议 RFC 核心创新 底层传输 主要短板
1983 DNS RFC882/883；1987 RFC1034/1035 分布式域名解析 UDP53 / TCP53 明文，可窃听劫持
2016 DoT RFC7858 DNS 报文 TCP+TLS 加密 TCP+TLS，853 TCP 队头阻塞；853 端口易封禁
2018 DoH RFC8484 DNS 封装 HTTPS，复用 443 HTTP/2 over TCP，443 HTTP 额外开销；TCP 队头阻塞
2022 DoQ RFC9250 DNS 原生跑 QUIC UDP+QUIC(TLS1.3)，853 QUIC 容易被中间网络拦截

一句话演进逻辑（按时间）

1983：DNS，明文能用，但是不安全 → 2016：DoT，给 DNS 套 TLS 加密，但 853 端口容易被封，TCP 丢包会卡 → 2018：DoH，把 DNS 藏进 HTTPS 443 穿墙，但 HTTP 开销大，TCP 队头阻塞依旧存在 → 2022：DoQ，抛弃 TCP，直接用 QUIC 承载原生 DNS，兼顾加密、低延迟、多路复用，下一代标准

DNS → DoT → DoH → DoQ 完整演进脉络

核心痛点：传统 DNS明文 UDP 53，极易被窃听、劫持、污染、中间篡改；后续几个协议本质是把 DNS 报文封装进加密传输层，只是选用的传输协议不一样。

协议 全称 传输层 端口 加密 诞生背景
DNS Domain Name System UDP 53（优先），TCP 53（超长包） 53 ❌ 明文 1983，原始设计，无安全考虑
DoT DNS over TLS TCP + TLS 853 TLS 1.2/1.3 2016 RFC7858，DNS over TCP 套 TLS
DoH DNS over HTTPS HTTP/2 / HTTP/3 + TLS 443 TLS 1.2/1.3 2018 RFC8484，DNS 报文放在 HTTPS POST/GET
DoQ DNS over QUIC QUIC 853（推荐） QUIC 内置 TLS1.3 2022 RFC9250，DNS 原生跑 QUIC

1. 原生 DNS（1983）

原理

  • 查询：客户端 UDP 53 发明文 DNS 请求；服务器 UDP 53 返回明文应答。
  • 超过 512 字节截断，自动降级 TCP 53。

缺陷

  1. 全部明文：网络中间设备（运营商、防火墙）可以看到你访问了哪个域名。
  2. 极易 DNS 劫持 / 污染：中间人伪造应答包。
  3. UDP 无连接：丢包就重传，延迟不稳定。
  4. 端口固定 53：防火墙很容易识别并阻断。

安全属性：无加密、无身份认证。

2. DoT — DNS over TLS（RFC7858，2016）

演进思路

在TCP 连接之上建立 TLS 加密隧道，DNS 报文在 TLS 隧道内传输。

  • 端口：853（专用端口）
  • 流程：TCP 握手 → TLS 握手 → 传输 DNS 报文

优点

  • 完整加密，中间人看不到域名；TLS 校验服务器证书防伪造。
  • 协议简单，保持 DNS 报文原生格式，不用封装 HTTP。

缺点

  1. 底层是 TCP：TCP 队头阻塞，丢包时整条连接卡住。
  2. 专用端口 853：很多防火墙 / 运营商直接封禁 853 端口（识别特征明显）。
  3. TLS 握手开销大（TCP+TLS 两次握手），冷启动延迟高。
  4. 连接复用差。

一句话：TCP+TLS 加密 DNS，但是端口容易被墙，TCP 有队头阻塞。

3. DoH — DNS over HTTPS（RFC8484，2018）

演进思路

把 DNS 请求包装成HTTP 请求跑在 443 端口 HTTPS 上。 两种方式：

  • GET：DNS 报文 base64 编码放在 URL 参数
  • POST：二进制 DNS 报文放在 HTTP body 底层 HTTP/2（主流），HTTP/3 也可以。 端口复用标准 HTTPS 443。

优点

  1. 端口 443，和普通 HTTPS 网站流量一模一样，流量特征隐蔽，很难单独阻断。
  2. TLS 加密 + 证书校验，防窃听劫持。
  3. HTTP/2 多路复用，单连接并发多个查询。

缺点

  1. HTTP 封装开销大：额外 HTTP 头部，报文更大。
  2. HTTP/2 仍然基于 TCP，TCP 队头阻塞依然存在。
  3. 流量虽然是 443，但可通过 SNI 等方式识别是 DoH 服务端。
  4. 很多企业防火墙 / 代理会解析 HTTPS（SSL 中间人），可以解密 DoH。
  5. 客户端实现复杂，需要完整 HTTP 栈。

一句话：DNS 藏在 HTTPS 里，利用 443 端口穿墙，但是背负 TCP 的缺陷。

争议：DoH 会绕过企业内网 DNS，所以很多企业网络禁止 DoH。

4. DoQ — DNS over QUIC（RFC9250，2022）

演进思路

直接把 DNS 跑在 QUIC 协议上，不再依赖 TCP，QUIC 自带 TLS1.3。 推荐端口复用 DoT 的853，也可以用 443。 QUIC 是 UDP 之上实现的可靠传输。

优点

  1. QUIC 基于 UDP，彻底消除 TCP 队头阻塞：一个流丢包，不影响其他并发 DNS 查询。
  2. QUIC 内置 TLS1.3：握手更快（1-RTT 甚至 0-RTT）。
  3. 原生支持多路复用，并行 DNS 查询。
  4. 报文结构比 DoH 简洁，没有 HTTP 头部冗余，开销低于 DoH。
  5. 连接迁移：客户端切换 Wi‑Fi / 蜂窝网络，QUIC 连接可以保持，不用重新握手。

缺点

  1. QUIC 相对新，老设备、防火墙、中间盒对 QUIC 支持差，容易丢包拦截。
  2. 端口 853 仍然容易被识别阻断；如果用 443，会和 HTTP/3 流量混在一起。
  3. 服务端部署成本更高。

一句话：DoT 的简洁 + DoH 的多路复用，底层换成 QUIC，解决 TCP 固有缺陷，下一代 DNS 加密标准

演进对比总结

项目 DNS DoT DoH DoQ
底层传输 UDP/TCP TCP TCP(HTTP/2) / UDP(HTTP/3) UDP(QUIC)
加密 无 TLS1.2/1.3 TLS1.2/1.3 QUIC 内置 TLS1.3
端口 53 853 443 853 (推荐)
队头阻塞 UDP 无；TCP 有 ✅ TCP 队头阻塞 ✅ HTTP/2 TCP 队头阻塞；HTTP/3 无 ❌ 无队头阻塞
报文开销 最小 中等 最大（HTTP 头） 较小
流量隐蔽性 完全暴露域名 较差（853 端口） 很好（443） 中等（853）
握手延迟 最低 高 (TCP+TLS) 高 低（1-RTT）

演进逻辑链条

原始明文DNS（UDP53）
    ↓ 安全问题：窃听劫持 → 套TLS over TCP
DoT（TCP+TLS:加密，但853易封、TCP队头阻塞）
    ↓ 端口容易被识别封禁 → 复用443伪装成网页流量
DoH（HTTPS封装，443穿墙，但是HTTP开销、TCP队头阻塞还在）
    ↓ 想保留加密+多路复用，同时干掉TCP队头阻塞 → 换QUIC
DoQ（QUIC+TLS1.3，UDP上层，无队头阻塞，新一代）

补充容易混淆的点

  1. DoQ ≠ HTTP/3。HTTP/3 是 QUIC 承载 HTTP；DoQ 是 QUIC直接承载 DNS 报文，没有 HTTP 层，这点和 DoH 本质区别。
  2. DoT 和 DoQ 推荐端口都是 853，但传输完全不同：DoT=TCP+TLS；DoQ=UDP+QUIC。
  3. 不是 DoQ 一定比 DoH 快：中间网络如果屏蔽 QUIC，DoQ 会直接失败，DoH (443) 兼容性更强。

应用现状

  • DoT：路由器、Linux 系统常用，但是国内运营商网络经常封 853。
  • DoH：Windows、Chrome、Firefox 主流内置支持，公共 DNS（Cloudflare、阿里 DNS、腾讯 DNS）广泛部署。
  • DoQ：2022 标准化，目前处于推广期；Cloudflare、AdGuard 等公共 DNS 支持，操作系统和客户端支持还在完善，属于下一代方向。
DNS 没有“一个最新 RFC 替换老协议”，而是 RFC 1034/1035 仍是底座（STD 13），EDNS 是现行扩展面，TCP 是强制兜底，DNSSEC 是安全扩展，DoT/DoH/DoQ 是传输加密层，SVCB/HTTPS 是服务发现层。未来不是换掉 DNS，是 明文 Do53 继续存在，但客户端到递归解析器默认走加密传输，权威侧仍跑 Do53+DNSSEC+TCP。

一、核心规范：哪些还是金标准

1. 基础协议（不变）

  • RFC 1034​ Domain names - concepts and facilities，STD 13，Internet Standard。
  • RFC 1035​ Domain names - implementation and specification，STD 13，Internet Standard。定义报文头、各段、A/NS/CNAME/SOA/PTR/MX/TXT、UDP 512 限制、TC 位处理。
  • RFC 1123​ 主机应用层要求，部分行为补充。
  • RFC 2181​ 对 1034/1035 的澄清：RRSet TTL 一致、zone cut、TC 位、label 合法字符。
  • RFC 2308​ 负缓存：NXDOMAIN / NODATA、负 TTL。
  • RFC 1982​ 序列号算术（SOA serial）。
  • RFC 3597​ 未知 RR 类型透明处理。
写解析器、权威服务器、排错，先引 1034/1035/2181/2308，不是引 DoH。

2. 传输层（容易被忽略但必须实现）

  • RFC 6891​ EDNS(0)，Internet Standard。OPT 伪记录、UDP payload size、扩展选项、DNS Cookies 基础。
  • RFC 7766​ DNS over TCP 实现要求，替代 5966。TC=1 必须能用 TCP 重查，权威和递归都不能禁 TCP 53。
  • RFC 9715​ DNS over UDP 的 IP 分片规避，生产建议 EDNS 缓冲区设 1232 或 1220，不靠 IP 分片。
  • RFC 8900​ IP 分片被认为脆弱，背景参考。

3. 区域传送与动态更新

  • RFC 1995 IXFR、RFC 1996 NOTIFY、RFC 2136 UPDATE、RFC 5936 AXFR、RFC 9103 XFR-over-TLS。

4. 安全扩展

  • RFC 4033/4034/4035​ DNSSEC-bis，现行 Proposed Standard 体系，被后续 6840/8078/8624/9157/9364 更新。
  • RFC 5155 NSEC3、RFC 6840 澄清、RFC 8624 算法要求、RFC 9364 DNSSEC 全链路指引。
  • RFC 2845 TSIG、RFC 3645 GSS-TSIG，主辅同步和动态更新鉴权用。
  • RFC 7873 DNS Cookies，无状态防放大。

5. 现代记录与发现

  • RFC 3596​ AAAA。
  • RFC 2782​ SRV。
  • RFC 8659​ CAA。
  • RFC 9460​ SVCB / HTTPS 记录，HTTP/3、ECH、ALT-SVC、加密 DNS端点发现都靠它。
  • RFC 7871​ ECS，边缘 CDN 用，但隐私折中，默认不传全前缀。
  • RFC 8914​ Extended DNS Errors，排错神器。

二、加密传输层：Do53 之外三件套 + HTTP/3

传输
RFC
端口
定位
明文 DNS
1035+6891
53/UDP、53/TCP
权威、内网、任意递归基线，必须保留
DoT
RFC 7858​ + 8310 使用画像
853/TCP/TLS
系统级、企业级、运营商级，策略清晰
DoH
RFC 8484​
443/HTTPS
浏览器、移动端、抗阻断、融进 Web 流量
DoQ
RFC 9250​
853/UDP/QUIC
低延迟、弱网、移动切网，生产可用但客户端覆盖还在扩
DoH3
8484 + RFC 9114
443/QUIC
DoH over HTTP/3，现代客户端自动升级
ODoH
RFC 9230
HTTPS
分离客户端 IP 与查询内容，隐私增强，运维重
DoT/DTLS
7858+8094
—
实验性，少生产
引用关系上，RFC 9250 明确 normative 引 1034/1035/6891/7766/7858/8446/9000。

三、自动发现与迁移到加密 DNS

  • RFC 9461​ SVCB/HTTPS 映射加密 DNS 服务器参数。
  • RFC 9462​ DDR（Discovery of Designated Resolvers），客户端拿普通解析器 IP，查 _dns.resolver.arpa 的 SVCB，自动发现同一运营方的 DoT/DoH/DoQ。
  • RFC 9463​ DHCP/RA 下发加密 DNS。
  • 实战含义：以后不是手填 https://1.1.1.1/dns-query，而是网络通告或 DDR 自动升级，但明文 Do53 仍作为 bootstrap。

四、配套 RFC 速查表

层
必引 RFC
报文/语义
1034、1035、2181、2308、1982、3597
传输
6891、7766、9715、8900
安全
4033、4034、4035、6840、8624、9364、2845、7873
记录
3596、2782、8659、9460
区传
1995、1996、2136、5936、9103
加密传输
7858、8310、8484、9250、9114、9230
隐私
7830、8467、9076、9156（QNAME 最小化）
发现
9460、9461、9462、9463
术语
8499 被 9499 更新，查词用新术语表
参数注册
IANA DNS Parameters，所有 opcode/rcode/rr/option 以它为准
 

五、未来切换判断：不是淘汰 Do53，是分层

1. 权威侧长期不动

根、TLD、企业权威服务器继续 Do53+TCP+DNSSEC。
  • EDNS 缓冲区默认 1232/1220，不鼓励大包 IP 分片。
  • 必须开 TCP 53，否则大 DNSSEC 响应会挂。
  • DNSSEC 验证在递归侧做，权威只签不验。
  • 未来加 SVCB/HTTPS 是为了服务发现，不是改查询语义。

2. 客户端到递归解析器：明文→加密

趋势：
  • 系统级：Android/iOS/Win/Linux 走 DoT 或平台私有加密 DNS。
  • 浏览器：DoH 默认，但受企业管理覆盖。
  • 移动/弱网：DoQ 和 DoH3 吃性能红利，QUIC 0-RTT、无队头阻塞、连接迁移。
  • 物联网：MUST 支持 EDNS(0)，SHOULD 支持 DoT/DoQ/DoH，MUST 支持 TC 后走 TCP。
但明文 Do53 不会消失：
  • 内网服务发现、容器、DHCP 下发、故障启动、DDR bootstrap 都靠它。
  • 加密是“到递归这一段”，不是全链路加密，权威链还是明文+DNSSEC。

3. 隐私演进方向

  • 传输加密：DoT/DoH/DoQ 解决链路窃听。
  • 查询最小化：RFC 9156 QNAME minimization。
  • 填充：RFC 7830 + 8467，抗长度指纹。
  • 分离信任：ODoH（RFC 9230）让解析器看不到“谁查了什么”。
  • 和 ECH 配合：HTTPS 记录带 ECH 配置，先加密 DNS 再加密 ClientHello，否则明文 DNS 先把域名漏了。

4. 性能演进方向

  • Do53：EDNS 1232，避免分片，任播+缓存。
  • DoT：TCP+TLS 开销固定，连接复用，edns-tcp-keepalive（RFC 7828）。
  • DoH：HTTP/2 多路复用，但首包握手重。
  • DoQ/DoH3：QUIC 流级并发，弱网民宿，未来移动端主线。

5. 企业/运营商视角

  • 别一刀切禁 DoH，禁了用户切公共 DoH 你更盲。
  • 正确做法：内网跑受控解析器，通过 DDR/RA/DHCP 推自家 DoT/DoH，做策略再上游加密转发。
  • 防火墙别禁 TCP 53，否则 DNSSEC 大包和 TC 重查会挂。
  • 监控层面：DoT 端口可见、DoQ 端口可见，DoH 融进 443 要靠 TLS SNI/ECH 状态和上游策略日志，不是抓 DNS 明文。

六、工程落地口径

  • 解析器实现：1035+2181+2308+6891+7766，EDNS 默认 1232，TC 必走 TCP，开 DNSSEC 验证，开 QNAME 最小化，开 Cookie 防放大。
  • 权威服务器：1035+2181+6891，TCP 53 必须开，DNSSEC 签名+Inline signing，大响应靠 EDNS 不是 IP 分片。
  • 公网递归给终端：同时提供 DoT/DoH，能就开 DoQ；用 DDR（9462）+ SVCB（9460/9461）自动发现。
  • 浏览器/前端：DoH 最稳，移动端新系统可 DoQ，内网管控走平台 DoT。
  • 物联网/嵌入式：EDNS MUST，TCP fallback MUST，加密 DNS SHOULD，别只实现 512 字节 UDP。
  • 排错：看 Extended DNS Errors（8914），看 TC 是否触发 TCP，看 DNSSEC 验证状态（AD/CD），别只 ping 通。

七、常见误解修正

  • “DNS 最新标准是 DoH” ❌ DoH 只是加密传输，底座还是 1035。
  • “RFC 1035 老了不用引” ❌ 所有 DNS 实现必须对齐，EDNS/DoH 都 normative 引它。
  • “DNSSEC 和 DoH 二选一” ❌ DNSSEC 管响应真伪，DoH 管传输窃听，两层叠加。
  • “禁 TCP 53 没事，UDP 够用” ❌ 大 DNSSEC 响应 TC=1，不禁 TCP 但服务器不开 TCP 会解析失败。
  • “DoQ 是未来，Do53 会没” ❌ Do53 是 bootstrap 和权威侧底座，加密只加在 stub-to-recursive 这一段。
  • “开了 1.1.1.1 就是加密 DNS” ❌ 没开 DoT/DoH/DoQ 就是明文，换 IP 不加密。
DNS 底座仍是 RFC 1034/1035（STD 13）+ RFC 2181/2308 + EDNS 6891 + TCP 7766；安全加 DNSSEC 4033-4035；客户端到递归默认走向 DoT 7858 / DoH 8484 / DoQ 9250，靠 SVCB 9460 + DDR 9462​ 自动发现；未来不是淘汰明文 Do53，而是权威侧不动、递归前段加密化、隐私走 QNAME 最小化+填充+ODoH、性能走 QUIC。

PixPin_2026-06-24_12-08-47

Windows 不原生支持 DoQ / HTTP/3 DoH 的底层完整原理

一、先理清四个协议底层承载差异

  1. 传统 DNS (UDP/TCP 53)
     
    传输层：UDP/TCP，操作系统网络栈原生内置传输逻辑，DNS Client 可直接调用 Winsock 发起报文。
  2. DoT (DNS over TLS)
     
    承载：TCP + TLS 1.3，端口 853。
     
    Windows 内置 Schannel TLS 库、TCP 传输栈，系统 DNS 客户端 dnscache 内置 TLS 握手、报文封装 / 解封装逻辑，属于系统网络栈原生能力。
  3. DoH (HTTP/2 over TLS)
     
    承载：TCP + TLS + HTTP/2，443 端口。
     
    Windows 内置 HTTP/2 解析、请求封装模块，dnscache 原生集成 HTTP 报文处理，能把 DNS 查询封装成标准 POST /dns-query 请求。
  4. DoQ (DNS over QUIC)、HTTP/3 DoH
     
    承载：QUIC 协议（基于 UDP，独立于 TCP 协议簇）。
     
    核心矛盾：Windows 系统内置 dnscache.dll（DNS Client 核心驱动）没有内置 QUIC 协议栈实现。PixPin_2026-06-24_12-08-56

二、Windows DNS Client 底层架构核心限制（根本原因）

1. dnscache 内核态 / 用户态分层设计

Windows 域名解析分为两层：
  1. 用户态服务：dnscache 服务，对应 dnscache.dll，负责协议封装（明文 DNS、DoT、HTTP/2 DoH）、缓存、网卡策略调度；
  2. 底层传输：依赖系统标准 Winsock 接口（TCP/UDP 标准套接字）。
微软仅在 dnscache 内部实现了三套解析封装器：
  • Plain DNS Parser（UDP/TCP 53）
  • DoT TLS Wrapper（TCP+TLS）
  • HTTP/2 DoH Wrapper（TCP+TLS+HTTP2）
没有开发 QUIC Wrapper，dnscache 内部不存在处理 QUIC 连接、QUIC 流、QUIC 加密会话的代码逻辑。

2. QUIC 协议栈独立，未下沉至系统基础 DNS 组件

Windows 确实内置 QUIC 支持（msquic.dll），但使用范围严格隔离：
  • 上层应用（Edge、Chrome、第三方软件）可主动加载 msquic.dll 自行发起 QUIC 连接；
  • 底层系统基础服务（dnscache、DHCP、Winsock 基础解析）不允许依赖独立动态链接库 msquic.dll，出于系统稳定性、依赖解耦设计：
    1. dnscache 属于系统关键基础服务，启动不能附加额外第三方 / 附加系统 DLL 依赖；
    2. 早期 Win10/Win11 21H2、22H2 发布时，msquic 尚未成熟稳定，微软未将 QUIC 集成进 dnscache 核心代码；
    3. 微软系统设计规范：核心网络基础服务仅使用纯 TCP/UDP 标准套接字，不绑定实验性 / 上层应用专属传输协议。

3. HTTP/3 本质是 QUIC + HTTP，天然无法被原生 DNS 识别

HTTP/3 = HTTP 语义运行在 QUIC 之上。
 
系统 dnscache 的 DoH 模块只解析基于 TCP 的 HTTP/2，没有 QUIC 传输层承载能力：
  • 当地址为 h3://xxx/dns-query，dnscache 无法创建 QUIC 会话；
  • 无 QUIC 流复用、0-RTT 握手、UDP 拥塞控制、QUIC 报文分片重组逻辑，直接无法发起查询。

4. DoQ 标准完全基于 QUIC，无 TCP 兜底

DoQ 规范（RFC9250）规定：全程仅使用 QUIC，不兼容 TCP。
 
dnscache 只能创建 TCP/UDP 套接字，缺少 QUIC 连接上下文，无法完成：
 
QUIC 握手 → QUIC 加密流创建 → DNS 报文封装进 QUIC Stream → 接收反向解析报文 → 解密解包整套流程。

三、为什么脚本 / 注册表无法绕过这个底层限制？

  1. 注册表仅作用是配置上游 DNS 地址、协议启用开关（DoT/DoH），只是策略配置层；
  2. 真正执行协议封装的逻辑硬编码在 dnscache.dll 二进制内部；
  3. 注册表没有任何键值可以 “开启 QUIC 支持”—— 底层根本没有对应的代码分支，再怎么修改注册表、PowerShell 配置都无法新增不存在的协议处理逻辑。
简单类比：
 
注册表只是 “开关”，DoT/DoH 有对应的电路（代码），打开开关就能用；
 
DoQ/HTTP3 没有内置电路，无论怎么改开关配置，硬件底层不支持。

四、必须本地 DNS 代理才能使用 DoQ/HTTP3 DoH 的底层原理

本地代理（AdGuardHome、SimpleDnsCrypt、WARP）工作分层：
  1. 本机网卡 DNS 指向 127.0.0.1（代理本地监听端口，标准 UDP/TCP 53）；
  2. 系统 dnscache 只和本地代理走原生支持的标准 UDP 明文 DNS，不存在 QUIC 依赖；
  3. 代理程序独立加载系统 msquic.dll，自行完成 QUIC 会话、DoQ/HTTP3 DoH 上游连接；
  4. 代理做协议中转：内网明文 DNS ↔ 上游 QUIC 加密 DNS；
     
    相当于增加一层中间翻译，绕开 dnscache 缺少 QUIC 栈的底层缺陷。

五、补充：DoT / HTTP2 DoH 为什么原生可行对比

  1. DoT：底层基于 TCP，系统 Winsock 原生 TCP 套接字，Schannel TLS 库是系统底层自带，dnscache 可直接调用完成加密隧道；
  2. HTTP/2 DoH：同样 TCP 承载，Windows 内置 HTTP/2 解析器，无需额外 DLL；
  3. DoQ/HTTP3：强制依赖独立 msquic QUIC 库，系统核心 DNS 服务不允许加载该组件，底层无执行逻辑。

六、微软官方设计层面的额外原因

  1. 稳定性优先级：QUIC 相比 TCP 迭代周期短，早年存在较多兼容性、拥塞控制、防火墙适配问题，系统核心解析服务不适合绑定；
  2. 权限与隔离：dnscache 运行在本地服务账户，msquic 存在独立权限沙盒，耦合会提升蓝屏、网络崩溃风险；
  3. 标准化落地节奏：DoQ RFC9250 定稿晚于 Windows DoT/DoH 内置功能开发周期，系统底层代码未预留扩展接口；
  4. 安全管控：企业域环境防火墙、组策略对 QUIC 管控难度更高，微软优先落地可管控的 853 (DoT)、443 (DoH-TCP) 端口方案。

细化拆解核心矛盾：dnscache 无内置 QUIC 栈，导致 Windows 原生不支持 DoQ / HTTP3 DoH

1. 四层承载架构对比，看清本质差异

（1）Windows 原生支持：DoT、HTTP/2 DoH

  • DoT：UDP/TCP 底层套接字 + 系统内置 Schannel TLS（TCP 隧道加密）
  • HTTP/2 DoH：TCP + TLS1.3 + HTTP/2 解析器
     
    二者全部依托 Windows 原生 TCP/UDP 套接字接口，加密、HTTP 解析逻辑硬编码在 dnscache.dll 内部，无需外部依赖库。

（2）DoQ (RFC9250)、HTTP/3 DoH 强制依赖 QUIC

QUIC 完全重构传输层，不复用 TCP 逻辑：
  1. 底层载体是 UDP，但 QUIC 自身实现独立的握手、重传、拥塞控制、多路流、会话加密、0-RTT；
  2. HTTP/3 = HTTP 语义完全跑在 QUIC 流上；
  3. DoQ 直接将 DNS 报文封装至独立 QUIC Stream，全程无 TCP 参与。

2. dnscache.dll 底层代码硬性缺失（核心矛盾）

  1. 无 QUIC 会话管理代码
     
    dnscache 内部仅实现 TCP、UDP 套接字收发逻辑，不存在 QUIC 连接创建、维护、断开的执行分支；注册表、系统策略仅能切换「明文 / DoT/HTTP2-DoH」，没有任何配置项能启用 QUIC。
  2. 无法加载 msquic.dll 作为底层依赖
     
    Windows 虽提供 msquic.dll（系统 QUIC 库，Edge、Chrome 等应用专用），但系统设计约束：
     
    dnscache 属于系统关键基础服务，启动加载依赖被严格限制，禁止绑定 msquic 这类上层应用专用动态库，避免网络栈蓝屏、解析服务崩溃。
  3. 无 QUIC 报文编解码、流封装逻辑
     
    DoQ 需要把 DNS 查询 / 应答塞入 QUIC 独立流，做长度前缀、帧分片、QUIC 层加解密；HTTP/3 DoH 需要在 QUIC 流内解析 HTTP3 请求。
     
    上述全套解析、封装代码在 dnscache 中完全空白，不是配置开关可以开启的功能，属于底层二进制缺失功能。

3. 为什么注册表 / PowerShell 脚本完全无法弥补？

注册表、PowerShell 仅负责策略参数配置：上游 DNS IP、DoT 端口、DoH 模板地址、网卡加密模式。
 
这些配置只是参数入口，真正处理协议的执行逻辑写死在 dnscache.dll 二进制文件内。
  • 有 DoT/HTTP2 DoH 代码 → 填入对应地址就能运行；
  • 完全没有 QUIC/DoQ 处理代码 → 无论怎么改注册表、命令行参数，底层没有对应执行逻辑，不可能发起 QUIC 连接。

4. 两种协议无法原生工作的直观现象

  1. 若把 DNS 服务器填 quic://dns.alidns.com
     
    dnscache 无法识别 quic:// 协议前缀，直接降级使用 53 端口明文 UDP 尝试连接，触发超时。
  2. 若填入 h3:// 类型 DoH 地址
     
    系统 DoH 解析器仅支持 TCP 承载的 HTTP/2，不识别 QUIC 承载 HTTP3，直接解析失败、切换明文 DNS。

5. 唯一可行解决方案原理（本地 DNS 代理）

引入中间代理程序（AdGuardHome、SimpleDnsCrypt、WARP）分层中转：
  1. Windows dnscache → 本地代理 127.0.0.1:53（标准 UDP 明文 DNS，系统原生支持）
  2. 代理程序独立加载 msquic.dll，完整实现 QUIC 协议栈
  3. 代理向外网上游发起 DoQ / HTTP3 DoH QUIC 加密查询
  4. 代理将查询结果以标准明文 DNS 回传给系统 dnscache
     
    本质：用第三方程序补齐 Windows 系统 DNS 组件缺失的 QUIC 能力，绕开 dnscache 底层限制。

 

DNS 地址本身只是服务器的“门牌号”（IP），而 DoH、DoT、DoQ 则是通往这个门牌号的“运输协议”。它们的核心区别在于传输层协议、加密方式、端口及性能特征。
传统的 DNS 使用 UDP/TCP 53 端口明文传输，存在被窃听、篡改和劫持的风险。DoH/DoT/DoQ 均为了解决此问题而生，但技术路线截然不同。以下是深度对比：

📊 核心参数对比表

特性 DoH DoT DoQ 传统 DNS
全称 DNS over HTTPS DNS over TLS DNS over QUIC -
底层协议 HTTP/2 或 HTTP/3 + TLS TCP + TLS QUIC (UDP) UDP / TCP
标准端口 443 853 853 53
流量伪装 ✅ 与网页流量完全一致 ❌ 独立端口，易识别 ❌ 独立端口，但可混淆 ❌ 明文，极易识别
抗丢包/延迟 ⚠️ H2有队头阻塞; H3改善 ❌ TCP队头阻塞严重 ✅ 原生无队头阻塞 ✅ UDP无阻塞(但不可靠)
连接复用 ✅ 支持多路复用 ✅ 支持 ✅ 支持 ❌ 每次查询新建连接
审查抵抗力 ⭐⭐⭐⭐⭐ (最强) ⭐⭐⭐ (中等) ⭐⭐⭐⭐ (较强) ⭐ (无)
客户端支持 浏览器/OS/路由器广泛支持 Android/iOS/部分路由器 较新, 生态快速增长 所有设备
RFC 标准 RFC 8484 / 9230 RFC 7858 RFC 9250 RFC 1035

🔍 三者深度解析

1. DoH：隐私保护的“伪装大师”

  • 原理：将 DNS 查询封装在 HTTPS 请求中，走 443 端口。
  • 核心优势：
    • 极致隐蔽：DNS 流量与普通网页访问（如访问百度）在端口、协议特征上完全相同，网络管理员和运营商无法区分也无法精准屏蔽。
    • 生态最成熟：Chrome/Firefox/Edge/Safari 原生支持，Windows 11/macOS/Linux 系统级集成，AdGuard Home/Pi-hole 等自建方案首选。
  • 劣势：
    • HTTP/2 基于 TCP，存在队头阻塞（一个丢包阻塞整个连接）；HTTP/3 虽解决此问题但普及度仍在提升中。
    • 协议栈较重，内存/CPU 开销略高于 DoT/DoQ。
  • 适用场景：公共 Wi-Fi、审查严格地区、对隐私要求极高的用户、浏览器内置安全 DNS。

2. DoT：移动端的“平衡之选”

  • 原理：在 TCP 之上直接加 TLS 层，专用于 DNS，走 853 端口。
  • 核心优势：
    • 协议轻量：比 DoH 少一层 HTTP 封装，头部开销更小，握手更快。
    • 移动端友好：Android 9+ 原生支持（“私人 DNS”功能即 DoT），iOS 14+ 通过配置文件支持。
    • 易于管控：独立端口使企业/学校可针对性放行或审计，适合需要“加密但可管理”的场景。
  • 劣势：
    • 853 端口特征明显，易被防火墙识别并阻断。
    • TCP 队头阻塞问题在弱网环境下比 DoQ 更显著。
  • 适用场景：手机系统级 DNS、企业内网加密解析、路由器上游 DNS。

3. DoQ：下一代“性能王者”

  • 原理：基于 QUIC 协议（UDP + 内置 TLS + 多路复用），专为低延迟设计。
  • 核心优势：
    • 零队头阻塞：QUIC 的流独立性确保单个丢包不影响其他 DNS 查询，弱网/高延迟环境体验远超 DoT/DoH(H2)。
    • 连接迁移：Wi-Fi ↔ 移动数据切换时无需重新握手，DNS 不中断。
    • 快速握手：0-RTT 或 1-RTT 即可完成加密连接建立，首次查询延迟极低。
  • 劣势：
    • 生态较新，旧设备/旧固件不支持。
    • UDP 在某些严格防火墙下可能被限速或丢弃（但可通过端口伪装缓解）。
  • 适用场景：游戏加速、跨国链路、弱网环境、追求极致响应速度的自建 DNS 服务器（如 AdGuard Home v0.107+、Mosdns、SmartDNS）。

💡 选型决策指南

PixPin_2026-06-03_19-21-16

  • 普通家庭用户：优先 DoH（浏览器+系统双保险），备选 DoT。
  • 手机用户：Android 用 DoT（系统原生），iOS 用 DoH/DoT 配置文件。
  • 自建 DNS 服务器：同时开启 DoH + DoT + DoQ，让客户端自动协商最优协议。
  • 游戏/实时应用：首选 DoQ，次选 DoH(H3)。
  • 企业合规环境：DoT（可审计、可策略控制），避免 DoH 的“影子 IT”风险。

⚠️ 重要提醒

  • 加密 ≠ 匿名：DoH/DoT/DoQ 仅加密“传输过程”，DNS 服务器本身仍能看到你的查询记录。若需真正匿名，需配合 Oblivious DNS 或使用可信无日志服务商。
  • 端口不是绝对：DoH 可运行在非 443 端口，DoQ 也可伪装为 443，但标准端口兼容性最佳。
  • 国内特殊注意：部分公共 DoH/DoT 服务在国内可能不稳定或被干扰，建议使用阿里云、腾讯云、Cloudflare 等经测试可达的服务，或自建中转。
  • 验证生效：配置后务必通过 https://browserleaks.com/dns 或 dig @server doh.example.com 验证是否真正走了加密通道，避免“假加密”。

📌 一句话总结

DoH 是隐私盾牌，DoT 是移动标配，DoQ 是速度利器。 三者并非替代关系，而是互补演进——未来趋势是 DoH(H3) 与 DoQ 融合，兼顾伪装性与性能。当前阶段，根据场景选对协议，比盲目追求“最新”更重要。

 

PixPin_2026-06-03_18-57-35

PixPin_2026-06-03_19-17-01

Windows 10与 11 系统设置中才有

PixPin_2025-10-04_14-11-49

PixPin_2025-10-04_14-11-28

PixPin_2025-10-04_14-10-54

PixPin_2025-09-29_16-32-46

 

# 脚本标题：Windows 阿里公共 DNS DOT DOH一键设置脚本
# 适用系统：Windows 10 / Windows 11
# 服务商：阿里公共 DNS

Write-Host "========================================" -ForegroundColor Cyan
Write-Host "   Windows 系统 DNS 修改脚本 (阿里版)    " -ForegroundColor Yellow
Write-Host "========================================" -ForegroundColor Cyan
Write-Host "注意：请务必在 PowerShell 中以管理员身份运行！`n"

# 1. 获取当前活跃的网络适配器
Write-Host "[步骤 1/3] 正在检测网络适配器..." -ForegroundColor Green
$Adapters = Get-NetAdapter | Where-Object {$_.Status -eq "Up"}

if ($Adapters.Count -eq 0) {
    Write-Host "错误：未找到已连接的网络适配器。" -ForegroundColor Red
    exit
}

# 如果有多个网卡（如同时有有线和无线），默认选择第一个，或者你可以修改索引
$SelectedAdapter = $Adapters | Select-Object -First 1
$AdapterName = $SelectedAdapter.Name
Write-Host "已选择网卡: $AdapterName `n" -ForegroundColor Magenta

# 2. 定义阿里公共 DNS 服务器地址
# IPv4: 223.5.5.5, 223.6.6.6
# IPv6: 2400:3200::1, 2400:3200:baba::1
$DNSServers = "223.5.5.5", "223.6.6.6", "2400:3200::1", "2400:3200:baba::1"

# 3. 执行设置
Write-Host "[步骤 2/3] 正在设置 DNS 地址..." -ForegroundColor Green
try {
    Set-DnsClientServerAddress -InterfaceAlias $AdapterName -ServerAddresses $DNSServers -ErrorAction Stop
    Write-Host " DNS 设置成功！" -ForegroundColor Green
    Write-Host "   主用 DNS (IPv4): 223.5.5.5" -ForegroundColor White
    Write-Host "   备用 DNS (IPv4): 223.6.6.6" -ForegroundColor White
    Write-Host "   IPv6 DNS: 2400:3200::1, 2400:3200:baba::1`n" -ForegroundColor White
} catch {
    Write-Host " 设置失败: $_" -ForegroundColor Red
    Write-Host "请尝试手动在 '网络和共享中心' 中修改。" -ForegroundColor Yellow
    exit
}

# 4. 刷新 DNS 缓存
Write-Host "[步骤 3/3] 正在刷新 DNS 缓存..." -ForegroundColor Green
ipconfig /flushdns
Write-Host "缓存已刷新。`n"

# 5. 高级选项：配置 DNS over HTTPS (DoH)
# 阿里 DoH 地址: https://dns.alidns.com/dns-query
Write-Host "💡 提示：阿里 DNS 支持加密查询 (DoH)。" -ForegroundColor Cyan
$DoHCommand = "Add-DnsClientDohServerAddress -ServerAddress '223.5.5.5' -DohTemplate 'https://dns.alidns.com/dns-query' -AllowFallbackToUdp"
Write-Host "若要开启加密，请在管理员 PowerShell 中运行：" -ForegroundColor Yellow
Write-Host "$DoHCommand `n" -ForegroundColor Magenta

Write-Host "设置完成！网络连接可能需要几秒钟恢复。" -ForegroundColor Green

 

这些 DNS 信息整理成一个清晰的，方便查阅和对比，同时保留国密 SM2 DoH 的信息。如下：

服务商 / 类型 IPv4 地址 IPv6 地址 DoH (DNS over HTTPS) DoH 国密 (SM2) DoT (DNS over TLS)
DNSPod 公共 DNS 119.29.29.29 2402:4e00:: https://doh.pub/dns-query https://sm2.doh.pub/dns-query dot.pub
阿里公共 DNS 223.5.5.5, 223.6.6.6 2400:3200::1, 2400:3200:baba::1 https://dns.alidns.com 不支持 https://dns.alidns.com

这个总结了以下关键点：

  1. 国密 SM2 DoH 是国内首家由 DNSPod 提供，增强了加密安全性。
  2. IPv4 和 IPv6 都有明确列出，便于在不同网络环境下使用。
  3. 支持 DoH/DoT，可在公共 Wi-Fi 或家庭网络环境下提升 DNS 安全性。

在 Windows 11 中，您可以使用 PowerShell 脚本来配置 DNS over HTTPS (DoH)，并设置指定的 IPv4 和 IPv6 地址。以下是一个示例脚本，演示如何启用 DoH，并将 IPv4 地址设置为 119.29.29.29，IPv6 地址设置为 2402:4e00::，同时使用 https://doh.pub/dns-query 作为 DoH 服务器。

示例 PowerShell 脚本

 
powershellCopy
# 检查当前的 DNS 设置
Get-DnsClientServerAddress

# 设置 DoH 服务器地址
$dohServer = "https://doh.pub/dns-query"

# 获取网络适配器
$adapter = Get-DnsClient | Where-Object { $_.InterfaceAlias -eq "以太网" }  # 根据您的网络适配器名称进行调整

# 配置 IPv4 和 IPv6 DNS 服务器地址
Set-DnsClientServerAddress -InterfaceAlias $adapter.InterfaceAlias -ServerAddresses ("119.29.29.29")  # 设置 IPv4 地址
Set-DnsClientServerAddress -InterfaceAlias $adapter.InterfaceAlias -ServerAddresses ("2402:4e00::")  # 设置 IPv6 地址

# 启用 DoH
Set-DnsClient -InterfaceAlias $adapter.InterfaceAlias -DnsOverHttpsEnabled $true

# 设置 DoH 服务器
Set-DnsClient -InterfaceAlias $adapter.InterfaceAlias -DnsOverHttpsServer $dohServer

# 验证 DoH 配置
Get-DnsClient | Where-Object { $_.InterfaceAlias -eq $adapter.InterfaceAlias }

使用说明

  1. 打开 PowerShell：以管理员身份运行 PowerShell。
  2. 复制并粘贴脚本：将上述脚本复制并粘贴到 PowerShell 窗口中。
  3. 调整网络适配器名称：根据您的网络适配器名称（例如“以太网”或“Wi-Fi”）调整 $adapter 变量。
  4. 执行脚本：按 Enter 键执行脚本。

注意事项

  • 确保您的 Windows 11 系统已更新到最新版本，以支持 DoH。
  • 您可以根据需要更改 DNS 服务器地址，脚本中提供的地址仅为示例。
  • 配置完成后，您可以使用 Get-DnsClient 命令来验证 DoH 是否已成功启用。
# 1. 定义变量
$ifName = "WLAN"
$dnsDotIp = "120.53.53.53"
$regRoot = "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache"
$wellPath = "$regRoot\DohWellKnownServers\$dnsDotIp"
$paramPath = "$regRoot\Parameters"

# 2. 开启系统全局DoT支持
if (-not (Test-Path $paramPath)) { New-Item $paramPath -Force | Out-Null }
Set-ItemProperty -Path $paramPath -Name EnableDotTls -Value 1 -Force

# 3. 创建阿里云DoH/DoT注册表节点（解决路径不存在报错）
if (-not (Test-Path $wellPath)) { New-Item $wellPath -Force | Out-Null }
# DoT端口853
Set-ItemProperty -Path $wellPath -Name DotTlsPort -Value 853 -Force
# DoH查询地址
Set-ItemProperty -Path $wellPath -Name DohTemplate -Value "https://120.53.53.53/dns-query" -Force
# 标识可信公共DNS
Set-ItemProperty -Path $wellPath -Name Flags -Value 1 -Force

# 4. 设置网卡DNS为阿里云加密DNS
Set-DnsClientServerAddress -InterfaceAlias $ifName -ServerAddresses $dnsDotIp

# 5. 注册表开启网卡自动DoH（替代不存在的Set-DnsClientDohConfig）
$ifIndex = (Get-NetAdapter -Name $ifName).InterfaceIndex
$ifRegPath = "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\InterfaceSpecificParameters\$ifIndex"
if (-not (Test-Path $ifRegPath)) { New-Item $ifRegPath -Force | Out-Null }
# 0=禁用DoH 1=自动DoH 2=强制仅DoH
Set-ItemProperty -Path $ifRegPath -Name DohMode -Value 1 -Force

# 6. 刷新DNS缓存（不用重启dnscache服务，规避权限报错）
Clear-DnsClientCache

# 7. 查看配置验证
Write-Host "`n=== 当前网卡DNS配置 ===" -ForegroundColor Cyan
Get-DnsClientServerAddress -InterfaceAlias $ifName
Write-Host "`n=== 网卡DoH模式 ===" -ForegroundColor Cyan
Get-ItemProperty $ifRegPath | Select DohMode
Write-Host "`n=== 全局DoT开关 ===" -ForegroundColor Cyan
Get-ItemProperty $paramPath | Select EnableDotTls

DNS (传统DNS)、DoH (DNS over HTTPS) 和 DoT (DNS over TLS) 的发布年代：

协议 发布年代
DNS (传统DNS) 1983年
DoH (DNS over HTTPS) 2018年
DoT (DNS over TLS) 2016年

解释：

  • DNS (传统DNS)：DNS 协议于 1983 年由 Paul Mockapetris 提出，成为互联网域名解析的基础协议。
  • DoH (DNS over HTTPS)：DoH 协议首次由 Mozilla 提出，并于 2018 年被正式采用，它通过 HTTPS 加密 DNS 查询，提升了隐私保护。
  • DoT (DNS over TLS)：DoT 协议于 2016 年提出，使用 TLS 加密 DNS 查询，增强了数据的安全性和隐私保护。

除了 DNS (传统DNS)、DoH (DNS over HTTPS) 和 DoT (DNS over TLS)，近年来还有一些新兴的 DNS 协议和相关标准，主要是为了增强隐私、安全性和性能。以下是几个较新的协议标准：

1. DNS over QUIC (DoQ)

  • 发布年份：2020年（草案阶段）
  • 标准简介：DNS over QUIC（DoQ）是一个基于 QUIC 协议的 DNS 传输协议，QUIC 是 Google 提出的传输协议，旨在替代传统的 TCP 和 TLS。DoQ 旨在提供更低延迟的 DNS 查询，同时利用 QUIC 的加密和性能优化特性。
  • 特点：
    • 提供更低延迟和更高性能，尤其是在网络条件不佳时。
    • 内建加密和身份验证机制，增强隐私保护。
    • 由于 QUIC 的多路复用特性，DoQ 可以减少连接建立的时间，提升响应速度。

2. DNS over HTTPS (DoH) 与 DNS over TLS (DoT) 的扩展标准

  • 发布年份：2021年（草案阶段）
  • 标准简介：随着 DoH 和 DoT 的应用普及，IETF（互联网工程任务组）正在对这些协议进行扩展，以提高其适应性和互操作性。例如，DNS Privacy（隐私保护）标准的改进，进一步加强了 DNS 查询的隐私保护。
  • 特点：
    • 更强的隐私保护措施。
    • 改进的负载均衡和多路径支持，提升可靠性。
    • 针对防火墙穿透的增强功能。

3. DNSSEC (DNS Security Extensions)

  • 发布年份：1999年（初步发布），至今仍在发展
  • 标准简介：DNSSEC 是一组增强传统 DNS 协议安全性的扩展，旨在防止 DNS 欺骗（如 DNS spoofing）和缓存投毒攻击。它通过对 DNS 数据进行数字签名，确保数据的完整性和来源的可靠性。
  • 特点：
    • 通过数字签名验证 DNS 响应的完整性，防止篡改。
    • 增强了对 DNS 请求结果的验证，确保结果来自可信的源。
    • 尽管 DNSSEC 增加了 DNS 查询的安全性，但其并未加密传输内容，仍然无法防止隐私泄露。

4. EDNS(0) (Extension Mechanisms for DNS)

  • 发布年份：1999年（初步发布）
  • 标准简介：EDNS(0) 是 DNS 协议的扩展机制，允许 DNS 协议支持更多的功能和更大的数据包尺寸。EDNS(0) 通过支持更大的 DNS 数据包，提高了 DNS 查询的性能和可扩展性。
  • 特点：
    • 增强了 DNS 协议的灵活性，支持更大数据包传输（例如 512 字节以上的响应）。
    • 为 DNSSEC 等扩展提供了支持，增强了协议的安全性。
  • DoQ (DNS over QUIC) 是目前比较新的协议，它利用 QUIC 协议的优势，目标是提供更低延迟和更高性能的 DNS 服务。
  • DNSSEC 和 EDNS(0) 是传统 DNS 协议的扩展，分别侧重于提升 DNS 的安全性和扩展性。
  • IETF 也在持续改进 DoH 和 DoT，提高其隐私性、可靠性和性能。

这些新的协议和扩展标准主要是在 隐私、安全性 和 性能 等方面进行改进，以应对现代网络环境中的挑战。

DNS、DoH 和 DoT 之间区别的：

特性 DNS (传统DNS) DoH (DNS over HTTPS) DoT (DNS over TLS)
协议类型 明文传输（UDP/TCP） 使用 HTTPS（基于 HTTP/2） 使用 TLS（基于 TCP）
加密 无 是（加密传输） 是（加密传输）
端口 53（UDP/TCP） 443（HTTPS） 853（TLS）
隐私保护 不保护隐私（流量明文传输，易被监听） 提供更好的隐私保护（加密，防止流量监听） 提供隐私保护（加密，防止流量监听）
性能 快速，但容易受到中间人攻击和篡改 可能稍慢（因为需要建立 HTTPS 连接） 与传统 DNS 比较，稍慢（需要建立 TLS 连接）
用途 传统 DNS 查询（广泛应用于各类网络） 用于保护 DNS 查询，防止第三方窃听和篡改 用于保护 DNS 查询，防止第三方窃听和篡改
配置复杂度 简单（默认配置即可使用） 需要配置 HTTPS 代理或浏览器支持 需要配置支持 TLS 的 DNS 服务器和客户端
安全性 低（数据可以被截获或篡改） 高（加密保护，避免中间人攻击） 高（加密保护，避免中间人攻击）

 

  • 传统 DNS 是最常见的 DNS 查询方式，但没有加密，存在隐私和安全风险。
  • DoH 和 DoT 都通过加密协议（HTTPS 和 TLS）来保护 DNS 查询的隐私，但 DoH 使用 HTTPS 端口 443，而 DoT 使用 TLS 端口 853。
  • DoH 更常用于 Web 浏览器中，尤其是在隐私保护要求较高时；而 DoT 通常用于整体网络中，尤其是在企业环境中。

DNS (传统DNS)、DoH (DNS over HTTPS) 和 DoT (DNS over TLS) 的定义、概念、功能、作用和应用场景的详细对比：

特性 DNS (传统DNS) DoH (DNS over HTTPS) DoT (DNS over TLS)
定义 是一种基于 UDP 或 TCP 的域名解析系统，通过明文传输将域名解析为 IP 地址。 在 HTTPS 协议下进行 DNS 查询，使用加密保护数据传输。 通过加密的 TLS 协议传输 DNS 查询，提供加密保护。
概念 将域名映射到 IP 地址的传统方式，通过端口 53 传输 DNS 数据。 使用 HTTPS 作为加密通道，确保 DNS 查询内容在传输过程中不被监听。 使用 TLS 协议加密 DNS 查询，保护数据不被中间人攻击。
功能 提供域名到 IP 地址的转换服务。 提供加密的 DNS 查询，防止数据被窃听或篡改。 提供加密的 DNS 查询，防止数据被窃听或篡改，增加隐私保护。
作用 实现域名解析，保障用户访问网站时将域名解析为正确的 IP 地址。 保护 DNS 查询隐私，防止 ISP 或其他中间人监控用户活动。 保护 DNS 查询隐私，防止 ISP 或其他中间人监控用户活动，确保网络安全。
应用场景 广泛应用于传统的网络设备、路由器和 DNS 服务器中，适用于所有需要域名解析的场景。 适用于对隐私要求较高的用户，特别是在使用公共 Wi-Fi 或不信任的网络环境下的设备。 常见于企业环境和对隐私要求较高的个人用户，特别是在需要确保 DNS 查询安全的网络中。

详细说明：

  1. 传统 DNS：

    • 定义与概念：DNS 是一种用于将域名解析为 IP 地址的系统，通常通过端口 53 进行通信。它的主要目的是帮助用户通过人类易记的域名（如 www.example.com）访问网站。
    • 功能与作用：DNS 提供了将用户请求的域名转换为 IP 地址的功能，用户在浏览器中输入域名时，DNS 服务器会将其转换为计算机可理解的 IP 地址。
    • 应用场景：广泛应用于所有类型的网络连接，无论是家庭网络还是企业网络，都是互联网基础设施的重要组成部分。

  2. DoH (DNS over HTTPS)：

    • 定义与概念：DoH 是 DNS over HTTPS 的缩写，它通过 HTTPS 协议对 DNS 查询进行加密，使用端口 443 进行通信。这意味着 DNS 查询将通过 HTTPS 通道加密，增加了安全性和隐私保护。
    • 功能与作用：DoH 的主要功能是加密 DNS 查询，防止第三方监听和篡改 DNS 请求。它的作用是保护用户的隐私，尤其是在不安全的网络环境下（如公共 Wi-Fi 网络）避免用户的 DNS 查询被监控。
    • 应用场景：适用于对隐私有较高要求的场景，特别是在公共 Wi-Fi 网络或不信任的网络环境下使用智能手机、浏览器等设备时。DoH 在许多现代浏览器中得到了支持，如 Chrome 和 Firefox。

  3. DoT (DNS over TLS)：

    • 定义与概念：DoT 是 DNS over TLS 的缩写，它使用加密的 TLS 协议来保护 DNS 查询的隐私。与 DoH 类似，DoT 也通过加密隧道保护 DNS 数据传输，但是它与 HTTPS 不同，使用的是专门的 DNS 端口 853。
    • 功能与作用：DoT 的功能与 DoH 类似，都是为了加密 DNS 查询，防止数据被中间人监听或篡改。其作用是提供更高的安全性，确保用户的 DNS 查询不被窃听或篡改。
    • 应用场景：DoT 常用于企业环境以及对隐私要求较高的用户，尤其是需要确保 DNS 查询安全的网络中。它可以与 VPN 或企业网络中的 DNS 服务器一起使用，提供安全的 DNS 查询。

 

  • DNS (传统 DNS)：提供基础的域名解析功能，但没有隐私保护。
  • DoH：通过 HTTPS 协议加密 DNS 查询，防止监听，提升隐私保护，常用于浏览器和个人设备。
  • DoT：通过 TLS 协议加密 DNS 查询，提供隐私保护，通常用于企业环境和对 DNS 安全性要求较高的用户。

在评估 DNS (传统DNS)、DoH (DNS over HTTPS) 和 DoT (DNS over TLS) 的安全性时，必须考虑其可能的漏洞和每种协议的弱点。以下是对这些协议的漏洞级别的比较：

协议 漏洞类型与风险 漏洞级别
DNS (传统DNS) 1. DNS Spoofing（缓存投毒）：攻击者伪造 DNS 响应，欺骗用户访问恶意网站。 2. DNS Reflection Attack（DNS反射攻击）：通过伪造源地址发起大规模的 DDoS 攻击。 3. DNS Query Interception（DNS查询劫持）：恶意中间人可以拦截并篡改 DNS 查询。 高
DoH (DNS over HTTPS) 1. HTTPS 中间人攻击：如果 HTTPS 证书管理不当，攻击者可能利用中间人攻击（MITM）拦截和篡改 DNS 查询。 2. DDoS 攻击：使用 DoH 服务可能暴露在针对 HTTPS 端口的 DDoS 攻击中。 3. 隐私泄露：如果 DoH 服务提供商收集查询数据，可能导致用户隐私泄露。 中等（依赖服务端的信任性）
DoT (DNS over TLS) 1. TLS 弱点：如果 TLS 配置不当或使用弱加密算法，攻击者可以利用漏洞进行攻击。 2. DDoS 攻击：DoT 也可能成为 DDoS 攻击的目标，尤其是针对 TLS 的攻击。 3. 不受信任的 DNS 服务器：如果 DoT 服务端未经过认证或被篡改，可能导致数据泄露或中间人攻击。 中等（依赖TLS实现的安全性）

详细解释：

  1. 传统 DNS：

    • 漏洞：传统 DNS 协议在设计时并没有加密，因此存在诸多漏洞。最常见的漏洞包括：
      • DNS Spoofing（缓存投毒）：攻击者通过伪造 DNS 响应，将恶意 IP 地址返回给受害者，导致用户访问恶意网站。
      • DNS反射攻击：攻击者伪造源地址，利用公开的 DNS 服务器发起大规模的 DDoS 攻击。
      • 查询劫持：恶意的中间人可以通过拦截 DNS 查询，修改查询结果，导致用户访问不安全的资源。
    • 漏洞级别：这些漏洞非常严重，因为传统 DNS 没有加密保护，容易受到各种攻击。

  2. DoH (DNS over HTTPS)：

    • 漏洞：DoH 提供了加密保护，但也引入了一些潜在的风险：
      • HTTPS 中间人攻击：尽管 DoH 使用 HTTPS 加密，但如果 HTTPS 配置不当（如 SSL/TLS 证书问题），可能会受到中间人攻击。
      • DDoS 攻击：由于 DoH 使用 HTTPS，攻击者可以将 DDoS 攻击定向到 DoH 服务的端口（通常是 443 端口），从而影响服务的可用性。
      • 隐私泄露：如果 DoH 服务提供商收集用户的 DNS 查询数据，可能会泄露用户的网络行为，尤其是在未对查询内容进行匿名化的情况下。
    • 漏洞级别：虽然 DoH 提供了更好的隐私保护，但仍然存在依赖服务提供商和 HTTPS 配置的潜在风险，漏洞级别相对较中等。

  3. DoT (DNS over TLS)：

    • 漏洞：DoT 也通过 TLS 加密传输 DNS 查询，但它同样面临一些潜在的安全问题：
      • TLS 配置弱点：如果使用不安全的 TLS 配置（例如弱加密算法、过期证书等），攻击者可能会利用 TLS 的漏洞对数据进行篡改或窃听。
      • DDoS 攻击：DoT 也会成为 DDoS 攻击的目标，尤其是当攻击者集中攻击 TLS 端口时（通常是 853 端口）。
      • 不受信任的 DNS 服务器：如果 DoT 服务端未经过认证或遭到篡改，可能导致用户数据泄露或中间人攻击。
    • 漏洞级别：DoT 提供了加密保护，相比传统 DNS 安全性更高，但其安全性依赖于 TLS 配置和服务端的信任性，漏洞级别较中等。

 

  • 传统 DNS 的漏洞级别较高，易受到缓存投毒、DNS 劫持和 DDoS 攻击的威胁。
  • DoH 和 DoT 通过加密提高了安全性，减少了数据泄露和劫持的风险，但也依赖于正确的配置和信任的 DNS 服务提供商，漏洞级别相对中等。

整体来看，DoH 和 DoT 提供了较高的隐私保护和安全性，尤其是在防止中间人攻击和数据篡改方面。但它们仍然可能面临服务端问题、DDoS 攻击等威胁。

创建了支持DNS over HTTPS的PowerShell和CMD脚本：

PowerShell 脚本（支持DoH）

powershell
# 以管理员身份运行此脚本
# WiFi静态IP配置脚本（支持DNS over HTTPS）

# 设置网络参数
$IPAddress = "192.168.1.211"
$SubnetMask = "255.255.255.0"
$DefaultGateway = "192.168.1.1"
$DNS1 = "119.29.29.29"
$DohTemplate = "https://sm2.doh.pub/dns-query"

Write-Host "=== WiFi网络配置脚本 (支持DoH) ===" -ForegroundColor Cyan

# 获取WiFi接口
Write-Host "正在查找WiFi网络接口..." -ForegroundColor Yellow
$WiFiInterface = Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Wireless*" -or $_.Name -like "Wi-Fi*"}

if ($WiFiInterface) {
    $InterfaceIndex = $WiFiInterface.InterfaceIndex
    $InterfaceName = $WiFiInterface.Name
    $InterfaceAlias = $WiFiInterface.InterfaceAlias
    Write-Host "找到WiFi接口: $InterfaceName (索引: $InterfaceIndex)" -ForegroundColor Green
    
    # 设置静态IP地址
    Write-Host "设置静态IP地址..." -ForegroundColor Yellow
    try {
        Remove-NetIPAddress -InterfaceIndex $InterfaceIndex -Confirm:$false -ErrorAction SilentlyContinue
        New-NetIPAddress -InterfaceIndex $InterfaceIndex -IPAddress $IPAddress -PrefixLength 24 -DefaultGateway $DefaultGateway
        Write-Host "✓ IP地址设置成功" -ForegroundColor Green
    } catch {
        Write-Host "✗ IP地址设置失败: $_" -ForegroundColor Red
    }
    
    # 设置DNS服务器
    Write-Host "设置DNS服务器..." -ForegroundColor Yellow
    try {
        Set-DnsClientServerAddress -InterfaceIndex $InterfaceIndex -ServerAddresses @($DNS1)
        Write-Host "✓ DNS服务器设置成功" -ForegroundColor Green
    } catch {
        Write-Host "✗ DNS服务器设置失败: $_" -ForegroundColor Red
    }
    
    # 设置DNS over HTTPS
    Write-Host "配置DNS over HTTPS..." -ForegroundColor Yellow
    try {
        # 检查是否支持DoH命令
        if (Get-Command Set-DnsClientDohServerAddress -ErrorAction SilentlyContinue) {
            # 移除现有的DoH设置
            Remove-DnsClientDohServerAddress -ServerAddress $DNS1 -Confirm:$false -ErrorAction SilentlyContinue
            
            # 添加DoH设置
            Add-DnsClientDohServerAddress -ServerAddress $DNS1 -DohTemplate $DohTemplate -AllowFallbackToUdp $false -AutoUpgrade $true
            Write-Host "✓ DNS over HTTPS 设置成功" -ForegroundColor Green
        } else {
            Write-Host "! 系统不支持DoH命令，请使用Windows 10 20121或更高版本" -ForegroundColor Yellow
        }
    } catch {
        Write-Host "✗ DNS over HTTPS 设置失败: $_" -ForegroundColor Red
    }
    
    # 显示配置结果
    Write-Host "`n=== 网络配置完成 ===" -ForegroundColor Cyan
    Write-Host "IP地址: $IPAddress" -ForegroundColor White
    Write-Host "子网掩码: $SubnetMask" -ForegroundColor White
    Write-Host "网关: $DefaultGateway" -ForegroundColor White
    Write-Host "DNS服务器: $DNS1" -ForegroundColor White
    Write-Host "DoH模板: $DohTemplate" -ForegroundColor White
    
    # 显示当前网络配置
    Write-Host "`n=== 当前网络配置 ===" -ForegroundColor Yellow
    Get-NetIPAddress -InterfaceIndex $InterfaceIndex | Where-Object {$_.AddressFamily -eq "IPv4"} | Format-Table -AutoSize
    Get-DnsClientServerAddress -InterfaceIndex $InterfaceIndex | Format-Table -AutoSize
    
    # 显示DoH配置
    Write-Host "=== DoH配置 ===" -ForegroundColor Yellow
    if (Get-Command Get-DnsClientDohServerAddress -ErrorAction SilentlyContinue) {
        Get-DnsClientDohServerAddress | Format-Table -AutoSize
    }
    
} else {
    Write-Host "未找到WiFi网络接口！" -ForegroundColor Red
}

Write-Host "`n按任意键退出..." -ForegroundColor Gray
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

CMD 批处理脚本

batch
@echo off
chcp 65001 >nul
setlocal enabledelayedexpansion

:: 以管理员身份运行检查
net session >nul 2>&1
if %errorLevel% neq 0 (
    echo 请求管理员权限...
    powershell -Command "Start-Process cmd -ArgumentList '/c %~f0' -Verb RunAs"
    exit /b
)

:: 设置网络参数
set IP_ADDRESS=192.168.1.211
set SUBNET_MASK=255.255.255.0
set GATEWAY=192.168.1.1
set DNS1=119.29.29.29
set DOH_TEMPLATE=https://sm2.doh.pub/dns-query

echo ===============================
echo    WiFi网络配置脚本
echo     支持DNS over HTTPS
echo ===============================
echo.

:: 查找WiFi接口名称
set "WIFI_ADAPTER="
for /f "tokens=1,2,* delims=:" %%i in ('netsh interface show interface ^| findstr /i "无线 Wi-Fi Wireless"') do (
    set "line=%%i%%j%%k"
    set "line=!line: =!"
    for /f "tokens=1 delims=" %%a in ("!line!") do set "WIFI_ADAPTER=%%a"
)

if "!WIFI_ADAPTER!"=="" (
    echo 错误: 未找到WiFi网络适配器！
    pause
    exit /b 1
)

echo 找到WiFi适配器: !WIFI_ADAPTER!
echo.

:: 设置静态IP
echo [1/3] 设置静态IP地址...
netsh interface ip set address name="!WIFI_ADAPTER!" static !IP_ADDRESS! !SUBNET_MASK! !GATEWAY! 1
if !errorLevel! equ 0 (
    echo ✓ IP地址设置成功
) else (
    echo ✗ IP地址设置失败
)

:: 设置DNS服务器
echo.
echo [2/3] 设置DNS服务器...
netsh interface ip set dns name="!WIFI_ADAPTER!" static !DNS1! primary validate=no
if !errorLevel! equ 0 (
    echo ✓ DNS服务器设置成功
) else (
    echo ✗ DNS服务器设置失败
)

:: 设置DNS over HTTPS (使用PowerShell)
echo.
echo [3/3] 配置DNS over HTTPS...
powershell -Command "try { if (Get-Command Set-DnsClientDohServerAddress -ErrorAction SilentlyContinue) { Remove-DnsClientDohServerAddress -ServerAddress '%DNS1%' -Confirm:`$false -ErrorAction SilentlyContinue; Add-DnsClientDohServerAddress -ServerAddress '%DNS1%' -DohTemplate '%DOH_TEMPLATE%' -AllowFallbackToUdp `$false -AutoUpgrade `$true; Write-Host '✓ DNS over HTTPS 设置成功' -ForegroundColor Green } else { Write-Host '! 系统不支持DoH，请使用Windows 10 20121或更高版本' -ForegroundColor Yellow } } catch { Write-Host '✗ DoH设置失败: ' `$_.Exception.Message -ForegroundColor Red }"

echo.
echo ===============================
echo       配置完成
echo ===============================
echo IP地址:      !IP_ADDRESS!
echo 子网掩码:    !SUBNET_MASK!
echo 网关:        !GATEWAY!
echo DNS服务器:   !DNS1!
echo DoH模板:     !DOH_TEMPLATE!
echo ===============================
echo.

:: 显示当前配置
echo 当前网络配置:
ipconfig /all | findstr /i /c:"!WIFI_ADAPTER!"

echo.
echo 按任意键退出...
pause >nul

额外功能：网络重置脚本

powershell
# 网络重置脚本（恢复DHCP）
Write-Host "网络重置脚本 - 恢复DHCP" -ForegroundColor Cyan

$WiFiInterface = Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Wireless*" -or $_.Name -like "Wi-Fi*"}

if ($WiFiInterface) {
    $InterfaceIndex = $WiFiInterface.InterfaceIndex
    $InterfaceName = $WiFiInterface.Name
    
    # 恢复DHCP
    netsh interface ip set address name="$InterfaceName" source=dhcp
    netsh interface ip set dns name="$InterfaceName" source=dhcp
    
    # 移除DoH设置
    if (Get-Command Remove-DnsClientDohServerAddress -ErrorAction SilentlyContinue) {
        Remove-DnsClientDohServerAddress -ServerAddress "119.29.29.29" -Confirm:$false
    }
    
    Write-Host "✓ 已恢复DHCP设置" -ForegroundColor Green
}

使用说明：

  1. PowerShell 脚本：

    • 完整支持DoH配置

    • 需要Windows 10 20121或更高版本

    • 以管理员身份运行

  2. CMD 脚本：

    • 基础网络配置

    • 通过PowerShell命令配置DoH

    • 兼容性更好

  3. 系统要求：

    • Windows 10 20121或更高版本完整支持DoH

    • 早期版本可能不支持DoH功能

选择PowerShell脚本以获得完整的DoH支持，或使用CMD脚本作为备选方案。

深入了解 DOH（DNS over HTTPS） 并系统学习它，以下是一些关键问题，涵盖了基础概念、工作原理、安全性、配置与应用等方面，帮助你全面掌握 DOH。

基础概念与原理

  1. 什么是 DOH（DNS over HTTPS）？
  2. DOH 与传统的 DNS（域名系统）有什么区别？
  3. DOH 是如何工作的？
  4. DOH 与 DNS over TLS（DoT）的主要区别是什么？
  5. 为什么需要 DOH？它能解决哪些问题？
  6. DOH 采用的加密协议是什么？
  7. DOH 相比传统 DNS 请求有何安全优势？
  8. 如何理解 DNS 查询的隐私问题，DOH 如何解决这些问题？
  9. DOH 如何保护用户免受 DNS 劫持和中间人攻击（MITM）？
  10. DOH 与 VPN 的隐私保护有何异同？

配置与部署

  1. 如何在浏览器中启用 DOH？（例如，Chrome、Firefox、Edge）
  2. 如何为本地 DNS 服务器配置 DOH？
  3. 如何选择一个 DOH 服务器提供商，是否可以自建 DOH 服务器？
  4. 如何在操作系统中配置 DOH？（例如，Windows、macOS、Linux）
  5. DOH 是否支持自定义 DNS 服务器？如何配置？
  6. 如何通过 Docker 容器部署 DOH 服务？
  7. 如何在移动设备（如 Android 和 iOS）上配置 DOH？

性能与优化

  1. DOH 对网络性能的影响如何？会增加延迟吗？
  2. 如何测试和优化 DOH 的查询速度？
  3. DOH 与传统 DNS 的性能对比如何？
  4. 如何衡量 DOH 服务器的可用性和稳定性？
  5. 在大规模网络环境下，如何优化 DOH 的部署？

安全性与隐私

  1. DOH 如何保护用户的隐私？与传统 DNS 有何不同？
  2. DOH 能否防止 DNS 伪造、DNS 缓存投毒攻击？
  3. DOH 的加密机制如何增强数据的安全性？
  4. 如何保证 DOH 服务器本身的安全性，防止被攻击？
  5. 使用 DOH 的时候，是否存在潜在的安全风险或漏洞？
  6. DOH 是否能有效防止政府或 ISP 的 DNS 攻击或监控？

常见应用与案例

  1. DOH 在企业网络中的应用场景是什么？
  2. DOH 在跨境网络环境中的应用有何优势？
  3. DOH 如何与其他隐私保护技术（如 DNSSEC、HTTPS）配合使用？
  4. DOH 在公共 Wi-Fi 网络中的应用如何提高安全性？
  5. DOH 如何支持智能家居设备和物联网设备的隐私保护？

流行的 DOH 服务提供商

  1. 哪些 DOH 服务提供商值得信任？（如 Google、Cloudflare、Quad9）
  2. 如何评估不同 DOH 服务提供商的隐私政策？
  3. 是否可以自建 DOH 服务，如何操作？
  4. 如何选择合适的 DOH 服务器？
  5. 如何检查 DOH 服务器的正常工作和响应速度？

发展与趋势

  1. DOH 的未来发展趋势是什么？
  2. DOH 是否能够取代传统的 DNS 协议？
  3. 哪些浏览器和操作系统已经默认支持 DOH？
  4. 在未来几年，DOH 是否会成为互联网隐私保护的标准？
  5. DOH 在全球范围内的普及情况如何？是否会被广泛采用？
  6. 如何通过技术标准（如 IETF）推动 DOH 的进一步普及？

故障排除与问题解决

  1. DOH 查询失败时如何排查问题？
  2. 如何检查 DOH 是否工作正常？
  3. 如何处理 DOH 配置时的常见错误和问题？
  4. 如何通过日志和诊断工具调试 DOH 服务？
  5. 如何恢复或切换 DOH 服务器以解决故障？

通过这些问题，你可以全面了解 DOH 的工作原理、如何配置和应用它，如何确保其安全性，并深入探讨其未来发展。希望这些问题能够帮助你构建系统的知识体系，并在实践中熟练掌握 DOH。

Windows DNS 配套链命令完整分类清单（客户端 + DNS 服务器，运维  / 排错）

底层配套链：DNS Client服务(Dnscache) → hosts 文件 → 本地 DNS 缓存 → 网卡 DNS 服务器 → DoH/DoT → 远端 DNS 服务器；下面命令覆盖整条链路。

分为 5 大类：CMD 基础客户端工具、Netsh DNSClient、PowerShell DnsClient 模块、DNS 服务器管理工具、辅助配套诊断命令。

一、CMD 原生 DNS 客户端命令（所有 Windows 自带，无需安装）

命令 功能说明 常用示例  
ipconfig /all 查看网卡 DNS 服务器、DNS 后缀 `ipconfig /all findstr DNS`
ipconfig /displaydns 查看本机 Dnscache 缓存（hosts 解析结果也会进缓存） 查看本地缓存所有域名记录  
ipconfig /flushdns 清空 Dnscache 本地 DNS 缓存（管理员权限） 排错最常用；可用来抹除本地解析缓存痕迹  
ipconfig /registerdns 向 DNS 服务器动态注册本机 A 记录（AD 域环境） 域内主机更新 DNS 注册  
nslookup DNS 查询工具，直接向 DNS 服务器发 UDP53 查询，绕过本机 Dnscache 缓存 nslookup baidu.com nslookup baidu.com 223.5.5.5 指定 DNS 服务器查询nslookup -type=MX baidu.com 查询 MX 记录  

重点区分：nslookup 不走系统 Dnscache；而浏览器、bitsadmin、Invoke-WebRequest 默认走Dnscache缓存。

二、netsh dnsclient（网卡 DNS/DoH/DoT 配置，Win10 2004+/Win11）

netsh dnsclient 专门管理本机 DNS 客户端，支持 DoH (DNS over HTTPS)、DoT (DNS over TLS)

命令 说明
netsh dnsclient show global 查看全局 DNS 客户端设置（DoH/DoT 全局开关）
netsh dnsclient show state 查看当前 DNS 客户端运行状态
netsh dnsclient show encryption 查看已配置的 DoH/DoT 加密 DNS
netsh dnsclient add dnsserver 给网卡添加 DNS 服务器 IP
netsh dnsclient delete dnsserver 删除网卡上的 DNS 服务器
netsh dnsclient add encryption 添加 DoH 模板、配置加密 DNS
netsh dnsclient dump 导出全部 dnsclient 配置脚本

示例：

netsh dnsclient add dnsserver name="以太网" address=223.5.5.5 index=1

三、PowerShell DnsClient 模块（现代推荐，Win10/Server2016+，面向 DNS 客户端）

DnsClient 模块（Windows 自带 PowerShell DNS 客户端模块）

Cmdlet 功能 等效 CMD
Get-DnsClient 获取网卡 DNS 客户端配置（网卡、搜索域） ipconfig /all
Get-DnsClientServerAddress 获取网卡配置的 DNS 服务器 IP 列表 ipconfig /all
Set-DnsClientServerAddress 设置网卡 DNS 服务器地址 netsh dnsclient add dnsserver
Add-DnsClientServerAddress 追加 DNS 服务器 —
Remove-DnsClientServerAddress 删除网卡 DNS 服务器 netsh dnsclient delete
Get-DnsClientCache 读取本机 DNS 缓存 ipconfig /displaydns
Clear-DnsClientCache 清空 DNS 缓存 ipconfig /flushdns
Register-DnsClient 动态注册本机主机记录 ipconfig /registerdns
Resolve-DnsName DNS 域名解析查询（推荐替代 nslookup） nslookup
Test-DnsServer 测试远端 DNS 服务器是否正常工作 -

常用示例（配套）

# 查看网卡DNS配置
Get-DnsClient
# 查看网卡DNS服务器地址
Get-DnsClientServerAddress
# 查看本地DNS缓存
Get-DnsClientCache
# 清空DNS缓存
Clear-DnsClientCache
# 域名解析查询
Resolve-DnsName baidu.com -Type A
# 指定DNS服务器查询
Resolve-DnsName baidu.com -Server 223.5.5.5
# 测试DNS服务器连通性
Test-DnsServer -IPAddress 223.5.5.5

Resolve-DnsName 高频示例：

# A记录查询
Resolve-DnsName baidu.com -Type A
# 指定DNS服务器查询
Resolve-DnsName baidu.com -Server 223.5.5.5
# 仅查本地缓存，不访问网络
Resolve-DnsName baidu.com -CacheOnly
# 不读取hosts文件
Resolve-DnsName baidu.com -NoHostsFile

四、DNS 服务器管理工具（仅 Windows Server，安装 DNS 角色 / RSAT 工具，管理 DNS 服务端，不是客户端）

4.1 dnscmd.exe（CMD，旧版 DNS 服务器管理工具）

用于管理 Windows Server DNS 服务，工作站默认不带

dnscmd /clearcache          # 清空DNS服务器端缓存（不是本机客户端缓存！）
dnscmd /enumzones           # 列出所有DNS区域
dnscmd /recordadd           # 添加A/CNAME/MX记录
dnscmd /recorddelete        # 删除资源记录
dnscmd /zoneprint           # 导出区域所有记录
dnscmd /statistics          # 获取DNS服务器统计
dnscmd /resetforwarders     # 重置转发器

4.2 PowerShell DnsServer 模块（RSAT，管理 DNS 服务器）

模块名：DnsServer，安装 RSAT-DNS-Server 才可用，管理 DNS 服务端区域、记录、转发器、策略

Cmdlet 作用
Add-DnsServerPrimaryZone 创建主 DNS 区域
Add-DnsServerResourceRecordA 添加 A 记录
Remove-DnsServerResourceRecord 删除 DNS 资源记录
Add-DnsServerForwarder 添加 DNS 转发器
Get-DnsServerStatistics 获取 DNS 服务器查询统计
Get-DnsServerZone 列出 DNS 区域

五、配套辅助诊断命令（DNS 链路上下游辅助工具，排查连通 / 解析链路）

命令 用途（DNS 链路配套）
ping 测试域名解析 + 连通性；ping 会走系统 Dnscache 缓存
tracert / traceroute 路由追踪，判断 DNS 解析后 IP 链路是否可达
Test-Connection PowerShell 版 ping，可输出 IP，依赖系统 DNS 解析
netstat / tcpview 查看 UDP53 出站连接，定位 DNS 流量
Get-NetUDPEndpoint PowerShell 查看 UDP53 端口连接
nbtstat NetBIOS 名称解析（旧名称解析，和 DNS 并行）
Get-WinEvent 读取 DNS Client 事件日志（事件 ID：1014 DNS 解析失败）

补充：hosts文件路径：C:\Windows\System32\drivers\etc\hosts，优先级高于 DNS 查询，Dnscache 会缓存 hosts 解析结果。

视角重点要点（配套前面 BITS 知识）

  1. bitsadmin、Invoke-WebRequest、curl.exe 默认使用 Dnscache 本地 DNS 缓存，不是直接 UDP53 查询；
    • 想绕过本机 Dnscache 做域名解析，用Resolve-DnsName -NoHostsFile 或 nslookup。
  2. 常用：Clear-DnsClientCache / ipconfig /flushdns 清理本地解析痕迹。
  3. 持久化：修改hosts文件，优先级高于 DNS 服务器，可劫持域名解析。
  4. DoH 配置：netsh dnsclient可以修改系统加密 DNS，劫持系统 DNS 解析链路。
  5. 日志取证：Get-DnsClientCache可导出目标主机全部本地 DNS 访问记录；事件日志 1014 记录 DNS 解析失败。

链路顺序（完整解析栈，理解命令调用关系）

应用程序(BITS/浏览器) → Dnscache客户端缓存 → hosts文件 → 网卡配置DNS服务器 → UDP53/DoH/DoT → 远端DNS服务器

 

posted @ 2025-03-22 22:46  suv789  阅读(2305)  评论(0)    收藏  举报