Hacker News new | ask | show | jobs
by the_angry_angel 2541 days ago
This is my beef with (my understanding maybe incomplete, in which case I apologise) the implementation.

Internal DNS, split brain DNS aren’t catered for without disabling support? I don’t want my internal names leaking to the internet, nor necessarily are they the same for external resolvers. Now yes the latter is a hack, but it’s one widely used still today.

The idea is laudable. But it feels hostile. I can disable support, but for how long?

5 comments

I guess it would be possible to run my own local DNS server that connects to these DoH servers. Does any DNS server support DoH? This could also allow the user to override domains using their /etc/hosts file in case DoH on Firefox doesn't support it.
I use pihole + dnscrypt-proxy 2.*

A fair number of resolvers support DoH and dnscrypt-proxy also supports DoT. It's fairly feature rich, you can configure a hosts file and then some.

[0] https://github.com/jedisct1/dnscrypt-proxy

I'm running my own DNSoverHTTP instance at home. I have Apache, with HTTP/2 support, running, some self-signed certificates, and a CGI script that accepts the DNSoverHTTP request and makes a DNS call to my local version of bind. I found RFC-8484 to be quite easy to follow, and I've set network.trr.mode to 4 (use DNS, but also send DNSoverHTTP for testing) and network.trr.allow-rfc1918 to true (so local addresses can be resolved locally).

I will do the occasional tests with network.trr.mode to 3 (only use DNSoverHTTP) but I seem to have issues resolving github. I haven't looked that far into it.

EDIT: there do exist solutions to run locally.

Thanks, I’ll hace to look it up and give it a read. I’ll be honest I’ve not read the actual RFC in this instance and pieced together what I know from articles, reported behaviour, etc.

I know it’s lazy and I should’ve done more work. But, burn out

In that case you are better off running local DNS and using a different subdomain (internal.companyname.com or whatever) for internal DNS entries; the DNS-over-HTTPS query will go out, fail, and then Firefox will fallback to traditional UDP DNS on port 53, hit the local resolver on the LAN, and away you go. It will presumably cause a short delay the first time a host is queried, but after that I assume Firefox is smart enough to cache the result, so unless you have absurdly short TTLs the performance impact should be pretty low.

The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway.

the DNS-over-HTTPS query will go out, fail

You completely missed the point of the parent, which is to NOT let internal hostnames out of the network.

The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway.

This is a perfect example of the irritating attitude I see from people pushing hostile features like this. Everyone wants their network to operate the way they want, and yet you think you know better than the actual owners of those networks.

The owners of the networks have time and time again done user hostile things that have compromised their security and privacy.

Corporate networks are a small percentage of network traffic and their use cases are less important in the grand scheme of the internet.

DNS over HTTPS is a solution because network owners can't be trusted. Either by blocking or by taking their DNS logs and selling it to advertiser's.

I am the owner of my network, as is everyone who has one at home, and you are saying that I can't be trusted. WTF!?
I think Jonnax meant ISPs, not you.
In which case he is wrong. You are the operator of your own network.

If applications decide to bypass you, they are hostile and cannot be trusted.

The lack of trust I mentioned was about ISP provided DNS servers. You don't own your WAN network and the majority of people use the DNS provided by their ISP.

On your own network, if you feel like doing a DNS lookup to what amounts to a public address book is unethical then don't allow arbitrary clients on the network.

If you want to do blocking based on a DNS list, configure your firewall to do that.

Knowing better than the owners is a matter of tradeoff.

There are whole isps and even countries (including the UK shortly) which mess with DNS requests. Helping the millions of users who are in that situation, and don't even know what D Sits, seems like a net good. As you say, experts can choose to disable it.

> As you say, experts can choose to disable it.

As long as they can. The problem with these ideas is that it can get increasingly difficult to work around them. How many hoops you have to jump through to pcap your own software on your own machines now that certificate pinning is becoming popular? What when someone will have the bright idea of implementing certificate pinning for DoH inside browsers, "because security"?

(I could live with the choice between having to somehow acquire Chrome Enterprise Edition vs. switching to Firefox, to have a browser I can control. I'm worried now that Firefox might be turning into Chrome, though.)

> including the UK shortly

If you're implying the porn filter, no, the porn filter has been shelved 'indefinitely' because a) it's against EU law, b) it was May's personal project (she pushed heavily for it when she was Home Secretary, and it became a thing under her PM-ship).

Firefox could provide an opt-out flag.
A likely opt-out [1] mechanism that will prevent Firefox from enabling DoH in any future update.

5 means explicitly disabled. 0 (default) is whatever is considered default for now.

  1. about:config
  2. network.trr.mode = 5
[1] https://news.ycombinator.com/item?id=20373444
Once Firefox starts to ignore DNS resolvers configured at the OS level other apps are sure to look at it and think it must be a good idea because Firefox is doing it. Soon there will be a multitude of applications needing this disabled in their own unique way.

If the Mozilla Foundation see this as an issue they should instead be developing a separate solution to provide this system wide. If you must bundle it with Firefox and offer to install it at browser installation or upgrade time. Don't install it by default and certainly don't enable it without user permission.