New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for DNS-over-HTTPS to systemd-resolved #8639

Open
lucaswerkmeister opened this Issue Apr 2, 2018 · 5 comments

Comments

4 participants
@lucaswerkmeister
Member

lucaswerkmeister commented Apr 2, 2018

Submission type

  • Request for enhancement (RFE)

systemd version the issue has been seen with

v238; master (34bfb98)

Used distribution

Arch Linux

Cloudflare’s new 1.1.1.1 DNS service supports both DNS-over-TLS (RFC 7858) and DNS-over-HTTPS (draft) according to their announcement. We already have an issue for supporting DNS-over-TLS (#5671), but I couldn’t find one for DNS-over-HTTPS support.

Google DNS also supports DNS-over-HTTPS (reference), but as far as I can tell it only supports JSON responses, not the DNS wire format used in the current version of the DNS-over-HTTPS draft. Cloudflare DNS supports both, depending on the ct query parameter (not the Accept header).

@ancarda

This comment has been minimized.

Show comment
Hide comment
@ancarda

ancarda Apr 3, 2018

Would it make sense to do #7617 first?

ancarda commented Apr 3, 2018

Would it make sense to do #7617 first?

@lucaswerkmeister

This comment has been minimized.

Show comment
Hide comment
@lucaswerkmeister

lucaswerkmeister Apr 4, 2018

Member

Sounds reasonable. I think there might also be some opportunity for using 0-RTT TLS here, but I don’t fully understand the implications of that yet.

Member

lucaswerkmeister commented Apr 4, 2018

Sounds reasonable. I think there might also be some opportunity for using 0-RTT TLS here, but I don’t fully understand the implications of that yet.

@ott

This comment has been minimized.

Show comment
Hide comment
@ott

ott May 22, 2018

Contributor

I think 0-RTT TLS and TCP Fast Open are unrelated to DNS over HTTPS. So perhaps it makes sense to open a separate issue for them after #8849 has been merged.

Contributor

ott commented May 22, 2018

I think 0-RTT TLS and TCP Fast Open are unrelated to DNS over HTTPS. So perhaps it makes sense to open a separate issue for them after #8849 has been merged.

@ott

This comment has been minimized.

Show comment
Hide comment
@ott

ott May 22, 2018

Contributor

@lucaswerkmeister What would be the use case for DNS over HTTPS? It seems to be targeted at applications in constrained environments which permit only HTTP queries and no other network communication. A use case would be a WebRTC client that has to resolve a SRV RR to find a SIP server. Perhaps it is also possible to circumvent DNS censorship.

However, I don't see how DNS over HTTPS is of use in systemd. There will be support for DNS over TLS (#5671) soon. I also guess that DNS over HTTPS can easily be fingerprinted by its traffic pattern, so it's might only work until it is widely deployed. So it seems that DNS over HTTPS is only a more complicated encoding of DNS queries. HTTP does not seem to be of use here. But perhaps I overlooked some advantages.

Contributor

ott commented May 22, 2018

@lucaswerkmeister What would be the use case for DNS over HTTPS? It seems to be targeted at applications in constrained environments which permit only HTTP queries and no other network communication. A use case would be a WebRTC client that has to resolve a SRV RR to find a SIP server. Perhaps it is also possible to circumvent DNS censorship.

However, I don't see how DNS over HTTPS is of use in systemd. There will be support for DNS over TLS (#5671) soon. I also guess that DNS over HTTPS can easily be fingerprinted by its traffic pattern, so it's might only work until it is widely deployed. So it seems that DNS over HTTPS is only a more complicated encoding of DNS queries. HTTP does not seem to be of use here. But perhaps I overlooked some advantages.

@ott

This comment has been minimized.

Show comment
Hide comment
@ott

ott May 22, 2018

Contributor

And just to give an example why tunnelling another protocol over HTTPS does not really help against censorship, consider for example the relatively simple ip-https-discover NMAP rule that identifies the Microsoft DirectAccess protocol that tunnels IPv6 over HTTPS. A more sophisticated intrusion detection system could discover the hostname or IP address of the DNS over HTTPS resolver from the TLS handshake or IP header of network traffic or initial DNS queries, probe whether it is a DNS over HTTPS resolver and if so, insert a packet filter rule.

For Google Public DNS it would even suffice to not resolve dns.google.com and for 1.1.1.1 it would suffice to block 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001 and cloudflare-dns.com.

Contributor

ott commented May 22, 2018

And just to give an example why tunnelling another protocol over HTTPS does not really help against censorship, consider for example the relatively simple ip-https-discover NMAP rule that identifies the Microsoft DirectAccess protocol that tunnels IPv6 over HTTPS. A more sophisticated intrusion detection system could discover the hostname or IP address of the DNS over HTTPS resolver from the TLS handshake or IP header of network traffic or initial DNS queries, probe whether it is a DNS over HTTPS resolver and if so, insert a packet filter rule.

For Google Public DNS it would even suffice to not resolve dns.google.com and for 1.1.1.1 it would suffice to block 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001 and cloudflare-dns.com.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment