Open mzealey opened 4 years ago
It would certainly be possible to do so in theory, yes . It's quite complicated, however, because we don't handle the HTTP(S) I/O ourselves but delegate that to libh2o. There might be some way to peak at the incoming bytes and to bypass libh2o if we detect that the request is DNSCrypt but that would require serious work, and it's unlikely to happen unless someone chimes in.
To note, looking at the project mentioned above it just checks if the first two bytes of the tcp connection start packet are 0x1603. This presumably comes from the method described in https://www.unvalidatedinput.com/detecting-ssl-and-early-tls/
This comes from the first bytes of a TLS handshake.
It works because in DNS queries over TCP (encrypted or not), these bytes encode the length. And 0x1603
would represent a 5635 bytes long query, which is hardly valid.
sslh may help do that, even though something leveraging XDP would be way more efficient nowadays.
Short description
DNSCrypt default port is 443; DoH also uses the same. It would be nice to be able to have both of these on the same ip/port combo. Currently specifying both fails as dnsdist tries to bind to the same port twice. According to https://github.com/jedisct1/encrypted-dns-server it should be possible to determine if request is DNSCrypt or https and route accordingly.