dnspod 的专业版公共 dns 的普通 udp dns 绑定源 ip 可以对自定义设置的规则生效，如果其他 ip 访问，就是普通的公共 dns ，自定义规则不生效，但是非绑定 IP 不能解析的功能是没有的，毕竟家用 IP 经常变，如果完全无法解析，问题比较大。
如果是 doh 的话，则是通过 sni 来控制的自定义规则是否生效的。
但是非指定 IP 不能解析的规则，好像确实没见过，毕竟一组 IP 不可能只分配给一个固定的用户用

{ echo -n -e "\x00\x2b";sleep 1; echo -n -e "\x69\x6f\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x0a\x6c\x6f\x76\x65\x6c\x79\x70\x69\x6e\x67\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x00\x00\x00\x00"; } | nc 1.12.0.1 53

nc 模拟在同一个 tcp 连接中分段发送 DNS 请求的示例，此处是向 1.12.0.1 发送 tcp dns 请求域名 lovelyping.com 的 A 记录

可以使用老版本 nslookup 或 nc 来模拟分段发送 dns 请求

这个还需要看 dns 服务端对 tcp 请求的兼容性问题，不是所有版本的 windows 的 nslookup 都有这个，只是部分版本的 nslookup 有这个问题。

当客户端发起 tcp 请求的时候，tcp 的 dns 请求是由 2 个字节的长度包+实际的 dns 请求组成的，部分较旧版本的 nslookup 会把两个部分分开发送，而 dig 和较新版本的 nslookup 会将两部分一起发送。

当 dns 服务端对 tcp 的 dns 请求数据不进行分段接收数据的支持处理的话，比如只支持一次性收到 2 字节的长度包，和完整的后续 dns 请求包，那么这些老版本的 nslookup 分 2 次发送的数据包，在 dns 服务端收到的数据和前 2 字节的数据包长度不匹配，就会校验失败，然后关闭 tcp 连接。

如果需要兼容此类客户端，需要在 dns 服务端进行修改，支持 tcp dns 请求的时候，没有一次性收到完整数据的场景，即需要自己对客户端的 tcp 连接和已收到部分数据做额外的管理，会复杂一些。

11.30 已经找有关部门解封完成

目前腾讯的 doh ， 域名形式的海外都没有污染，国内走正常路径，是否污染看上游是否有污染。
IP 形式的海外部分国家无污染，部分则还会有污染。

@YHKM 已经转给产品

@yuepao 建议可以工单咨询

@yuepao 问了下，上海和广州已经灰度了部分服务器，很快会全量。
北京和国外的节点貌似暂无灰度更新计划

相关同事排查确认，IOS17 的 doh 会额外携带 EDE 的 EDNS 扩展（ 15 Extended DNS Error ），而 dnspod 的 doh 对 dns 格式请求进行严格校验，不支持的 edns 扩展直接返回错误。
等相关同事后续看怎么兼容吧。

@cndns 阿里和腾讯是合规开展服务的，至于如何合规的就可以想象了，合规成本非常高。

@dingdangnao [流汗]doh 不是这样直接使用的，如果只是想访问产品主页，建议直接从官网进入。

如果要用 DoH 进行 DNS 查询，建议直接使用相关软件或浏览器 /操作系统中设置安全 DNS 。

如果想通过命令行方式通过 DoH 进行 DNS 请求，则必须带查询参数，有两种 API ，google 的 json API 和 RFC 8484 两种方式，而 RFC 8484 又分为 GET 和 POST 两种不同的方式，请求参数都不一样，可以参考： https://developers.google.com/speed/public-dns/docs/doh?hl=zh-cn

比如查询 dnspod.com 需要请求，如果是 json api 就是类似这样
curl -v "https://doh.pub/resolve?name=www.dnspod.com&type=a" 或
curl -v "https://doh.pub/dns-query?name=www.dnspod.com&type=a"

RFC 8484 GET 方式，其中 dns 参数是 dns 请求二进制数据进行了 base64 编码：
curl -v "https://doh.pub/dns-query?dns=AAABAAABAAAAAAAAA3d3dwZkbnNwb2QDY29tAAABAAE"

如果是 RFC POST 方式则是将 dns 请求的二进制数据放到 post 数据里

任何请求参数校验失败服务器会丢弃请求，前面的 nginx 自己回了 502

@dingdangnao 也可能是其他参数校验错误，如果参数都正常的话可以正常应答。

@dingdangnao 说错了，id 可以为 0 ，但是 answer 不能是 1 或其他值，必须是 0 ，否则会 502 。

@dingdangnao 看下是不是 dnsid 传了 0 ，目前这两个 IP 的 doh 不支持 dns id 为 0 的请求，会返回 502 。正常的 dig/kdig/浏览器等发起的 doh 请求都是正常应答的。

可以通过或者抓包（ POST ）或者 GET 看下请求 url base64 编码的前 3 个字节是什么，比如如果是 AAA-AAD 表示 dns id 为 0 。

如果不是 dns id 为 0 的情况，可以发下请求串的 base64 或抓包的 16 进制都可以。

@dingdangnao 有复现，我找负责的人看下

@dingdangnao 问下哪个地区的啊

测试是正常的，不过在 10:30-12:50 这个时间段 1.12.12.12 和 120.53.53.53 这两个 IP 有部分地区部分运营商可能会失败。