阿里云公共 DoH/DoT 的一个坑

[adoyle-h]

问题描述

我对网络安全有一定的要求，于是用 AdGuard Home（以下简称 AGH） 自建的家用 DNS 服务器。并把上游服务器指向到公共的 DNS DoT/DoH 服务。

但是今天我发现，在用 nslookup 查询时发现 Got recursion not available from 192.168.1.61, trying next server 报错。（我这的 AGH 的 IP 是 192.168.1.61）。它没有用我自建的 DNS 服务，而是用了下一个 nameserver（这里是我设置的 1.1.1.1，我在 DHCP 里设置了两个 nameserver）。
用 nslookup 或者 dig 都会遇到 recursion not available 的问题。

查询 AGH 的日志，该域名是正常解析的，并没有报错。

当客户端只有一个 nameserver 时，报错是这样的：

> nslookup baidu.com
Server:         192.168.1.61
Address:        192.168.1.61#53

** server can't find baidu.com: SERVFAIL

问题定位

起初我以为是 AGH 的问题，经过一番折腾，我定位到是 AGH 的上游 DNS 服务器的问题。
实测当 upstream dns 设置成阿里云的 DoT tls://223.5.5.5 或者 DoH https://223.5.5.5/dns-query，都会报 recursion not available 的问题。
当使用 cloudflare 的 DoT tls://1.1.1.1，腾讯的 DoT tls://1.12.12.12 以及 DoH https://1.12.12.12/dns-query，nslookup 都不会有问题。
我也测试了阿里云公共 DNS 223.5.5.5，nslookup 没有问题。只有它的公共 DoH/DoT 有问题！

原因分析

直接用 dig 命令请求阿里云的 DoT dig @223.5.5.5 +tls baidu.com，以及请求 DoH dig @223.5.5.5 +https baidu.com

对比请求腾讯的 DoT/DoH。

会发现阿里云的 DNS 响应 Flag 是 flags: qr rd;，腾讯的 DNS 响应 Flag 是 flags: qr rd ra;，多了一个 ra。
这个 ra 的意思是 Recursion Available。详见 RFC 定义。
这就说明阿里云的 DoT/DoH 不是 recursive dns。啥是 recursive dns？请看这篇与这篇文章。

dig 223.5.5.5 baidu.com 显示的是 flags: qr rd ra;，符合预期。

顺便一提，这篇文章写得不错，讨论了权威 DNS 与递归 DNS 在 ISP 层面的架构考量。

查看 man nslookup 文档发现，nslookup 默认查的是 recursive dns，DNS 请求会把 RD 位（Recursion Desired）设为 1。如果不想要这样，可以这么写 nslookup -norecurse baidu.com， 就不会有那个 warning，也不会跳过不支持 ra 的 DNS 服务了。

延伸问题

于是我又有问题了，

1. 为什么 nslookup 默认要求 DNS 响应必须是 recursive 的？如果 nslookup 去请求权威 DNS，那不也会被跳过吗？
2. 浏览器，以及其他 DNS 解析库，对于不支持 ra 的 DNS 响应是怎么处理的？也像 nslookup 会跳过吗？

我粗略一搜没搜到答案。见多识广的朋友可以说下。

看了 nslookup 的源码（nslookup 是 bind 项目的一部分）， c-ares 的源码 以及其下游项目源码（libcurl, aria2， Wireshark, node.js Apache Arrow）。我认为对于 DNS response header 的处理并没有统一标准，都是由应用层自己看情况处理的。比如在 nodejs 里的 dns.lookup 对于 non-recursion-available 的响应不会报错和提示，就返回解析 ip 而已。