Hacker News Reader

Comment by iso1631 | Hacker News Reader

I want my OS to do DNS - including DOH, not my browser. I want a single source for my DNS

I want my network to tell me a DNS server to use. As I own my computer I can override that, but much of the time I want to use the network provided DNS server.

View on HN

> I want my OS to do DNS - including DOH, not my browser.

The cat is out the bag, so to speak. I foresee a lot of adware, spyware, and malware leveraging DoH now to evade just about every DNS-based monitoring/blocking/provisioning solutions.

Anyway, the right layer to monitor for Internet traffic has always been the IP layer (VPNs notwithstanding).

Can you elaborate? An adware app will be installed in the OS, and will proxy all DNS requests?

Apps will make DOH requests from within their apps to avoid host-based DNS blocking.

The next step is blocking all the traffic from all apps and whitelist the IP addresses app by app. I did it on my Android phone, a couple of phones ago. I don't remember the name of the app. It could be done on a desktop or server OS too.

That sounds like a fun way to spend your life.

This is nothing that wasn't possible before. Taking the traditional example of hosts-blocking the Adobe activation servers, what was stopping them from just querying 1.1.1.1 from the app? Or even falling back on a hard-coded IP? Especially with IPv6, bypassing DNS-based blocks is rather trivial - the main reson we don't see it all that much is that companies simply don't care to do it. Users of PiHole and similar are usually the kinds of users who will figure out a way to block whatever they want one way or another, so there's no use in trying to stop them. Until we get hardware-enforced app signing (big middle finger to Apple here) we can block anything, regardless of DoH.

You're right, I guess the question is did they bother before. If normal DNS works fine for 95% of users, the hurdle of implementing a non-standard workaround is too much. If DOH is the norm, then the hurdle becomes lower.

Of course you can just drop a rule blocking the IP address on your firewall, which will probably work for a while.

I would argue that the hurdle of bypassing DNS-based content blocking was already so vanishingly small that it doesn't make any sense to impede useful and practical privacy technologies on that basis.

You could make the exact same kind of argument about widespread use of HTTPS for example. Do we want to allow encryption technology if it means the enemy can use it too? As a society we have agreed that encryption is a net positive even though terrorists and criminals benefit from it, but when malware uses it then that's too far?

>I would argue that the hurdle of bypassing DNS-based content blocking was already so vanishingly small [...] //

That doesn't hold up under scrutiny. My pihole blocks ~11% of domain lookups (blocking 1000 queries per day for our household), turning it off vastly increases the unwanted content. It might seem is logical a ready hurdle, but it's a hurdle that practically works.

I don't follow the reasoning that says this is a small barrier to malware so we'll remove it.

What are we, end users, getting out of routing all our domain lookups to Cloudflare and ceding control of filtering?

I've always assumed any device or program I don't control will bypass anything I tell it to use and tunnel all it's evil traffic.

It does feel the world is moving away from a multi-level network to run everything over TLS/TCP (and probably eventually mainly TLS/UDP), taking away the power from me as a network and device owner, and giving it to the developers

If only the OS could terminate TLS and allow to filter decrypted traffic locally.

Isn't this SSL offloading and done by companies to introspect the traffic?

That only works as long as the CA trusted by the user's computer is controlled by the box trying to do this.

Which shouldn't be a problem since it's the box itself doing the decryption. No need to MiTM since it's the endpoint.

This is prevented by certificate pinning.

You could easily add APIs for cert pinning at the OS level. Or provide the details needed to verify with the OS -> Program call return.

Yep, and HTST (if you don't trust that you can use an Firefox addon to perform certificate pinning). I believe HTST got introduced in the wake of the DigiNotar debacle (listen Darknet Diaries #3). Mitmproxy also made it easy.

I guess this Mozilla Firefox change deprecates HTTPS Everywhere.

Either way, we've come a long way. For people in the Dutch security world, DigiNotar was a known joke. I knew about their terrible security (and the implications) back around 2000-2004. Although there have been more vulnerabilities too, such as Hearthbleed and POODLE.

> HTST

I'm not familiar with HTST so I went looking but didn't find anything related to the web and HTTP, so I'm guessing you meant HSTS?

Yes, thanks for the correction.

Only on a handful of domains. Most site admins are fearful of HPKP. The mitm proxy I am using to post this message only has to exclude a small handful of domains from mitm decrypting. A bunch of google domains, eff.org, paypal, a few mozilla domain names, dropbox and android. To my surprise, no traditional banks, no money management or stock trading sites, no "secure" portals used by law firms to share sensitive files. The sites I would expect to use pinning are the ones that do not.

On a side note, I would love to see a system that adds out-of-band validation of an entity. e.g. My bank should have a QR code behind glass on the wall that I can scan, import a key and further validate their site at the application layer, above and beyond HTTPS and CA certs.

I was thinking more of devices I don't control - IOT stuff that requires internet access to function (like a box to watch netflix). Clearly anything running on my machine is fine as it's under my control

So between the user and the network operator, who should have the final say? It seems like you're saying, "it should be the user when I'm the user and it should be the network operator when I'm the network operator". But I don't think we can have it both ways.

Generally the policy should be

1) The ISP says what should be used

2) the lan either accepts that, or the operator puts their own values

3) the device either accepts that, or the operator puts their own values

Same as object inheritence. An ISP says "use this DNS server it's nearer", the network operator says "no thanks, I'll run my own with an upstream of google as I don't like your NXDOMAIN injects", the user says "actually I'll use cloudflare because I don't trust any of you"

That's all fine, and gives the power to the user.

Exceptionally if a device doesn't allow the network settings to be overwritten for some technical reason, it should simply accept what the lan sends it.

I think there will be some contention over 1 and 2 because we're at the point where both of these entities might be trusted (at home and work) but are inherently untrustworthy.

And so browsers are saying that the path should be.

1) The browser developers say what should be used.

2) The user either accepts that or puts their own values.

Ideally I think it should actually be something like

1) The OS vendor say what should be used.

2) The user either accepts that or puts their own values.

2.1) Lan operators can offer DNS servers which the user can (always) accept or (always) reject with reject being the default.

But this whole mess with browser DoH is because OS vendors are slow to move on this. Google Android does it kinda, Windows has it in beta, Linux works but it's a little DIY.

Just point them to your http proxy and filter there all you want.

IBM z/OS has an interesting feature: AT-TLS (Application Transparent TLS). An app uses the OS sockets API to create plaintext sockets, and the OS adds TLS to them (based on policies configured by the sysadmin) transparent to the application. (There are IOCTLs that apps can call to discover this is going on, turn it on/off, configure it, etc, but the whole idea is you can add TLS support to some legacy app without needing any code changes, so adding those IOCTL calls to your app is totally optional.)

In some parallel universe, TLS would have been part of TCP not a separate protocol and the Berkeley sockets implementation in the OS kernel would handle all encryption, certificate validation, etc, on behalf of applications. AT-TLS is a bit like visiting that parallel universe

I think this is actually making a comeback for the server room; https://www.kernel.org/doc/html/latest/networking/tls.html for example. I _think_ the point of these is hardware TLS accelerators.

Linux kernel TLS, at least at the moment, only does the symmetric encryption part in the kernel, and the TLS handshake, certificate validation, has to be provided by user space. This is different from z/OS AT-TLS in which the OS does the TLS handshake, certificate validation, etc as well.

(Strictly speaking, I'm not sure if AT-TLS actually is implemented in the OS kernel – or "nucleus" to use the z/OS terminology – it may actually be implemented somewhere else, say in the C library. I know some of it is actually implemented by a daemon called PAGENT. But, from the application programmers viewpoint, it is provided by the OS, however exactly the OS provides it.)

> The cat is out the bag, so to speak. I foresee a lot of adware, spyware, and malware leveraging DoH now to evade just about every DNS-based monitoring/blocking/provisioning solutions.

But tunnelling X in Y is not new at all and has a long tradition (even in regular protocol design). Is this really a shift waiting to happen in malware? As I would think, this has been available all along. Except for browser-based malware.

Right. It is ridiculous to say that DoH enables malware because it has always been trivial to bypass DNS-based access control with or without technologies like DoH. In fact, if anything, using DoH would be a particularly cumbersome way of doing it when there are many simpler solutions. Like for example, just putting an IP in a text file on a REST endpoint.

I think the best case I can make is that it's not about the ability to tunnel DNS, it's that there's now many fast highly-available public DoH resolvers that bypass DNS filtering for free. A hypothetical malware author just needs to use any of them rather than set up their own tunnel.

True, this aspect of the situation could make malware use cases a bit simpler to operate/maintain.

If we're going to talk about the "right" thing to do then don't run closed software or anything that doesn't do what you want and the problem goes away.

This has always felt like a strange concern to me. It’s a bit like refusing to have gloves in your house, so that a burglar can’t borrow your gloves to avoid leaving fingerprints.

Adware, spyware, and malware has always had the ability to avoid system DNS. At its most basic, they could hardcode lists of IPs into their malicious code. At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system. Drop a list of hostnames into a pastebin post, tell your malware to check the list for updates, profit.

DoH in Firefox simply makes the above issue harder to ignore. Before this, an enterprise or individual sysadmin could implement DNS inspection at the border, see logs showing their users browsing naughty websites, and feel like they’d made progress. But they’d always be blind to attackers (or nefarious users) who just didn’t bother using the stock DNS offering to bootstrap their hijinks. Detecting that has always required device-level monitoring or further MITM of traffic; learning about DoH makes that more obvious to sysadmins, but it doesn’t materially change what adversaries were able to do already.

I am not in disagreement.

> DoH in Firefox simply makes the above issue harder to ignore.

That's exactly what I mean [0]. The cat's always been there so to speak but now it is out there roaming around harder to ignore.

[0] https://news.ycombinator.com/item?id=25123487 and https://en.wikipedia.org/wiki/Script_kiddie

> At its most basic, they could hardcode lists of IPs into their malicious code.

Which makes the malware more fragile, because the hosts are often compromised machines themselves, or are the targets of takedowns. If they include only one IP at a time (as they can do with DNS) then when that machine gets cleaned by the owners, they have no way to switch to another one. If they list several machines then anyone analyzing the malware has a list of multiple compromised machines to go have them all cleaned at once. Also, then you can add the IP address to a block list and they can't update it like they can with DNS.

> At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system.

Malicious javascript in a browser doesn't have access to SSH or similar. And that's assuming their code can even reach your machine if your Pi-hole is blocking the DNS name of the server hosting it.

> DoH in Firefox simply makes the above issue harder to ignore.

It makes it harder to prevent. Someone sends the user an email link to a URL containing an unpatched browser exploit or a link to a malicious binary. If the Pi-hole blocks the domain and/or the IP address in the email, the attack is prevented. If the browser bypasses the Pi-hole, you have malicious code actually running on the user's machine, and that's a much bigger problem.

Hardcoding the IP certainly has limitations but that is only the easiest example of bypassing DNS-based content blocking. A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer.

> Also, if they use an IP address then they can't be using SNI to host it on the same IP address as several other domains

Sure they can, just hardcode the "Host" header value as well

> Malicious javascript in a browser doesn't have access to SSH or similar.

They can access HTTP though, which is more than enough.

> A slightly less trivial solution where you grab the IP out of a file over HTTP instead could be easily implemented by any junior developer.

Over HTTP from what? You would need name resolution or a hard-coded IP address to make an HTTP request.

And the thing this is preventing isn't just what the malware does after you're already infected, it's the path to receiving malware to begin with.

And don't you similarly also need name resolution or a hard-coded IP address in order to reach a malicious DoH server?

It's not a malicious DoH server. It's just any DoH server which is bypassing your Pi-hole and therefore resolves the malicious name instead of blocking it.

That's not the point. Don't you need to hardcode some kind of identifier in order to use your malware's preferred DoH server instead of the user's preferred one (which could have content blocking applied)?

The issue is with Firefox overriding the system DNS with its own by default, when the system DNS may have content blocking applied and the Firefox default may not.

I think if the user wants that, they should choose to apply it. Not the network operator. Same as how I wouldn't want my network operator inspecting my HTTPS traffic for malware.

The user can do whatever they want. It's their machine. But you know perfectly well that almost everybody is going to take the default because they don't even know what the setting does, and end up disabling content blocking when they didn't intend to.

And in many cases the user is the network operator. What the browser is doing is taking away the mechanism to set local policy. Ordinarily you hand out the DNS you want your devices to use via DHCP, and they use it. If you move that from the OS to the application and the application ignores the DHCP setting by default, now you've lost the ability to set a uniform policy for all your devices and applications. It becomes an arduous manual process to change the setting in every application on every device, and then you probably miss half of them.

Yes, and I am saying the default should be to use a guaranteed source of truth and not something set by the network operator's policy. Same as how your trusted root CA certificates don't come from a network policy for example. I don't think we should be making a convention of inspecting users' private traffic, regardless of whether it is by default or by opt-in, under the guise of protecting them from malware.

DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.

The problem is "guaranteed source of truth" doesn't exist. When the network operator is you, or your family/company, you may trust the local DNS to respect your privacy more than you do Cloudflare. Not all names are intended to resolve the same everywhere -- sometimes the local DNS will give the RFC1918 address for a local server instead of the public one, or have a set of local names that are only accessible on the local network. How do you propose to globally resolve the reverse lookup zones for 10.0.0.0/8 et al?

If the DNS set by DHCP were only used for local network resources and not internet resources, I wouldn't have a problem with that. That is what it is there for.

There isn't a bifurcation in the namespace for local resources. Any given name could resolve to a local address or a public one. There isn't even anything requiring a local-only server to have a private address -- it's common to have a public IPv6 address for something which is still only resolvable or accessible from the local network.

> you may trust the local DNS to respect your privacy more than you do Cloudflare

For most people, their local DNS is someone like Comcast or Verizon, way less trustworthy than CloudFlare. We shouldn't reduce the privacy of the majority of people just to increase it for a small minority of people by default.

I'm the user and the network operator. Can you give me a comprehensive list of places I need to configure, and notify me when another place software can go around my configuration is added?

I never said there wouldn't be an increased configuration burden for that kind of setup. There was also an increased configuration burden when we moved to widespread HTTPS, but the benefits outweighed the costs.

As a user, what is the increased administration burden for http?

Are you referring to the whole CA system being an untrustworthy racket?

As a user, what is the increased admin burden for using DoH, assuming you don't want to implement network level content blocking? Basically none.

What is the burden for using HTTPS assuming you DO want to be able to inspect and block HTTPS resources at a network level? Very extensive compared to plain HTTP.

Make the libc resolver do DoH, and drop it from firefox,half the problems go away.

The other half of the problems are around defaulting to allowing cloudflare to inspect your traffic, instead of comcast. And the lack of integrity and encryption for the rest of the DNS infrastructure. And the expansion of the complex and difficult to secure x509 certificate regime which we should be moving away from. (Something like gossamer seems to be a big step in the right direction)

I want encrypted dns, just not a half-assed hack of an implementation that is going to be impossible to fix once deployed.

I agree with you there, OS vendors should be implementing DoH. Thankfully they are finally getting around to it after pressure from browsers.

Regarding the rest of the DNS infrastructure, I agree there is more work to be done. But I see DoH/DoT/etc as a necessary step and not a "half-assed implementation" that needs to be "fixed".

>assuming you don't want to implement network level content blocking? //

Who doesn't want that? I have a pihole (and use OpenDNS). Bypassed it all yesterday, as an experiment, to look at an anime site my eldest started using and immediately was hit with a pretty impressive and convincing phishing attempt (mimicking my ISP).

Pretty much all of us on HN seem to use some form of 'DNS' based filtering (pihole, or even just hosts file). UK ISPs offer DNS based filtering as a default (and have to filter some pages by law, and are encouraged to filter others [through threat of law]) ... but a lot of people want that, many many families, schools, businesses.

Certainly I don't want it to be easier for advertising and malware to bypass my chosen DNS-style filtering.

I don't want it and I don't recommend it to my peers. I also don't think DNS-based content blocking is really as popular as the PiHole community would say. I use client-side content blocking like uBO instead, which I imagine is overwhelmingly the more common solution, and it is also more powerful and effective (and easier to use).

UK ISPs having mandatory DNS blocking is a great example of why DoH is important. The user should decide what they want, not the network operator.

Perhaps widespread use of encryption technologies means I can't do content blocking on proprietary appliances like the Chromecast for example. I think that's a necessary evil and I just won't buy such an appliance if it's that big of a problem. Only legislation can really fix that kind of problem anyway, it doesn't really matter whether Firefox implements DoH or not.

I'm not sure why HN won't allow me to reply to ori_b's question below you, however DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS.

https://support.mozilla.org/en-US/kb/configuring-networks-di...

Someone previously mentioned Pi-Hole. Pi-Hole provides the DoH canary domain in it's default configuration, therefore if you run an up to date Pi-Hole on your network you will have DoH disabled. It is recommended (and there are good instructions on the Pi-Hole website) to set up cloudflared or a similar DNS resolver which implements DoH as the backend to Pi-Hole, allowing it to use DoH when leaving your network but still act as the local network's authoritative name server.

If you choose to be a network operator, there are some additional complexities you must think about. For those (majority of) users that choose not to be network operators, DoH is nearly transparent for them and provides significantly improved security and privacy by preventing local cache poisoning, DNS injection, and DNS snooping attacks on their browsing.

Additionally, while the default in Firefox is a non-filtering endpoint currently, you can manually configure the use of a filtering DoH endpoint like those provided by CloudFlare 1.1.1.1 for Families if you wanted to do so. Nothing prevents this, and it can be configured via policies network-wide in Firefox using the enterprise policy mechanisms.

> DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS.

I still don't really understand this. Yes, it solves that problem, but how is it not also defeating the entire premise? If you had a DNS server from an adversarial network operator, they could just resolve the canary. So it means the browser's DoH is only secure if you can trust your network operator's DNS, at which point, what was its purpose supposed to be?

And the fear is that at some point someone is going to try to "correct" that by removing the check for the canary.

The user can choose to ignore the canary in the app's settings (not the default though), or they could ignore it at an OS level. And it is indeed intended to be removed and replaced with a different mechanism eventually

Right now is a transition phase, it is absolutely intended that some other mechanism becomes available in the future which is more resilient. The canary domain provides a clear pathway though for existing Do53 configurations to prevent DoH when necessary.

There's still some specific cases where DoH is problematic, but these are being eliminated over time as the technology matures. As an example of this, split horizon DNS in corporate environments is a good choice. Right now, the only realistic way to provide this is with Do53, so DoH must be disabled, but with Microsoft adding DoH support into the Windows 10 DNS Client, they are likely soon going to also support it on Windows DNS Server, which would enable businesses to make use of DoH internally and to simply set the endpoint by enterprise policies.

DoH is a few different things, but at it's most basic it's transport security for DNS, which is a fundamentally good idea any way you slice it. At some point in the future, plaintext DNS will effectively cease to exist and that's a /good thing/. There are several different implementations of encrypted DNS in the wild besides DoH (DoT and DNScrypt as examples), whichever you choose, any option that encrypts DNS both on your local network and across external networks improves privacy and security.

It takes a pretty long time to transition fundamental protocols like this, but a future where more things are sent across encrypted transports is a good future. Plaintext DNS is incredibly vulnerable, and it's also in an area which isn't heavily visible to most users, which is not a recipe for success.

The main thing I don’t want is to send all my browsing data to Cloudflare or similar “public” DNS operator outside my jurisdiction.

While I'm not glad about the current Cloudflare monopoly on encrypted DNS, and I hope more providers spring up soon, I'm inclined to think that Cloudflare are much better able to maintain privacy and resist government intervention (where possible) compared to any local operator.

Currently, Firefox only has DoH rolled out in the US, so CloudFlare is in that same jurisdiction. Additionally, all DoH providers included in Firefox must meet the Trusted Recursive Resolver (TRR) guidelines, sign a contract to that effect, and undergo third-party audits to ensure they meet the requirements.

https://wiki.mozilla.org/Security/DOH-resolver-policy

This is all publicly documented. As Mozilla rolls DoH out to other regions they will add additional TRR partners and CloudFlare won't be the only choice.

That's not an issue with overriding the system DNS. It's the point of overriding the system DNS. Content blocking by anyone but the user is a bad thing, and if you the user want it, then install uBlock Origin or something.

GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning.

For non-tech companies, replace with any relatively popular wiki.

The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.

> GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning.

They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.

Domains can be seized too, nothing is foolproof.

> They're not going to leave malware payloads sitting there. They do though, I usually check where spam emails lead me to as a curiosity, and the payload is sometimes hosted on github.

A simple GET request to https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt would work for DNS purposes.

Also, there are countermeasures for malware domains themselves, as you can report them to registrars.

As a parallel reply noted, the goal isn’t to host a payload on GitHub or a pastebin.

The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload.

Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.

I'm not fully understanding how this works. Can't the user just run their own secure DOH server and tell Firefox to use that instead?

Run your own DNS server locally. It's not that hard.

At least in my case network provided DNS are the worst, Full of spyware, and tracking.

They're referring to the local network configuration.

Many sysadmins will hate this.

> Full of spyware, and tracking.

What do you use? Google?...

I run my own networks and my own devices, I choose what options go in my DHCP server

If I were on a hostile network (say a hotel), then sure, I'll ignore their DNS server and use my own (or indeed just punch my way out via a VPN), but most of the time I use friendly networks, and I don't want to have to configure 20 different applications on a dozen different boxes to use a DNS provider of my choice. There's a reason I use DHCP in the first place.

You are able to run own network and have the know how to do so, typical physical Firefox users cannot.

Given your knowledge you can disable or even build firefox with DoH disabled , it is a sensible default for vast majority of users who do not know what DHCP is, or control their network. It cannotis trivial configuration for people who can control and do not want the DoH service provider given by Firefox.

Also many places do not allow VPN traffic either. It is not as easy to bypass monitoring in a locked down environment like typical corporate firewalls, college campuses etc. Yes for every block in place like deep packet inspection etc there is usually some workaround but these become increasingly difficult as more stringent the blocking becomes, and having options like DoH helps users who cannot or do not know how to run VPNs.

If your network allows TLS to an arbitary DOH server it allows VPN over TLS to an arbitrary server

A lot of networks block VPNs via port number + DPI, but can't really block DNS over HTTPS if it looks like a connection to any other HTTPS website.

Yes, which is why my VPNs are available on port 443 and 53, including a TLS based VPN.

Now port 53 can and often is intercepted (but sometimes it gets through when 443 doesnt)

it does not matter under what port including 443 you are running the service, deep packet inspection (DPI) can sniff out VPN traffic, perhaps you may not encountered this type of firewall as it somewhat more expensive to run both computationally and licensing wise.

It is not possible to sniff out DoH traffic via DPI as looks exactly the same as regular traffic

While running flash servers for media use in corporate environment (when flash was still a thing) back I used to run into similar problems with RTMP/ RTMPS constantly.

You can use an HTTPS "CONNECT" proxy to protect your VPN traffic in the same way (I assume that's the kind of setup they were referring to on port 443)

> Given your knowledge you can disable or even build firefox with DoH disabled , it is a sensible default for vast majority of users who do not know what DHCP is, or control their network. It cannotis trivial configuration for people who can control and do not want the DoH service provider given by Firefox.

I have mixed feelings about the issue, but it's not that simple.

I run a variety of services on my LAN for my users and guests. That includes Unbound, so even though their browser doesn't know it, their queries are secure from my ISP. But more importantly I have other stuff behind hostnames (which are resolved by Unbound). For example, my guests can navigate to music/ and use a web interface to play any of the music in my library over the stereo.

Hopefully it's obvious why this is something useful to have.

Now that Firefox is intercepting DNS requests, a conversation with someone might go like this: "Oh, it's not working? Are you using Firefox? Yeah, Firefox broke this recently, let me get the IP address for you." And then I have to log in to a computer, ssh into the relevant system, and get its IP address on the LAN.

And that's just the beginning. Last I checked Cloudflare still can't resolve the archive.is / archive.today domains. Even though I use Cloudflare over TLS in Unbound, I fix this for myself and my users by sending these domains to Google instead. Anything as convenient and simplistic as Firefox just sending everything directly to Cloudflare can't do that.

If you follow the DNS specs this will not a problem. If you use *.local for local domain names DoH will never be triggered

From Mozilla documentation.

   "localhost" and names in the ".local" TLD will never be resolved via DOH. [1]

Lan based services are pretty common use case. Mozilla is hardly going to release this feature without considering this.

The Cloudflare / Archive.is point is esoteric debate and not a common occurence, DoH does support other providers than Cloudflare so not sure if this really a major concern

[1] https://wiki.mozilla.org/Trusted_Recursive_Resolver

> If you follow the DNS specs this will not a problem. If you use *.local for local domain names DoH will never be triggered

I don't think PFsense + Unbound supports appending .local to every hostname automatically, so I'd have to change every last one of my hostnames to whatever.local and that seems like a real pain. (Surely most people are not using whatever.local in their /etc/hostname, right?)

> The Cloudflare / Archive.is point is esoteric debate and not a common occurence, DoH does support other providers than Cloudflare so not sure if this really a major concern

Sure, but my general point is that there's all sorts of different reasons why it can be useful for a LAN administrator to override the remote DNS response in certain specific cases. Given that Firefox is using Cloudflare by default, the fact that you can change it also doesn't really help anything, since after all the thing I'm specifically complaining about is that stuff randomly breaks for any of your guests using Firefox.

It is perhaps reason for you(and others) not wanting migrate, however there is nothing wrong in the way DoH functionality is implemented.

Cloudflare broke a lot of traffic when the 1.1.1.1 dns server came up, google broke lot of dev setups when they got the . dev TLD, however it is not theit fault though.

Yes it does, you set it in System > General Setup: https://docs.netgate.com/pfsense/en/latest/config/general.ht...

Then it will automatically register them in DNS with that name: https://docs.netgate.com/pfsense/en/latest/services/dns/reso...

> The domain name from System > General Setup is used as the domain name on the hosts.

Then in the DHCP configuration, you set the domain name as well (defaults to using the general setting): https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv...

> Specifies the domain name passed to the client to form its fully qualified hostname. If the Domain Name is left blank, then the domain name of the firewall it sent to the client.

The client will automatically try adding the domain when looking up hostnames. Normally on Linux the FQDN is not specified in /etc/hostname but only in /etc/hosts.

The default behaviour is to fallback to the network DNS if DoH doesn't resolve the domain, so your use case would work fine.

archive.is didn't work for Cloudflare users because they purposely sabotaged the results for Cloudflare (they did actually return valid, but wrong, results).

EDIT: Although you might have a problem if the owners of the ".music" TLD decide to put something else there.

Why should Firefox want enable users and devices to bypass network owners configuration in this way? A company should control their network, just as a home network's owner should have control.

Because Firefox represents their users' interests and not network owners' interests which are often hostile e.g. inserting ads into pages.

For the vast majority of people, "the network" is their ISP or a random hotspot, who should absolutely be treated as a hostile adversary.

How can DNS be "full of spyware"? Or are you saying that it is used for spying on you?

But anyway, it is your decision to use them - you can use 1.1.1.1 (CloudFlare), 8.8.8.8 (Google - if you don't mind the tracking) or any other DNS provider.

I don't know what GP meant with "full of spyware" but the most popular ISP in my region (Telefónica) used to redirect to pages filled with ads when a domain couldn't be resolved. Changing to 8.8.8.8 wouldn't work because it was unencrypted, they intercepted the requests and still redirected to ads. They stopped doing it some time ago but any ISP or middle man has the ability to continue doing that if they want.

Yes this is the same thing that happens with me, all unencrypted websites are redirected to adware. On phone i use 1.1.1.1 app from cloudfare but on other devices this is still issue.

Aren't all these public DNS getting unencrypted requests, so I assume ISPs snoop the domain lookups already, regardless of Google/Cloudflare/OpenDNS/Yandex doing so.

That's the point of using DoH, to avoid sending unencrypted DNS requests so your ISP can't spy or intercept those requests. If you are using unencrypted DNS from Google/Cloudflare/etc you are just adding one more party that can see your requests. If you use DoH, in theory, you are replacing who can see your requests. In practice your ISP can still know what websites you visit thanks to unencrypted SNI or if the domain you are visiting is the only one on that IP (and probably other techniques I'm not aware of). There are many more variables than just DNS requests so if you really don't want your ISP knowing what websites you visit you have no choice but to use a VPN or Tor.

It’s coming...

https://www.bleepingcomputer.com/news/microsoft/how-to-enabl...

> I want my OS to do DNS - including DOH, not my browser. I want a single source for my DNS

I'll go further and say I want my router to handle this. It is unrealistic to expect every device on my network to natively support the standard, but it's pretty easy to have your local DNS endpoint reroute the traffic through DoH on it's way out of your network. Right now I accomplish this by running cloudflared upstream of my Pihole.

"I want a single source for my DNS."

I don't like applications that do their own DNS resolution. I use a text-only browser that relies on the OS to do DNS resolution.

But imagine your DNS is filtered. Would you still want only a single source, e.g., your ISP? In that case, wouldn't you want multiple sources?

When in a DNS-filtered environment, e.g., a hotel, DOH outside the browser can actually be useful. For example, I can retrieve all the DNS data for all the domains on HN in a matter of minutes using HTTP/1.1 pipelining from a variety of DOH providers. The data goes into a custom zone file served from an authoritative nameserver on the local network. Browsing HN is much faster and more reliable when I do not need to do recursive DNS queries to remote servers. The third party resolver cache concept is still really popular, but IME most IP addresses are long-lived/static and "TTL" is irrelevant. I rarely need to update the existing RRs in the zone files I create and the number that need to be updated is very small.

DOH servers are not the only alternative source of DNS data.

Ideally, I prefer to avoid third party DNS altogether. Nor do I even need to run a local cache. I wrote some utilities that gather DNS data "non-recursively", querying only authoritative nameservers and never setting the RD bit. It is very fast. The only true "single source" of DNS data is the zone file for the particular RR at the designated authoritative nameserver(s). Everone else is a middleman.

I am not a fan of applications doing their own DNS resolution, even if they use DOH. But I have found the existance of DOH servers, i.e., third party DNS caches served over HTTP, can be useful.

I have a root hints dns sever running in my home environment. I'd prefer to control dns at os level. I also route my mobile devices through openvpn to cover when I'm not home. I control every aspect of all my devices network traffic.

What you want would make censorship and surveillance easier against the vast majority of people. Networks I'm on shouldn't be able to tell which CloudFlare-hosted site I'm visiting, or to block some of them without blocking them all. Letting the network give me a DNS resolver instead of using a known-good one would allow exactly those bad things.

So you are suggesting we further centralising the web to avoid censorship and surveilance?

How is this further centralising the Web? You can still use whatever DoH provider you want (and there's plenty of them); the choice just shouldn't be tied to the network you're on.

But you don't want it tied to a specific application either. It should be an OS level setting that lets you configure what DNS to use based on circumstance. This is possible today for power users (on Linux at least) and wouldn't be hard to implement for normal users.

This is a fair point, but the reality today is that basically every OS uses the network-provided DNS servers by default, so Firefox is completely right today to ignore the OS by default. If this ever changes such that it is common for the OS to use DoH instead of the network-provided DNS servers by default, then I'd agree that Firefox should follow the OS.

OK, what if you own the network? The corollary to that is 'you shouldn't be allowed to stop devices on your network from accessing malware, or exfiltrating data'.

Untrusted devices should be on a separate network where they don't have access to any data worth exfiltrating.

My perspective is this is my home network and this application is infringing on my freedom. I should have the right to monitor my network and my traffic. An application is a guest in my house/computer it does not set the rules.

> I should have the right to monitor my network and my traffic.

The key is that if it's really your traffic, then you can easily reconfigure Firefox so that you can monitor it. The benefit of DoH is that if someone else is using Firefox on their own computer, you can't snoop on or hijack their DNS just because they're on your network.

Cool, that makes you one of the people that's going to keep DoH turned off. What's the problem?

The internet of crap will also use DoH and bypass my network settings.

Also, it is only a matter of time before ads (and websites) start using it to bypass browser DNS:

https://github.com/byu-imaal/dohjs

Your concern about smart devices using DoH can be trivially avoided by not buying smart devices that use DoH, or even connect to the internet. Make sure that whatever you buy works with a local server such as Home Assistant and is actually under your own control. A system like this will be more reliable and customizable too.

There is no reason they couldn't have done this without DoH being an available standard. Remember, DoH is just an ordinary HTTPS request. Anyone can hide almost anything in that, including their own homemade DNS.

Sometimes you don't own the computer on which the browser is running, e.g. public web browsing kiosk. Or else you sort of own the computer, but not the DNS.

If you work in a setting in which web surfing is intercepted, and outright breaks pages, the in-browser DNS can be a godsend.

Easily doable (at least for the browser): https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

So now I have to add fake DNS records for every application that decides to do their own special snowflake thing and ignore the source of truth for what DNS server to use?

Oh joy.

I run DHCP for a reason. That reason is telling devices on my network what their settings should be. I expect those settings to be honored, not them doing the electronic equivalent of "okay boomer" and using whatever arbitrary settings they were told to by a corporation.

Software and hardware vendors need to start honoring the local configuration choices of the owner of the hardware and network. At a certain point ignoring my decisions about what can traverse my network becomes a crime and should be prosecuted as such.

The reason to run DHCP is to allow devices to be configured automatically, not to restrict how they can be configured.

You'd like Plan 9

I think in 2020 we can declare that Californian companies dictate what you can and can't do on your computer, which DNS server to use and what goes through a VPN client and what does not. The same way they decide what is a fact, what is newsworthy and what you are allowed to read / post.

"Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents."

https://news.ycombinator.com/newsguidelines.html

According to you it is a flamebait to have an observation? Ok, understood.

There are infinitely many observations. They don't select themselves. Humans do that, and not for neutral reasons [1].

Your comment was obviously trying to strike a blow for one side of a well-known argument that's going on right now. There are a few problems with that. First, blow-striking is not curious conversation; we can't have both, and HN exists for the latter [2]. Second, these arguments are so well known that the threads they lead to get increasingly predictable as they get more intense [3]. I'm sure you can see how that's bad for curious conversation too.

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[2] https://news.ycombinator.com/newsguidelines.html

[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

Reply on news.ycombinator.com