7 ms·

The thing that bothers me most about DoH is that it moves the responsibility for name resolution from the operating system to each application. So now you don'

The thing that bothers me most about DoH is that it moves the responsibility for name resolution from the operating system to each application. So now you don't have the ability to set up your own DNS server system-wide, you need to do it per-application and per-device. Assuming, of course, that the applications and devices in question allow you to do this and/or respect your choice when you do it. Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it?

creatonez 1y ago
This is not the only way to use DoH. You can setup a system-wide resolver using dnscrypt-proxy.
lokar 1y ago
Why can’t you have a forwarding resolver send out queries via http and then use it as the system default?
- Mister_Snuggles 1y ago
  There's no reason you couldn't, and this would actually be fine in my view. The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.
  - VWWHFSfQ 1y ago
    Firefox at least allows to set your own DoH resolver if you want
    - Mister_Snuggles 1y ago
      I can see a future where Chrome will use the system resolver for everything except Google's advertising domains, and those name resolutions will be impossible to block because they're going to a Google IP that may also serve services you want. Maybe Chrome would get called out for this change and they'd back it off. But I doubt that a smart TV that does this would get called out, and even if they were the response would likely be "Oh, that model is three months old and we don't do firmware updates, sorry."
      - josephcsible 1y ago
        That's not a good argument to block DoH, since once apps or devices would start doing that, they could just as easily start hardcoding the IPs instead.
      - jonhohle 1y ago
        Google already makes blocking individual services nearly impossible. Want to give kids access to Google Classroom? Auth is done through google.com so now search is unblocked. What about Google Docs? You’ve just opened all of YouTube as well.
        jonhohle 1y ago
        Just had a nice reminder that all of YouTube is accessible from Google Classroom as well.
      - kuschku 1y ago
        That's already been the case for years, and is why DoH was invented in the first place. Chromecasts hardcode DNS to 8.8.8.8, so people would redirect that traffic to their PiHole for adblocking. To "fix" that, Google introduced DoH, which is why adblocking on chromecasts is significantly harder nowadays.
  - josephcsible 1y ago
    Today, it's a good thing that applications don't respect the system defaults, since on basically every OS, the system defaults are either "totally insecure DNS all the time", or "auto fallback to insecure DNS". I'd only want programs to start respecting the system defaults if that ever changes.
    - __turbobrew__ 1y ago
      You can change the system defaults on sane OS. Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS.
      - josephcsible 1y ago
        > You can change the system defaults on sane OS. You can, but most people won't. > Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS. Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE?
        throwaway290 1y ago
        > Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE? Better analogy, should every random app bundle own custom crypto and encrypt all files and ask user for password just in case some user does not set login password? An app should do what it does, if secure storage is not its task then it probably should leave it to the os and if it's not DNS resolving then it shouldn't DNS resolve. Is very annoying
        __turbobrew__ 1y ago
        > You can, but most people won't. Who is to say that insecure defaults is less good for most people? The reason why things like FDE and other enhanced security mechanisms aren’t enabled by default is because it increases the risk of things breaking for non tech savvy people. I have had to recover installs from peoples hard drives where the messed things up and if they used FDE they would have been screwed. The reality is that it is much more likely grandma forgets her password over somebody stealing her desktop and scraping her data. It would be nice for OS vendors to create profiles for OS installs, and then people who know what they are doing can opt for the “secure” profile, but I don’t think FDE can ever be the default on mass consumer devices. > Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE? Those are different threat vectors. FDE stops intruders from accessing your system when it is locked/off. Password manager encryption is to prevent rogue processes on an UNLOCKED system. The system can solve the second problem either by having a more granular permissions system (like iOS) so that process A cannot read data of process B, or the OS can have a secure enclave which can store your secrets behind biometrics. Notably, both of these solutions are implemented in Apple world and I would argue that applications should consider using those system mechanisms instead of rolling their own encryption. If you are actually serious about security you aren’t using passwords, you are using webauthn and u2f where possible.
- PhilipRoman 1y ago
  You can, in fact that's how Arch wiki suggests doing it: https://wiki.archlinux.org/title/DNS-over-HTTPS https://wiki.archlinux.org/title/DNS-over-HTTPS
mlhpdx 1y ago
Yes, but it won’t be easy. Heavy investment has gone into HTTP and we have great tooling and support for it as a result. That has a lot of benefits and I’m glad for it. But there is a cost. HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.
- Mister_Snuggles 1y ago
  To play devil's advocate, shoving everything into HTTP/HTTPS also allowed a ton of innovation. Would video streaming sites (Youtube, Vimeo, etc) ever have gotten off the ground if they had to go to IANA to get a port number assigned, then wait for browsers to support the new protocol that runs over the new port, etc? Probably not to be honest. Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. I'm firmly convinced that shoving everything into HTTP/HTTPS was a mistake. But I'm also willing to acknowledge that it's probably the least-worst solution to a bunch of problems.
  - mlhpdx 1y ago
    Absolutely. The investment in HTTP means I can setup a website or API in a few clicks and pay nothing (or nearly so) for it. That has made it possible for me to try many, many things over the years. It’s fabulous. I would very much like to see that same freedom to innovate when using other protocols.
  - AnthonyMouse 1y ago
    > Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. Isn't this just WebRTC? Also, why does everything have to be done in a browser? We're talking about name resolution. That's supposed to be done by the OS regardless so you don't have a thousand separate configuration options to change if you want to change your DNS server.
meindnoch 1y ago
>Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But the HTTP part of HTTPS is invisible to middleboxes. They see an opaque TLS stream.
- Mister_Snuggles 1y ago
  Usually. Some middleboxes inspect the TLS session setup (e.g., SNI sniffing) and in some corporate environments they even decrypt the traffic (this relies on the endpoints having a root certificate installed that allows this functionality, which is something you'd see in a corporate environment).
  - meindnoch 1y ago
    Ok, but at that point there's zero benefit to DoH anyway.
    - jen20 1y ago
      There might be: even if my employer can decrypt traffic, there's no reason for either of my scumbag internet service providers to be able to.
bornfreddy 1y ago
Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity? Of course, Cloudflare (if page uses them) and Google (if you are not blocking their remote fonts & js) also already have this information, so there's that.
- josephcsible 1y ago
  > Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity? Because a lot of sites are behind a CDN that makes such guessing infeasible, and can use ECH to block the SNI leak. And since your ISP knows your real identity and other personal info like physical address, it's better privacy-wise for them not to be the ones who know exactly which sites your IP is visiting.
  - bornfreddy 1y ago
    TIL about ECH [0], thank you! [0] https://developers.cloudflare.com/ssl/edge-certificates/ech/ https://developers.cloudflare.com/ssl/edge-certificates/ech/
josephcsible 1y ago
> Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it? It'd be great for the horrible ISPs and middleboxes to change, but that's not realistic, and working around it by wrapping everything in HTTPS is realistic.
eckelhesten 1y ago
That’s incorrect. I use DNSecure (iOS app) to relay all DNS traffic on my iPhone to my DNScrypt-proxy server which I host on the internet (make sure you know what you do before exposing DNS servers on the internet). It’s awesome because I have system wide tracker/adblocking which works whether or not I’m on my LAN and even with Apple Private Relay on.
- eckelhesten 1y ago
  And in case it wasn’t clear. Yes it’s DNS-over-HTTPs and no one except my server and njal.la know about my queries.
- Mister_Snuggles 1y ago
  How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)? This is what DoH looks like from outside the application. You can't really tell that it's DoH since it's just an HTTPS connection, which is kind of the whole point of it.
  - nerdsniper 1y ago
    Yep with applications hardcoding addresses and utilizing certificate pinning, there's nothing the device owner/homeowner/network admin/system admin can do to inspect or modify DNS over HTTPS traffic, other than uninstall the application or block the connection entirely. Increasingly, blocking connections breaks the app so you almost might as well just uninstall the app or block it from being installed on managed endpoints.
  - eckelhesten 1y ago
    Theoretically you could domainblock known DoH servers that certain applications would use. But yes, I believe that if an application try hard enough there are ways to bypass any set of rules you set on a device. Luckily, most applications just use the internal libresolv for any domain resolving needs.
  - 1y ago
marcosdumay 1y ago
> But shouldn't we fix the ISPs and middleware instead Well, good luck with that. I say we formalize an entire internet tunneled over HTTPS and throw some eggs on the face of those people.
- AnthonyMouse 1y ago
  HTTP3/QUIC is on the path for this because once you have "HTTPS" over UDP, the next thing that happens is you mark all of the actual HTTP bits as optional to implement since the middlebox can't see them and just run a datagram TLS VPN over port 443 to tunnel whatever you want.
camhart 1y ago
Windows, mac, ios, chrome os all support DOH at the OS level to some degree. Android supports limited, preset DOH resolvers only.
anonymousiam 1y ago
I have the same gripe about QUIC, but nobody seems to care. QUIC moves part of the network stack into the application layer.
- tptacek 1y ago
  That's a good thing.
  - anonymousiam 1y ago
    Please elaborate. Why is it "good" to have a separate network stack element in each application, and what does this mean for legacy applications that will never support QUIC?
    - tptacek 1y ago
      Because different applications have different needs and there is nothing intrinsically safer or better about having the stack be kernel-resident and, in fact, a lot to recommend moving things out of the kernel and into userland, which has a better application cotenancy model (full cr3 context switches between different users).
      - anonymousiam 1y ago
        Circumventing the role of the operating system in the name of improved efficiency and duplicating a once-centralized function in (some) applications doesn't seem like a well thought out course of action. Why have an operating system at all? Why not just boot your computer to each application you want to run, as was done on the early PCs of the 1980's? Perhaps we shouldn't use computers to run our applications anymore. Everything could run on a gaming console. That would certainly be more efficient for the applications.
        tptacek 1y ago
        "The role of the operating system" is whatever we decide it is. The operating system exists to serve applications, not the other way around. This isn't an aesthetic thing; it's an engineering choice. Moving parts (or all) of the networking stack into userland is often better engineering, for the reasons I just supplied, any of which I'm happy to go further into.
jlaporte 1y ago
> it moves the responsibility for name resolution from the operating system to each application Browsers only took on DoH implementation directly because they were solving the cold-start problem for a new protocol. Nothing to do with the spec. There is support for DoH in all major OSs today, but none have made it a simple box to click AFAIK (we could speculate why). For macOS, iOS, either via Private Relay (paid) or a configuration profile. Premade profiles: * https://github.com/paulmillr/encrypted-dns https://github.com/paulmillr/encrypted-dns For Windows > In the Registry Editor window open: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters > Right-click within the “Parameters” folder and create a new Dword (32-bit) Value. Name this new file “EnableAutoDOH” and set its value to “2.” * https://superuser.com/posts/1764668/revisions https://superuser.com/posts/1764668/revisions Linux: * https://dev.to/mfat/how-to-enable-system-wide-dns-over-https-on-fedora-linux-og7 https://dev.to/mfat/how-to-enable-system-wide-dns-over-https...
gsich 1y ago
This is only because applications think they should do that. There is nothing against a DoH client in the OS, I think Windows and MacOS already supports it.

creatonez 1y ago

This is not the only way to use DoH. You can setup a system-wide resolver using dnscrypt-proxy.

lokar 1y ago

Why can’t you have a forwarding resolver send out queries via http and then use it as the system default?

Mister_Snuggles 1y ago
There's no reason you couldn't, and this would actually be fine in my view. The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.
- VWWHFSfQ 1y ago
  Firefox at least allows to set your own DoH resolver if you want
  - Mister_Snuggles 1y ago
    I can see a future where Chrome will use the system resolver for everything except Google's advertising domains, and those name resolutions will be impossible to block because they're going to a Google IP that may also serve services you want. Maybe Chrome would get called out for this change and they'd back it off. But I doubt that a smart TV that does this would get called out, and even if they were the response would likely be "Oh, that model is three months old and we don't do firmware updates, sorry."
    - josephcsible 1y ago
      That's not a good argument to block DoH, since once apps or devices would start doing that, they could just as easily start hardcoding the IPs instead.
    - jonhohle 1y ago
      Google already makes blocking individual services nearly impossible. Want to give kids access to Google Classroom? Auth is done through google.com so now search is unblocked. What about Google Docs? You’ve just opened all of YouTube as well.
      - jonhohle 1y ago
        Just had a nice reminder that all of YouTube is accessible from Google Classroom as well.
    - kuschku 1y ago
      That's already been the case for years, and is why DoH was invented in the first place. Chromecasts hardcode DNS to 8.8.8.8, so people would redirect that traffic to their PiHole for adblocking. To "fix" that, Google introduced DoH, which is why adblocking on chromecasts is significantly harder nowadays.
- josephcsible 1y ago
  Today, it's a good thing that applications don't respect the system defaults, since on basically every OS, the system defaults are either "totally insecure DNS all the time", or "auto fallback to insecure DNS". I'd only want programs to start respecting the system defaults if that ever changes.
  - __turbobrew__ 1y ago
    You can change the system defaults on sane OS. Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS.
    - josephcsible 1y ago
      > You can change the system defaults on sane OS. You can, but most people won't. > Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS. Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE?
      - throwaway290 1y ago
        > Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE? Better analogy, should every random app bundle own custom crypto and encrypt all files and ask user for password just in case some user does not set login password? An app should do what it does, if secure storage is not its task then it probably should leave it to the os and if it's not DNS resolving then it shouldn't DNS resolve. Is very annoying
      - __turbobrew__ 1y ago
        > You can, but most people won't. Who is to say that insecure defaults is less good for most people? The reason why things like FDE and other enhanced security mechanisms aren’t enabled by default is because it increases the risk of things breaking for non tech savvy people. I have had to recover installs from peoples hard drives where the messed things up and if they used FDE they would have been screwed. The reality is that it is much more likely grandma forgets her password over somebody stealing her desktop and scraping her data. It would be nice for OS vendors to create profiles for OS installs, and then people who know what they are doing can opt for the “secure” profile, but I don’t think FDE can ever be the default on mass consumer devices. > Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE? Those are different threat vectors. FDE stops intruders from accessing your system when it is locked/off. Password manager encryption is to prevent rogue processes on an UNLOCKED system. The system can solve the second problem either by having a more granular permissions system (like iOS) so that process A cannot read data of process B, or the OS can have a secure enclave which can store your secrets behind biometrics. Notably, both of these solutions are implemented in Apple world and I would argue that applications should consider using those system mechanisms instead of rolling their own encryption. If you are actually serious about security you aren’t using passwords, you are using webauthn and u2f where possible.
PhilipRoman 1y ago
You can, in fact that's how Arch wiki suggests doing it: https://wiki.archlinux.org/title/DNS-over-HTTPS https://wiki.archlinux.org/title/DNS-over-HTTPS

mlhpdx 1y ago

Yes, but it won’t be easy. Heavy investment has gone into HTTP and we have great tooling and support for it as a result. That has a lot of benefits and I’m glad for it. But there is a cost. HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.

Mister_Snuggles 1y ago
To play devil's advocate, shoving everything into HTTP/HTTPS also allowed a ton of innovation. Would video streaming sites (Youtube, Vimeo, etc) ever have gotten off the ground if they had to go to IANA to get a port number assigned, then wait for browsers to support the new protocol that runs over the new port, etc? Probably not to be honest. Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. I'm firmly convinced that shoving everything into HTTP/HTTPS was a mistake. But I'm also willing to acknowledge that it's probably the least-worst solution to a bunch of problems.
- mlhpdx 1y ago
  Absolutely. The investment in HTTP means I can setup a website or API in a few clicks and pay nothing (or nearly so) for it. That has made it possible for me to try many, many things over the years. It’s fabulous. I would very much like to see that same freedom to innovate when using other protocols.
- AnthonyMouse 1y ago
  > Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint. Isn't this just WebRTC? Also, why does everything have to be done in a browser? We're talking about name resolution. That's supposed to be done by the OS regardless so you don't have a thousand separate configuration options to change if you want to change your DNS server.

meindnoch 1y ago

>Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But the HTTP part of HTTPS is invisible to middleboxes. They see an opaque TLS stream.

Mister_Snuggles 1y ago
Usually. Some middleboxes inspect the TLS session setup (e.g., SNI sniffing) and in some corporate environments they even decrypt the traffic (this relies on the endpoints having a root certificate installed that allows this functionality, which is something you'd see in a corporate environment).
- meindnoch 1y ago
  Ok, but at that point there's zero benefit to DoH anyway.
  - jen20 1y ago
    There might be: even if my employer can decrypt traffic, there's no reason for either of my scumbag internet service providers to be able to.

bornfreddy 1y ago

Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity? Of course, Cloudflare (if page uses them) and Google (if you are not blocking their remote fonts & js) also already have this information, so there's that.

josephcsible 1y ago
> Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity? Because a lot of sites are behind a CDN that makes such guessing infeasible, and can use ECH to block the SNI leak. And since your ISP knows your real identity and other personal info like physical address, it's better privacy-wise for them not to be the ones who know exactly which sites your IP is visiting.
- bornfreddy 1y ago
  TIL about ECH [0], thank you! [0] https://developers.cloudflare.com/ssl/edge-certificates/ech/ https://developers.cloudflare.com/ssl/edge-certificates/ech/

josephcsible 1y ago

> Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it? It'd be great for the horrible ISPs and middleboxes to change, but that's not realistic, and working around it by wrapping everything in HTTPS is realistic.

eckelhesten 1y ago

That’s incorrect. I use DNSecure (iOS app) to relay all DNS traffic on my iPhone to my DNScrypt-proxy server which I host on the internet (make sure you know what you do before exposing DNS servers on the internet). It’s awesome because I have system wide tracker/adblocking which works whether or not I’m on my LAN and even with Apple Private Relay on.

eckelhesten 1y ago
And in case it wasn’t clear. Yes it’s DNS-over-HTTPs and no one except my server and njal.la know about my queries.
Mister_Snuggles 1y ago
How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)? This is what DoH looks like from outside the application. You can't really tell that it's DoH since it's just an HTTPS connection, which is kind of the whole point of it.
- nerdsniper 1y ago
  Yep with applications hardcoding addresses and utilizing certificate pinning, there's nothing the device owner/homeowner/network admin/system admin can do to inspect or modify DNS over HTTPS traffic, other than uninstall the application or block the connection entirely. Increasingly, blocking connections breaks the app so you almost might as well just uninstall the app or block it from being installed on managed endpoints.
- eckelhesten 1y ago
  Theoretically you could domainblock known DoH servers that certain applications would use. But yes, I believe that if an application try hard enough there are ways to bypass any set of rules you set on a device. Luckily, most applications just use the internal libresolv for any domain resolving needs.
- 1y ago

marcosdumay 1y ago

> But shouldn't we fix the ISPs and middleware instead Well, good luck with that. I say we formalize an entire internet tunneled over HTTPS and throw some eggs on the face of those people.

AnthonyMouse 1y ago
HTTP3/QUIC is on the path for this because once you have "HTTPS" over UDP, the next thing that happens is you mark all of the actual HTTP bits as optional to implement since the middlebox can't see them and just run a datagram TLS VPN over port 443 to tunnel whatever you want.

camhart 1y ago

Windows, mac, ios, chrome os all support DOH at the OS level to some degree. Android supports limited, preset DOH resolvers only.

anonymousiam 1y ago

I have the same gripe about QUIC, but nobody seems to care. QUIC moves part of the network stack into the application layer.

tptacek 1y ago
That's a good thing.
- anonymousiam 1y ago
  Please elaborate. Why is it "good" to have a separate network stack element in each application, and what does this mean for legacy applications that will never support QUIC?
  - tptacek 1y ago
    Because different applications have different needs and there is nothing intrinsically safer or better about having the stack be kernel-resident and, in fact, a lot to recommend moving things out of the kernel and into userland, which has a better application cotenancy model (full cr3 context switches between different users).
    - anonymousiam 1y ago
      Circumventing the role of the operating system in the name of improved efficiency and duplicating a once-centralized function in (some) applications doesn't seem like a well thought out course of action. Why have an operating system at all? Why not just boot your computer to each application you want to run, as was done on the early PCs of the 1980's? Perhaps we shouldn't use computers to run our applications anymore. Everything could run on a gaming console. That would certainly be more efficient for the applications.
      - tptacek 1y ago
        "The role of the operating system" is whatever we decide it is. The operating system exists to serve applications, not the other way around. This isn't an aesthetic thing; it's an engineering choice. Moving parts (or all) of the networking stack into userland is often better engineering, for the reasons I just supplied, any of which I'm happy to go further into.

jlaporte 1y ago

> it moves the responsibility for name resolution from the operating system to each application Browsers only took on DoH implementation directly because they were solving the cold-start problem for a new protocol. Nothing to do with the spec. There is support for DoH in all major OSs today, but none have made it a simple box to click AFAIK (we could speculate why). For macOS, iOS, either via Private Relay (paid) or a configuration profile. Premade profiles: * https://github.com/paulmillr/encrypted-dns https://github.com/paulmillr/encrypted-dns For Windows > In the Registry Editor window open: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters > Right-click within the “Parameters” folder and create a new Dword (32-bit) Value. Name this new file “EnableAutoDOH” and set its value to “2.” * https://superuser.com/posts/1764668/revisions https://superuser.com/posts/1764668/revisions Linux: * https://dev.to/mfat/how-to-enable-system-wide-dns-over-https-on-fedora-linux-og7 https://dev.to/mfat/how-to-enable-system-wide-dns-over-https...

gsich 1y ago

This is only because applications think they should do that. There is nothing against a DoH client in the OS, I think Windows and MacOS already supports it.