(They / Them)

Except that we all know what the believers in heaven are like, and if they actually got in they’d ruin the place.

I’m pretty sure the guy’s a douchebag whether you observe him or not.

Awww, one of them thinks they learned something…

The term ‘magat’ is just so on the nose, no matter how deep you go with the analogy.

A maggot is a mindless sack of flesh that wriggles and writhes all over itself and its neighbors, feeding on a constant diet of rot and decay. And if it survives that stage? It becomes a fly, attracted to steaming piles of shit, regurgitating the same diet that it feeds on just to consume it again, and then buzzing off to distract, annoy, and generally piss off the regular folk who are just trying to get on with their day.

Yes but what were you watching??

Those people are the other fascists. You can’t be a part of the problem without being part of the problem.

Eh, we let healthcare CEOs roam the streets…

Literally anyone: “Palestine should be free”

ADL: AntiSeMiTisM!!!

Elon Musk: Performs a nazi salute. Twice.

ADL: My, my, such enthusiasm! *bats eyelashes

Haha mo, not those ones silly!

And my testicles!

Thanks for the info, I’ll read through the docs and hopefully get this up and running again in the near future. Fortunately, nothing here is mission critical and I can still use the machine with VPN active. Getting resolv.conf back in working order appears to be the right solution.

My nsswitch.conf file looks identical to yours, so nothing to edit there.

I also looked at my resolv.conf and systemd\resolved.conf files.

resolv.conf is a symlink, but is the only file with anything un-commented in the file:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(
8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Yes I believe that Mullvad routes you to their DNS server so that explains why it works when connected to VPN. If I attempt an nslookup when NOT connected to VPN it fails and the server it attempts to contact is 127.0.0.53. When I connect to VPN the nslookup succeeds, and it uses the same server address.

I then disconnect from VPN and ping the ip address that I just looked up (I chose etsy) and the ping goes through so this seems to be a DNS lookup issue. Is 127.0.0.53 the right server address? I would expect it to use my DHCP server address of 192.168.x.x format.

Thanks for the tip. If I bypass DNS it does appear to work so that’s likely the problem. I need to figure out why now and I think it has something to do with a local DNS override of some sort.

My hospital buys from Harbor Freight!

Yeah, but Dunkin for coffee??

*stealthily closes nano window and closes laptop lid…

But other than those 5 places…