DoQ (DNS-over-QUIC) support

[zdm9981]

No description provided.

[lwore]

DoQ (DNS-over-QUIC) RFC 已经定稿，希望得到支持。

[EkkoG]

看了一下 overture 的 DNS 请求是由 https://github.com/miekg/dns 构建消息然后发出的，所以 overture 要加 DoQ 的话应该需要 miekg/dns 支持

根据 miekg 的说法，现在的实现不太容易实现

quic-go uses Streams which are not net.Conn`s, and we don't want to pull all of that in this library. Quic/http3 is slowly happening in Go's std lib, until that is done I don't see what can be done in this library.

If you want to play with it yourself, various things can be wrapped in dns.Conn and the server could check if the conn support quic or some such

Originally posted by @miekg in miekg/dns#1370 (comment)

After looking over the code I can't really see a simple way to make protocols pluggable, they are too tied into a lot of things such as the Reader interface which has ReadTCP(), ReadUDP() etc and none of that is applicable to DoQ.

The design is also around having one listener listening for one connection that delivers DNS messages where QUIC is conn listener -> stream listener -> streams. Sure, that could be solved with channels etc but then it's workarounds which makes the code clunky and slow.

I think a better approach is to make my own module that mimics dns.Server as much as possible.

Thanks for the reviews and discussion!

Originally posted by @jelu in miekg/dns#1377 (comment)

Surge 作者发现疑似 Adguard 的实现有问题 AdguardTeam/dnsproxy#260

[ZeroClover]

AdGuard Home 的问题是因为其依赖的上游项目 quic-go 禁用了 Connection Migration，而且 quic-go 在短期内似乎没有计划重新实施连接迁移。

[EkkoG]

Go 的 QUIC 实现好像只有 quic-go 是吗，官方的进度也比较慢，如果是这样感觉 QUIC 在 Go 生态的推进似乎不太理想