Migrate Everything from Linux to BSD
unixsheikh.com
unixsheikh.com
This is emotion-driven drivel.
He pumps out really high quality software (seriously, read some of his source code it’s really easy to hack on), is genuinely innovative, and all people seem to do is shit on him and make him out like he’s some Linux daemon laughing manically every time a sysadmin gets frustrated.
Anyone who uses the phrase “potteringware” please listen to him talk at any conference he speaks at like All Systems Go. He really is down to earth and really thinks through problems before tackling them.
Say, "let's do away with the old Unix ways, and build a new, much better userland!"
People at least would expect the radical change of the direction which is taking place.
I like Linux, but I have mixed feelings about systemd, especially when I discovered that systemd runs its own DNS server, which prevents the DNS server I wrote from binding to port 53 using INADDR_ANY. Instead, I had to write code to enumerate the interfaces & corresponding IP addresses & bind to each one separately. Systemd's decision to run their own DNS server is a bit of overreach, IMHO.
It's like, yeah, that's a funny thing to also live in systemd.git, but systemd-resolved is functionally a separate product from systemd.
So when asked if I like systemd, it's a loaded question. It's great but absolutely sucks, both.
[note] It describes itself as "a suite of basic building blocks for a Linux system" - although in my opinion that implies more modularity than it posesses.
Principles aside, in reality, systemd has been a complete non-issue for me and a massive quality of life improvement for Linux as a desktop operating system.
Is it not possible to turn off things like systemd’s DNS server, etc? I imagine if you care about such things you should be able to reconfigure your OS to use something else instead.
It is possible to disable stuff like systemd-resolved or systemd-timesyncd but it takes extra work which should be done by installing another package that accomplishes the same task (unbiound, chrony) just like as one MTA replaces another on Debian.
However, you ask a good question. Lots of people do like it, supposedly. But I think there's a large clue to its controversial nature in that people still call it an "init system", and pointing out that it isn't is interpreted by some as an attack.
Basically, it started out as an init system, which was used by Red Hat / Fedora, which was positioned well at a time when certain distros, notably Debian, used crufty SysV init scripts which they wanted to move on from. When Debian adopted systemd, after some debate, every Debian-based distro did too. This wasn't considered a particularly invasive change at the time. But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Distros which adopted systemd found themselves along for the ride, while distros that didn't increasingly found that software was starting to break, forcing them to maintain forks, or chisel out the piece of systemd that made it work and run it standalone. So was created a network effect that forced even more distros down the path of least resistance into systemd.
Meanwhile, amidst all the grumbling that this bait-and-switch was provoking, the systemd project leaders had an astonishingly bad attitude towards the maintainers of software that they were breaking, which fomented considerable personal animosity on top of the technical resentment. Not only were they driving a horse and cart through the standard ways of doing things, breaking a lot of stuff in the process, they were being rude about it.
So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
Your timing is off. udev became part of systemd in 2012. The big Debian debate was in 2013-2014, and was acrimonious enough to eventually cause several of the CTTE members to resign their position over it. One of the core issues driving the Debian systemd debate was the fact that GNOME was planning on dropping support for anything other than systemd-logind (or something like that), and there was definite concern that packages were already making decisions that were forcing everyone to adopt systemd as the only init system.
I eagerly await the publication of "SystemD: A History" and its subsequent adaptation into a dramatic screenplay.
Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html
Among other things, it talks about:
-deferring launch of some services until they are needed, to speed up boot
-launching additional services and shutting down others in response to hardware changes (e.g. adding a usb device).
-taking some or all socket management away from daemons so that sockets can be ready before daemons are live or daemons can be shut down when there is no activity
-“babysitting” services including through cgroup based process management
-managing (some of the) access to /home and other directories
It’s quite a broad scoped announcement. Toward the end there is a “short list of other features”, numbered, ending at 20. Under “Where is this going?” he writes, “ The feature set described above is certainly already comprehensive. However, we have a few more things on our plate.”
systemd clearly started out as a broad based solution, and reading through that post, looking at the problems it addresses, and considering that launchd and upstart tackled similarly many issues, it’s clear why it is so broad - the world has changed. In the 70s on a pdp 11 it was sufficient to launch some daemons at boot, keep an eye on getty, and call it a day. Maybe ~50 years later a new, more comprehensive system makes sense? When Linux runs laptops and phones that are endlessly reconfiguring themselves in response to network, Bluetooth, usb, when systems are sleeping and waking routinely, when vastly more services run on a single machine, when conserving battery is important, when boot time can be reduced to seconds if things are better orchestrated? “standard ways of doing things” have changed in every other sector of society, basically, why wouldn’t they finally change in OS service management?
Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now.
systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.
It was pretty invasive - I tried to keep using Debian without systemd, but indirect dependencies always brought it in. Until I switched to Devuan.
And the dependencies brought in EVERYTHING. You could no longer mix and match, pick one part from here if it worked for you, and another part from there.
Which lead to the criticism that "systemd is not modular". Which Poettering denied, pointing out that there are modules at systemd-compile time, completely missing the point.
> So, more or less, people resent systemd because it's difficult to find - or build - a distro without it.
And I wouldn't have minded systemd as an INIT SYSTEM - the existing scripts WERE pretty bad. But systemd is like the Borg - it tries to assimilate everything. And it broke quite a bit of existing functionaility along this path.
Red Hat produced systemd. Red Hat is the major contributor to Gnome. Gnome now refuses to run without systemd. Every major distro wants to carry Gnome, so...
Well, at least some distros offer a choice. Some other distros (Alpine, popular for containers, Void, which powers my laptop) live happily without it. Various shims exist, logind exists to allow running things like Xfce without systemd.
Is that true? The gentoo documentation says that you can chose your init system independently of your desktop manager, and puts openrc+gnome as an example:
https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd/Gen...
You can also install GNOME on OpenBSD, which of course does not run systemd.
> After the transition from GNOME 2 to GNOME 3, configuring GDM is only possible through systemd as it no longer supports other init systems.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
You can see the same effect in e.g. politics.
It's one of those situations where the minority that doesn't like systemd is just a lot more noisy than the vast majority that likes it.
Easy as that.
The majority of people don’t give a hoot about it.
The short answer is...Red Hat has money and threw it behind systemd. Like them or hate them, they are in many ways the deciding fate of Linux systems. So, other distros fall in line. Ubuntu is a contender, but gave in and followed suit too.
Void and Solus are both good distros that don't use systemd. I'd go as far as to call Solus the best out of the box distro ive ever used.
IIRC the required parts of systemd are pretty much init-related, service-related (as in starting/stopping services based on certain conditions), udev and journald (which can and is often defaulted to forward to syslog).
Comments like yours make it seem like resolved, homed, nspawn, machinectl, networkd, cgtop, and all of the other utilites and optional daemons are required. They seem more like konquerour in your KDE analogy as in that they are nice if you want to buy into the whole ecosystem but by no means required to use the core program (and many seem to use alternatives instead).
I'm by no means an expert on this, so please correct me if I'm wrong.
I wrote a personal blog post about this (https://www.turek.dev/posts/disable-systemd-resolved-cleanly...) to try to help people out.
I suppose you could do that. although I prefer: systemctl disable systemd-resolved systemctl mask systemd-resolved
Then it's dead and will stay that way.
Does systemd want to be an init system? A logging system? a dnsmasq replacement?
Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.
'Doing many things, none of them well' is actually the opposite of UNIX.
Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX".
This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.
There is nothing bad about it. What I find bad is forcing everyone to jump on the same bandwagon, no matter which bandwagon. If I wanted choices made for me, I'd buy a Mac.
Nobody says things like "what is GNU? Is it a kernel, a compiler, a libc, a build system, a set of userspace tools?".
Likewise, the systemd project has many utilities under its umbrella, and most of them are completely optional.
What does all systemd software have in common? What's the unifying principle there?
Each distro used to have to roll their own initscript system (with varying degrees of compatibility), so they made `systemd`. Each distro had their own init script to save/load the backlight state, so they made `systemd-backlight` (if you're going to replace the initscript system, you'll also have to replace the things that the initscripts for that system did). Each distro used to have to roll their own network configuration scripts (Debian's /etc/network, Arch Linux's netcfg and later netctl, ...), so they made `systemd-networkd`.
Some of this class of thing got picked up by other projects; each distro used to have to roll its own initramfs system; today Dracut exists, so systemd won't be doing that (unless the Dracut folks decide to team up with the systemd folks--remember gummiboot? gummiboot renamed to systemd-boot).
In one of your other comments you wrote "in my opinion that implies more modularity than it posesses." While there are some nasty couplings (it'll take some patching to get systemd-nspawn to work on a non-systemd system), you can successfully use many of the systemd modules on an OpenRC system; it is a lot more modular than people give it credit for.
[0] https://www.freedesktop.org/software/systemd/man/systemd-res...
It wasn't quite the solution I was looking for. I wanted my DNS server to "just work" for people who downloaded it—I didn't want to force them to re-configure systemd to accommodate my software.
Tweaking my software to accommodate systemd.resolved took ~4 hours. It was an enjoyable dive, but I'd rather not have had to do it on the first place.
I continue to think it's a bit of an overreach for Fedora to include a DNS server by default.
systemd-resolved is a separate project from systemd whose only relation is that it’s in the same repo. It’s up to your distro builder to decide if they want to use it. And also up to your distro if they want to use the stub resolver. It’s not necessary for systemd-resolved to work. The reason they have the stub listener is because on Linux every application is supposed to use glibc nss to resolve names but there are real-world applications that try, incorrectly, to parse resolv.conf and do dns queries themselves. This breaks things if your assumption is that all dns queries are going through systemd-resolved. And this project isn’t the first. Ubuntu and others have used dnsmasq as the stub resolver for the same reason. Using just the dns nss module and resolv.conf is fundamentally broken and at this point unfixable when you are connected to multiple networks or with separate dns or split tunnel VPNing. You have to provide your own, smarter, nss module and/or use a stub resolver to cover these use-cases.
The nice thing about systemd-resolved is that it make enabling split-tunnel vpns a breeze.
Do Linux users really want their year on the desktop, or will they keep complaining at any change to get there?
Worth a shot! https://distrowatch.com/table.php?distribution=artix
It’s actually quite an astute observation. I read recently that there are over 600 Linux distros and only about 500 are actively maintained.
> Web developers who use Google Analytics are stupid.
The adjective is wrong, but it’s also fair to say that there are free solutions for analytics, and some may go straight to using GA when they don’t need to.
How old are you? Everyone knows there are many Linux distros. Distrowatch has existed for almost 20 years. The issue isn't the number of distros; it's the marketshare. There are only a few distros with significant usage. The fact that there are many others is irrelevant because no one uses them.
Because of the fragmentation, I don't have to use systemd, or pulseaudio, or snap, or Gnome desktop, or most other things I don't want to use for whatever reason. I can configure my box (or my container) mostly the way I see fit.
If you want ultimate unification, choose macOS. These guys are certain that they know what you need, and rid you of the need to choose. If you want a bit less strict unification but with backwards compatibility, choose Windows.
BSD sees less fragmentation mostly because it's less widely used. Though FreeBSD, OpenBSD, NetBSD, DragonflyBSD, and even Darwin exist, and differ significantly form each other. The BSD land, fortunately, also offers choice.
I think part of the very reason some folks like you don't like to use some of those things is their shortcomings... which likely come about in part due to the plethora of choices leading to fragmented efforts on the development side. People shift their attention to the newer/shinier things all the time, and nothing ends up becoming rock-solid to the point where you wouldn't even think about wanting to replace it.
To put this into perspective, consider how bizarre it would be to hear end-users complain "What if I want to replace the Windows Audio/Task Scheduler/etc. service with something else?" in Windows land.
Linux has always been about software freedom and open source, it was never about choice. When people made it about choice, infinite fragmentation started and there's no end in sight.
Though with their shortcomings, thankfully somebody is fighting against that concept, and trying to build a stable base for everybody.
Of course this leaves the door open for "choice", but it's just, in my opinion, an unfortunate side effect.
That is explicitly about choice.
Pretending that freedom of choice about what people spend their free time on is "an unfortunate side effect", is what represents a "toxic" attitude in my opinion.
And people have tried a LOT to replace stuff in Windows, it is just that Microsoft doesn't make it as easy as on Linux.
In Windows Vista, Microsoft rebuilt the audio stack on top of WASAPI, making MME and DirectSound shims which feed into WASAPI. However, they didn't break compatibility, and all APIs more-or-less work nowadays. On Linux, ALSA apps sometimes have trouble picking the right device when talking to PulseAudio, and it's difficult for PulseAudio and Jack to share a single device.
And it was great when it worked, I tell you that!
So yes, they did break compatibility.
I would gladly replace the window manager and the desktop manager in Windows. It is even possible.
24 mentions of systemd and 0 mentions of the word "jails", come on, you're not even trying.
Ten year old FUD. Most distros are on systemd now. Whatever you want to say about systemd, it's definitely not fragmentation. Also there's the freedesktop project and dbus which creates a standard API for desktop applications. All Linux distros use glibc and GNU coreutils. Where's the fragmentation?
Linux desktop applications are all very fragmented and broken (GNOME, KDE, 100 different tiling window managers, 100 different music players that all suck), but that's not Linux, that's userspace.
> Torvalds has a bad opinion on ZFS
Doesn't matter. ZFS on Linux still works. Also ZFS is not immune to criticism. BTRFS is getting better and is more than adequate for everyone who is not running a CDN. Also ZFS isn't exactly usable on all BSDs, just FreeBSD (nor did FreeBSD come up with ZFS in the first place (why not migrate everything to Solaris then?)).
> Linux is being heavily influenced by corporate interests
Good. Problem? The computer is a tool not a political bumper sticker. I'm happy to use something for free that developers are paid to improve and that I still have complete control over. Linux [Android] is the most widely deployed OS in the world. It's constantly improving and lots of eyes are on the code. There just aren't enough skilled volunteers to maintain a giant codebase as critical as an OS.
https://madaidans-insecurities.github.io/openbsd.html
When BSD is used by corporations, they fork it and make their improvements proprietary.
> Time to migrate everything to BSD
Then almost everything I do with my computer would be impossible except for dicking around in a web browser. How do I run containers, modern hardware, or CUDA? Hard mode: No Linux emulation.
See, I get where you are coming from, and I use Linux myself, but I feel that the author sees this as the fragmentation problem. One of the author's points is that the division between userspace and kernel is a problem, and the *BSDs offer up full operating systems, not just kernels.
From TFA: "Linus Torvalds has many times made it very clear that he doesn't care about what goes on in the "Linux world", all he cares about is the kernel development"
Otherwise, yeah... BSD is a great choice for some stuff, but it certainly falls short of the tools available to a Linux environment.
Agree on all your other comments, but BSD jails and Solaris zones were a thing long before Docker made it mainstream on Linux.
I would have installed BSD on one of my primary dev laptops by now, but there's one huge software compatibility missing for me:
https://wiki.freebsd.org/Docker
Docker's currently broken.
I still don't understand why Docker was not made to run on jails as well.
However, BSD's do not guarantee that their userlands will work with a mismatched kernel. Sure, it often does work, hence why jails only give a warning on mismatch rather than refuse to run at all.
Also containers are most useful when most containers you want are actually available for your platform. Unless you use the Linux Emulation features, I'd suspect that relatively few containers would be mode available to run on FreeBSD. And the problem with Linux personality systems is that while many programs will work fine with them, there will always be some Linux syscalls that are unimplemented, or have important limitations/differences. So while many programs may work, some will not work. Even if the system call is fully supported, not all use cases will be. For example, not every file system Linux supports will be mountable, and programs could be using loopback mounts that need such support for weird reasons (I'd bet has made an app-bundle system for linux that relies on loopback mounting ext4).
There is a reason why Microsoft abandoned the personality like implementation of WSL1 in favor of virtualization for WSL2. Now admittedly, things are not nearly as bad on FreeBSD, since implementing one Unix-like personality in a different Unix is going to be easier and work better than trying to implement it on a decidedly non-Unix kernel. But even so, there will always be some programs (however obscure) that won't work right, while virtualization can largely avoid that. (Albeit with new limitations like not being able to easily access host hardware).
Noth of the above is at all a dealbreaker. containerd and docker support windows containers which have many of the above mentioned concerns, and many additional ones like the restrictions on distributing the windows base images.
What really needs to happen for jail support for docker is to come up with the FreeBSD specific options for the OCI spec, implement an OCI runtime based on jails, add support for setting the OS specific options in containerd, and implement needed network support in dockerd. (containerd leaves networking setup to its caller, as docker has different opinions than kubernetes for example).
The containerd people will almost certainly not object to the needed patches. If I had to guess, the docker maintainer's big concerns over a moby patch will be the overhead of supporting the needed patches (since FreeBSD will rightfully be seen as far more niche than Linux), and that the end-user experience of various docker command lines work more or less as users expect. (I.e. not more different from docker-on-linux than docker-for-windows-containers is). None of this is at all insurmountable.
FWIW, FreeBSD tends to go to pretty great lengths to ensure newer kernel with older userland works. A stock GENERIC kernel comes with COMPAT_FREEBSD* options back to COMPAT_FREEBSD4, and parts of the project's infrastructure tend to explicitly rely on at least supported releases to be functional in a jail on a -CURRENT kernel.
Windows for example makes zero guarantees there. There are a lot of syscalls that they won't renumber because some applications have taken a dependency on using them directly, but officially using a syscall without going through NTDLL (or wherever the stub is located for private syscalls) is unsupported. Those syscalls they are not keeping fixed for compatibility can and do change from version to version. Mostly in numbering, but changes to semantics or arguments can happen too. Hence Windows Containers can only run in separate namespaces on a matching kernel version, and the hyper-v isolation (a.k.a. virtualization) option for containers is needed for mismatched versions.
So creating an OCI runtime that wraps jails, adding any needed support for FreeBSD specific OCI container settings to containerd, and adding the needed code for things like networking to moby/moby (a.k.a. docker) sounds very feasible to me if some FreeBSD hacker wanted to get proper docker support. Offering Linux Emulation as an experimental option top be able to run more containers would be an added bonus, and should be feasible, since they once had that working with their old unofficial (presumably pre-containerd) builds of docker.
Companies are free to do whatever they want with BSD and as such they don't need to try to affect the way things are going. If that wasn't the case we would possible see, for example, Sony trying very hard to influence the development of FreeBSD because they use that in their PlayStation products.
I think this is the biggest incentive companies have for making contributions to open source: they don't want to pay engineers to keep maintaining their own patches forever.
The end result is lots of companies jamming their code upstream because it is cheaper (or they are soft-required) to do so, not because it is good for the project. The benefit is you have large corporate contributions, with the possible downside that the companies want to take your software in a different direction than you do (i.e. Microsoft embracing/extending).
The BSD license doesn't try to strongarm people into contributing, and the BSD projects are open to being a base for other projects. This is bad because companies may not contribute back to you. It is good because it means that you don't have 20 companies pressuring you do make decisions. They've gone in their 20 directions and they want you to continue to be a solid base for them to build on.
I think a lot of people (me included) like the feel of this way more. When you read through FreeBSD you don't see the legacy code from a bunch of corporations mixed in, you just see the good stuff. People contribute because they want to even though it's more work, versus reluctantly contributing because it's less work. Not saying permissive licenses are perfect and don't have their own problems, just explaining why they might have different advantages.
It's about project management, not licenses.
Linux is very, very much more coherent than that chaos.
I find it mildly ironic that MacOS was based on BSD.
While I will never use these methods, and I think they are completely flawed ideas, I think the goal of them is a natural evolution of fragmented similar systems.
The BSDs have the same problem as linux distributions. The open source BSDs share a lot of code but aren't quite the same. If several of them got very popular, someone would attempt to make a method to distribute software across all of them. Though in BSD this is harder because in linux land at least the kernel is standardized.
Actually I always found it funny and a little brave that Linus called ZFS a buzzword. In my opinion he’s right. ZFS breaks a lot of use cases but unless you know what you’re talking about you’re going to think it’s the end-all. I slightly prefer the MD-RAID system.
option('dns-servers', type : 'string',
description : 'space-separated list of default DNS servers',
value : '1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700::1111 2001:4860:4860::8888 2606:4700:4700::1001 2001:4860:4860::8844')
option('ntp-servers', type : 'string',
description : 'space-separated list of default NTP servers',
value : 'time1.google.com time2.google.com time3.google.com time4.google.com')
Seems like Cloudflare primary then Google primary (followed by the secondary records in the same order) is the preferred default order for both IPv4 and IPv6.
Traditionally, it's your ISP who gets to see your and all their users' DNS lookups.
But now it's Google (on top of your ISP) and Cloudflare (on top of with 1.1.1.1 and instead of your ISP for DNS-over-HTTPS), and the claim is that they are going to misuse the data (well, it's pretty much a fact for Google).
I am generally not in favour of any siloing and centralisation of that scale, but if you want private DNS, your options are quite limited.
I also wonder if it'd make sense to bundle a simple DNS-over-Tor service or would that be easy to track? I'd run it on my openwrt router.
List of public DoH Servers: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Serv...
Simple guide for DoH over Tor: https://github.com/piskyscan/dns_over_tls_over_tor
I don't consider 10+ public, free DoH servers as "quite limited".
Private communication is something that only the two (or more) parties communicating are privy to.
With HTTPS, the risk is reduced to CA compromise. With DoH, the risk is the company running the service on top of the CA compromise.
The parties communicating are the root/TLD name servers and me. Private DNS is DNS where nobody sees any of my DNS traffic, except for the root resolvers (which thus become the target of potential privacy breach).
Any intermediary means that they can see your data, but if they are centralized in only a few places, it's a bit beside the point. But then again, if they are so small that only a handful people use them, your traffic will be simple to filter out.
Finally, how do I set up my system to use any of these half-solutions for all DNS requests today?
I'd still prefer a DNS-over-Tor solution if anyone came up with it.
As for graphics layer fragmentation, it seems like Wayland makes it worse by handing more of the graphics stack over to window managers. But I guess it's also an opportunity for a BSD to make their own 'blessed' compositor (although this is extremely unlikely IMHO, for graphics driver reasons if nothing else).
There's almost no mention of such issues in the Linux kernel itself, except for "the kernel forcing adaption of DRM". I'm not versed in that story, feel free to enlighten me. But from following the link to the kernel.org thread, it seems fairly clear that the feature in question is opt-in, and that the Linux kernel therefore isn't forcing DRM onto anyone.
The criticisms of DoH seem to be around removing the ability of third parties to snoop on your DNS queries. Am I missing something here?
Like, yes, some of the use cases outlined in the linked wiki article [0] are arguably legitimate (parental controls, cybersecurity identification of C&C nodes), but then we quickly move into murkier territory (ISP blockages due to government mandates).
Preventing MitM attacks is an explicit design goal of DoH, not a side effect.
[0] https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticisms_and_...
DoH on-by-default means that I as a sysadmin -- for my family, enterprise, or even just my own computer -- no longer have the ability to easily specify how DNS works for the systems under my control. Maybe I run a PiHole; maybe I run a parental control DNS server; maybe I'm better at privacy protection than Mozilla and Cloudflare are.
Tough luck; now I'm no longer able to configure all my systems to use my DNS server over DHCP. I can't even manually set the global DNS server for one computer any more. Now I have to manually set preferences on every instance of Firefox (at least to verify that DoH is truly off), and every other application that adopts DoH one at a time.
The goal of DoH for preventing snooping by ISPs is fine. It's the implementation with hardwired per-application resolver hosts that's bad.
Edit: There's a way to tell Firefox to disable DoH at the network level [0] but AFAIK this is just a Mozilla thing; it's not an RFC. Will other browsers and apps adopt this mechanism? Who knows?
[0] https://support.mozilla.org/en-US/kb/configuring-networks-di...
I get that it makes some use-cases harder, just like HTTPS made some HTTP use-cases harder (like captive portals for wifi login) but in the end it seems like a net benefit for the majority of usecases (I want the same site, securely, no matter the network I'm on), right?
Point 2 is that if I for some reason don't trust Cloudflare to protect my users' privacy or provide speedy service or hey, maybe I just don't like the fact that they carry traffic from a bunch of seditionists -- whatever -- then I have no easy way to say to Firefox: Don't Use Cloudflare, use my provider who I do trust.
I don't care what sites my users are visiting, so inspecting their DNS traffic is not something I need to do (although perhaps it is for certain enterprises). The central point is that I no longer get to easily choose which DNS provider to trust; Mozilla has made that choice for me. That breaks the internet in a way analogous to the way AMP breaks it, and that's wrong.
I can in fact change that choice but doing so introduces a new protocol and a new set of labor-intensive tasks for the sysadmin that did not exist before, and for every app that adopts the Mozilla model, that labor increases yet more.
For privacy it's a discussion of do I trust my obnoxious non-US ISP or a US based .com with seeing all my browsing habits based on DNS queries. At least I could have legal recourse with my ISP in my own country, and there is slightly better privacy laws.
Sure lots of ways you could do it - get a fat edge firewall to hairpin the traffic + support Internet access but you end up paying a lot more for all the threat licenses on the oversized edge. Could add many more tiers, maybe more translations or overlays... but why bother with a lot more complexity or especially more cost just because someone saw a threat in another country and are trying to solve a problem that does not apply to most.
Further more there can be internal only host names that are now getting probed and exposed externally. Exfiltration to a US company in the name of "security"
https://blog.powerdns.com/2019/12/03/doh-anti-competitive-an...
I just hate that it breaks Split Horizon which is totally legitimate. Leaking local-to-the-LAN queries onto the public internet is also a concern.
IMO the right way to do this is to run your own local DNS recursive resolver, and deploy DNSCurve. This doesn't work for myopic browser vendors though...
On one hand, I see the arguments against DoH-by-default -- loss of control, potential for unfixable poor / buggy implementations, requiring trust of third parties... (The trust problem isn't going to be solved any time soon, though.)
It would be nice if implementations just used the discovered DNS server across the board, but DNS servers don't support DoH across the board yet.
On the flip side, I don't see any widespread shifts in this space until a large enough player (in this case, Mozilla) decides to put its thumb on the scale to "encourage" wider adoption. While centralized DoH may be the only game in town today, I would argue that's due to lack of adoption, and I would hope that's not the desired end state.
And even just a passive observer snooping on your DNS requests can result in an invasion of privacy.
...oookk...
Deleted comment