Hacker News Reader

Comment by swiley | Hacker News Reader

I personally would have been a lot more comfortable with a different DNS protocol if

1) the companies pushing them didn’t limit it to just their product (and instead added it to the C runtime resolver)

2) didn’t limit it to their servers (that’s honestly pretty concerning)

Firefox allows you to use any resolver you wish. It just isn't a feature exposed in the UI, and instead you have to use about:config.

Specifically you'll need to set:

- network.trr.bootstrapAddress: To a secure DNS provider you trust (to get the HTTPS DNS resolver's IP/bootstrap DNS over HTTPS). e.g. 1.1.1.1

- network.trr.mode: To 2 (DNS-over-HTTPS is first choice, fallback to OS), 3 (DNS-over-HTTPS only otherwise fail, recommended)

- network.trr.uri to the URL of your DNS-over-HTTPS provider. e.g. https://cloudflare-dns.com/dns-query

If you set all three (and mode to 3), it is a completely bespoke, highly secure DNS solution. That's what I use at work for any personal browsing.

The problem isn't the lack of a configuration option, it's when the default is to ignore the one configured in the operating system.

Suppose I have all my devices configured to use my local DNS where I've added names for my other local devices or changed the ones for some names because local devices should use the RFC1918 addresses instead of the internet ones that are routed differently. Suddenly Firefox on every device is using Cloudflare even though nobody ever told it to, and now I have to go touch every device and fix it, including when they're BYOD and the owners want them to "just work" and resolve the names correctly without me having to touch them.

Then the same thing all over again when Chrome does it or any other application.

I would also add the following for Encrypted SNI:

  network.security.esni.enabled = true

Check by running all four tests i.e. Secure DNS, DNSSEC, TLS 1.3 & Encrypted SNI at https://www.cloudflare.com/ssl/encrypted-sni/

This is really the issue. DoH is a little ugly/slow, but the security improvement over vanilla DNS is real. There are superior alternatives like DNSCurve but DoH > plaintext DNS even if DNSCurve > DoH.

The problem is implementing it in the application instead of the operating system. The owner of the device should be able to choose their DNS server in one place (including one that blocks or redirects domains the user actually wants to) and not have to keep after a dozen separate applications all with their own settings that ignore the user's globally stated preferences.

Mozilla could do everyone a favor and produce a free independent DoH implementation for each platform they support that allows it to be used by the OS resolver in every application and have its configuration set all in one place. Extra points for supporting DNSCurve as well.

There are instructions on how to route all operating system DNS requests through DoH here: https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo....

One advantage that DoH has over DNSCurve is that it is much harder to detect or block due to it being encapsulated as https traffic.

> There are instructions on how to route all operating system DNS requests through DoH here

Then the next step is to get operating systems to ship it by default and support DoH as a DHCP option:

https://tools.ietf.org/html/draft-peterson-doh-dhcp-00

> One advantage that DoH has over DNSCurve is that it is much harder to detect or block due to it being encapsulated as https traffic.

If you're using a network subject to active adversarial man in the middle attacks like that then you probably want to be sending all your traffic through some kind of encrypted tunnel rather than only DNS.

Yes but many such active adversarial networks prevent most traffic besides http/tls leaving the network. DoH solves this problem.

> Yes but many such active adversarial networks prevent most traffic besides http/tls leaving the network. DoH solves this problem.

So do VPN tunnels over HTTPS/TLS.

There is also happy eyeballs. Use DNSCurve and DoH at the same time and accept whichever answers first, which will be DNSCurve whenever it isn't blocked. Then in a few years when middleboxes have given up trying to block DNSCurve because the alternative is no advantage to them, we can deprecate inefficient DoH to a strict fallback and eventually be rid of it entirely (because they couldn't block DNSCurve anymore if it was 95% of DNS traffic).

Reply on news.ycombinator.com