It's no problem. It was just kinda funny.

Oh, that explains what OP is talking about

I kinda cringed when you said "NFT firewall" instead of `nftables`. Lol.

Basically, network-manager is handling the /etc/resolv.conf and it looks like this:

\# Generated by NetworkManagernameserver 192.168.3.1

As far as I understand the man-page the fallback DNS-option (which is disabled in Debian) is only used if no dns-server in /etc/resolv.conf is known. 
Can it be that you set 8.8.8.8 as your dns-resolver and systemd just tries that?

Yup. I tried to configure systemd-resolved to use an alternate DNS to bypass censorship in my country and it just kept automatically using my ISP’s DNS instead for some reason until I set it in KDE’s system settings and it decided to work (even though that was the first thing I tried and it didn’t work back then, hence why I even bothered to try manually configuring it…!) That, and the fact systemd-resolved just sometimes randomly stops working definitely lowered my opinion on systemd-resolved.

As someone who just had to deal with systemd DNS fuckery today…I really wish they didn’t touch that

Firefox several issues like that but it's just an app and there are alternatives. Systemd is a core component that should enforce network configuration instead of bypassing it.

Firefox is real fucky like that. I keep having issues where it will cache DNS entries or network routes. So I will be WFH, activate my work VPN, and then have to restart Firefox because it didn't pick up the new routes.

Does disabling DoH in policies have the same effect?

Since we're talking DNS, i discovered firefox has its own TLS dns service thats enabled that can bypass your dns configuration on the network. In pfsense using pfblockerng I  had to enable a DoH/DoT Blocking List to prevent it. Might be something you can check out aswell to ensure there are no leaks.

>  Frankly I'd like to see Devuan bury the hatchet

Devuan seems to me like it's a whole community based on a gripe with one (1) specific difference of opinion. I appreciate the effort they put into it but burying hatchets is not something I'd expect them to do.

I should be clear though that I have not spent any time at all looking at the community. For all I know they're very reasonable and nuanced people. It's just that the very premise on which their community is based doesn't inspire a lot of confidence in that particular area.

Haven't checked Bullseye in a while but the procedure I used to do that always worked in Stretch and Buster was to enable either Debian's ``unstable`` or Antix's ``nosystemd`` repo. After that install sysvinit first, then in one pass install elogind + elogind_compat, and remove systemd (and only systemd, plus whatever it's indicated as a dependency as a result). You will need to reboot be it after that or in the middle of the process.

How can I install sysinit+elogind in debian? just apt install or do I also need to edit some config files?

Fortunately sysvinit+elogind still exists and can be near effortlessly installed on Debian. I put a package level filter to avoid installation of systemd since my machine was in its Jessie days and I've so far had no issues.

The package orphan-sysvinit-scripts would probably give you a much more up to date list than I could (unless I just copied it from there).

Do you have any examples? It would be good to know beforehand what Debian maintainers are not trustworthy.

The problem with that is there are several systemd fanboys in the package maintainers who remove any init script for anything other than systemd from their packages, even when the other scripts were still working, it is hard to see that as anything but hostility to anything except systemd.  
Some of the people higher up in Debian defend those acts while saying empty words about how they support init diversity.

>core system component like systemd

systemd has many long and deep tendrils.  Fortunately Debian has done quite well a separating out various parts of systemd so ... on Debian one can have the core systemd init system ... without dragging in tons of other systemd cruft of dubious use/quality - e.g. DNS and NTP related stuff.  So ... just don't.  Heck, Debian, lots of choices ... even supports non-systemd init systems, so yes, can run Debian with init systems other than systemd.  Though I'd like to see Debian also better support those other init systems.  Frankly I'd like to see Devuan bury the hatchet and take lots of the good work they've done to make lots of stuff independent of systemd, and bring/port much of that work over to Debian.  Alas, that's probably not going to happen ... well, at least anytime soon.

So, yeah, don't be going DNS, NTP, etc. with systemd - no use to drag in that cruft - if you use systemd on Debian, keep it minimal ... or at least well understand what you'r

I was reading from here: [https://wiki.debian.org/PrivacyIssues](https://wiki.debian.org/PrivacyIssues), that the privacy issues related to systemd bypassing the system DNS by using the google DNS as fallback DNS were fixed in debian.

However, I setup the nftables to drop outgoing packages from any of the system users except for my own user and \_apt, and log any attempt from any other user. And, I found in the nftables logs that the user with id 105 tries to send UDP packages with port number 53 to this destination ip address: '[8.8.8.8](https://8.8.8.8)'

So if I'm correct, it's basically the user systemd-timesync bypassing the system DNS and try to perform DNS request to '[8.8.8.8](https://8.8.8.8)'. It happens because systemd fails to contact the DNS since it's blocked by nftables, then it tries to use the fallback DNS

I think it's kind of bad that such a core system component like systemd tries to bypass the DNS configuration this way, and apparently this has not been solved in debian bullseye yet.

privacy issues of systemd in debian