DNS over TLS support?

[nogweii]

Could SSLH support passing encrypted DNS traffic to an upstream?

RFC 7858

(This issue was previously about DNS over HTTP, but I have since changed my mind. It was also phrased poorly and conflated some terms together that I shouldn't have. Sorry for the confusion!)

[gdm85]

I am also interested into this; however I am a bit confused at this point.

We have:

• DNS over TCP
• DNS over HTTP(S), shortened as DOH
• DNS over TLS, probably the same as DOH

From what I have seen about DOH it requires a server replying in JSON and is protected by TLS.

@evaryont are you proposing here that sslh could support only DNS over TCP as specified in RFC 7766? The draft you linked is expired and mentions both TCP and HTTP, but I doubt sslh would want to inspect the HTTP request to decide whether it is a DNS-over-HTTP request.

From my understanding it would be enough to proxy /dns-query through your webserver of choice to a local DNS-over-HTTP capable server, although I have not been able to find a capable one so far.

[nogweii]

DNS over TCP is just regular DNS. A DNS query can happen over UDP or over TCP. TCP is useful when you start adding a lot of detail, like DNSSEC. I've also made a mistake in my original phrasing. All traffic happens in clear text on port 53.

DNS over HTTP is an HTTP wrapper around a DNS request. Outside of the weird binary body content (which is just a regular DNS query), it it regular ol' HTTP. SSLH doesn't need to do anything. Traffic usually happens via HTTPS over port 443. I also don't care about DoH.

DNS over TLS is what I'm requesting. It encrypts the DNS query and sends it to the remote server over 853/tcp. (Since the encryption adds a fair amount of extra data, exceeding the maximum size of a UDP datagram.)

[yrutschle]

If there is an ALPN identifier for DNSoTLS, and your DNS client uses it, then it should just be a matter of configuring sslh to route the appropriate ALPN towards the DNS server.

Also, if the other protocols you're multiplexing are "not TLS", you just need to route TLS to the DNS server (possibly through stunnel), e.g. you're hosting DNSoTLS + SSH on TCP port 443:

----> :443 ---> sslh --tls_probe----->stunnel---dns--->dns_server -----ssh_probe---->sshd

If you need to have both HTTPoTLS and DNSoTLS over the same port, then that'll only work if the clients support SNI or ALPN...

[xxdesmus]

DoH or DoT would be great. Adding a vote on this also. I know it's an old thread, but I can still dream this might happen.

[jedisct1]

DNSCrypt would be even more useful.

[yrutschle]

@xxdesmus : what doesn't work with my proposed solution?

@jedisct1 : I had never heard of that. Apparently no-one wants DNSSec or what? :) From the quick look I had of the protocol, there is nothing in the client's first message that would let us work out what protocol it is:

<dnscrypt-query> ::= <client-magic> <client-pk> <client-nonce> <encrypted-query>

[jedisct1]

The client magic is known in advance by the server; this is a constant for a given server key.

[yrutschle]

Ah, then a simple regex probe would do the trick, if I remember correctly you could specify a byte at the start of the packet as such:

regex_patterns: [ "^\x42"]

to match a client-magic of 0x42.

[rnhmjoj]

@jedisct1 : I had never heard of that. Apparently no-one wants DNSSec or what? :)

DNSSEC is authentication, DNSCrypt is encryption: you generally want both.

The client magic is known in advance by the server; this is a constant for a given server key.

Yes, but it changes constantly as the server rotates the ephemeral keys. So, it doesn't look very practical. If DNScrypt is the only non-TLS protocol anyprot works, though.