"It's slow" and "it can't connect" are, surprisingly often, DNS. When name resolution breaks, everything downstream looks broken in a hundred confusing ways. The cure is a systematic check that isolates where resolution fails.
1. Confirm it's actually DNS
Compare a name to a raw IP. If ping 8.8.8.8 works but ping google.com fails with "Name or service not known", you've localised it to DNS, not the network.
2. Query directly with dig
dig example.com # what does the default resolver return? dig @8.8.8.8 example.com # bypass it — ask a known-good server dig +trace example.com # follow the delegation from the root down
If @8.8.8.8 resolves but the default doesn't, the problem is your resolver, not the record. If neither resolves, the record (or the authoritative server) is the problem.
3. Check which resolver you're using
Look at /etc/resolv.conf — the nameserver lines are who you're asking. On systemd-resolved boxes this is often a stub (127.0.0.53); use resolvectl status to see the real upstream servers and per-link config. A missing or wrong nameserver entry is a classic cause — pointing it at 8.8.8.8 is the fast fix to confirm the theory.
4. Rule out the easy traps
Check /etc/hosts for a stale manual override, confirm /etc/nsswitch.conf lists hosts: files dns, and if you run a local resolver like named/bind, make sure it's actually up (systemctl status named) and listening on port 53.
Practise it under pressure
DNS failures — bad resolv.conf, a crashed resolver, a missing record — are recurring incidents in the simulator. Work them live with Linux troubleshooting practice and a full incident response shift.