> So, pretend that this somewhat realistic scenario is happening to you: it's 4:00 am you just got a panicked call from someone at your company that the website is down. You log into a server and you want to see if the website is actually down or if it's just dns. You probably want to know the answers to these basic questions<p>Those questions the page raises are based on what systemd tells you, not what I'd be askiny myself. I wouldn't want to know most of those, nor do they actually answer if "DNS is down" or not (what does it even mean).<p>From my computer: dig www.mysite.com -- checks DNS is available externally. Check it at a few sites (dig www.mysite.com @1.1, @8.8.8.8, @9.9.9.9 etc). My monitoring checks my website every 10 minutes anyway from multiple locations across the world and tells me if something is wrong, so it won't be that.<p>If I think the problem is that DNS lookups are failing on the server (so it can't see db1.mysite.com or whatever), something I might suspect if it takes a couple of seconds to log in as the reverse dns times out, I'd just log in and type<p><pre><code> $ dig www.google.com -- checks DNS lookups are working internally
</code></pre>
If it's not working, I'd check what's configured<p><pre><code> $ cat /etc/resolv.conf
</code></pre>
But oh dear, systemd has put its ugly fingers into DNS, and resolv.conf is pointing to 127.0.0.53, so I have to remember some convoluted command to run to try to find out what DNS it's using.<p>The easiest way in a systemd world to do that is<p><pre><code> $ tcpdump -i any udp port 53 -nn
</code></pre>
One of the many reasons systemd is so broken.<p>In systemd that's no longer the case, another daemon is running on my machine, another daemon to go wrong, another daemon to hide what's actually happening, another daemon to wake me up at 4am because it's not working.<p>I type systemd-resolve --status<p>and get 82 lines of nonsense (on my desktop), with perhaps 1 line perhaps telling my the 'current' server configured, and a few lines telling me other servers. But then there's different servers on different links, so it's all a bit of a guess, hence tcpdump is far more reliable to see where lookups are <i>actually</i> going.<p>I have a small monitoring PC which runs a bunch of VLC sessions and webpages. It broke a couple of months ago because of systemd hijacking DNS. That means spending time looking in to why it's broken, which is a waste of time, or just having a script to fix it on bootup. The script is an ugly hack, but systemd is draining. It gets in my way, I never asked for it, but practically every distro forces its use in various (and constantly changing) ways. That's why some people get pissed off by it, it doesn't just add features you can use, it fundamentally changes the core of your machine without even buying you dinner first.