DNS-over-HTTPS是DNS的一种演变，它允许我们以与TLS保护HTTP流量相同的方式保护来自系统或用户的DNS请求流。截至2018年9月，它已在两大主要浏览器(Mozilla[1],Chrome)和两大主要服务提供商(Cloudflare[2],Google[3])中部署，并得到了该领域许多人的支持，因为我们需要解决DNS问题。
目前GitHub上已经有几个Go实现[4],但这些实现需要获得认可和意识才能使用。将其嵌入到Go标准库中将极大地有助于保护我们的系统和用户。
[1] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/
[2] https://developers.cloudflare.com/1.1.1.1/dns-over-https/
[3] https://developers.google.com/speed/public-dns/docs/dns-over-https
[4] e.g. coredns/coredns#1619
6条答案
按热度按时间5rgfhyps1#
我想象最好先在标准库之外实现这个功能，就像HTTP2最初是在
x/net中实现的一样。所以也许#16218应该先做。我还想知道#12503是否会成为这个功能的要求，以便能够在不同的解析器之间切换。
我个人对DNS over TLS和DNS over HTTPS也有些困惑。我们想要支持两者吗？如果不是，我们应该更倾向于哪一个，为什么？
hs1ihplo2#
我认为#16218的大部分内容都在https://godoc.org/golang.org/x/net/dns/dnsmessage中。
DNS over TLS是一种不同的协议。DNS over TLS的技巧在于它需要在人们的防火墙中打开一个新的端口。Chrome尝试在除了HTTPS的443端口之外的其他端口上部署HTTP/2和SPDY,并发现对于他们用户群的很大一部分人来说，他们无法通过这些其他端口建立连接。出于同样的原因，通过443隧道并利用HTTP(尤其是HTTP/2)客户端的优势来实现DNS over HTTPS已经成为一种主流做法。
qq24tv8q3#
我想象最好先在标准库之外实现这个功能，就像HTTP2最初是在x/net中实现的一样。所以也许应该先完成#16218。
我一直在玩一个使用
net/http和x/net/dns/dnsmessage的玩具命令行客户端，它非常令人愉快。jrcvhitl4#
我也对DNS over TLS与DNS over HTTPS有些困惑。我们是否需要支持两者？如果不是，我们应该选择哪一个以及为什么？
@mvdan DNS over TLS已经通过极少量的代码得到支持：https://github.com/artyom/dot/blob/master/dot.go
fhg3lkii5#
作为附注，另一个在Go中实现的DoH客户端和服务器也可以在https://godoc.org/github.com/shuLhan/share/lib/dns找到。
0x6upsns6#
这些是基于#24796中表达的想法的hack,但我无论如何都会分享它们：
net.Resolver示例具有缓存、机会主义加密、DNS-over-TLS和/或DNS-over-HTTPS: github.com/ncruces/go-dnsDoH解析器利用Go的HTTP机制来解决诸如#23866的问题。
DoT/DoH不应受到诸如#23873之类的事物的影响，因为512字节的限制不适用。
另一方面(也是我认为的),任何严肃的DoH/DoT实现都需要考虑缓存。两者都不会从本地解析器缓存中受益。还需要考虑的是解析器的配置方式。DoH需要指定URI模板，DoT需要为证书验证指定服务器名称。
就我个人而言，Go的
net.ResolverAPI并不适合实现这些功能。