Unbound může být aktivní v systemctl a neplnit žádné požadavky z počítače. Na VM Debian nebo Ubuntu je symptom běžný: služba běží, ale DNS požadavky zůstávají pomalé, nebo aplikace už nic neřeší.
Než upravíte /etc/resolv.conf nebo se pustíte do systemd-resolved, nejprve proveďte místní diagnostiku. Zkontrolujte konfiguraci a port, pak se dotazujte přímo na Unbound. DNS systému zůstává v platnosti během těchto kontrol.
Přečtěte si konfiguraci, než se dotknete portu 53
Na Debianu a Ubuntu často hlavní konfigurace prochází přes /etc/unbound/unbound.conf, s inkluzemi v /etc/unbound/unbound.conf.d/. Nez assumejte, že Unbound naslouchá na 127.0.0.1:53.
Port 53 může být již obsazen systemd-resolved, dnsmasq nebo BIND. Riziko je jednoduché: pokud příliš brzy změníte systémový resolver, můžete přerušit DNS rozlišení počítače, přičemž Unbound neposlouchá na správném místě.
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'unbound-checkconf čte konfiguraci a vrací chybu, pokud nějaká direktiva blokuje načtení. Podle oficiální stránky manuálu se návratový kód 0 považuje za platný soubor. Možnosti -o interface a -o port zobrazují skutečné hodnoty.
ss ukazuje proces, který skutečně naslouchá. Pokud vidíte 127.0.0.53:53 u systemd-resolved, zatímco Unbound by měl odpovídat na 127.0.0.1:53, máte konkrétní konflikt k řešení.
Před úpravou si uchovejte čitelnou kopii hlavního souboru:
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-testDotaz na Unbound bez změny DNS počítače
Aktivní služba nestačí. Unbound může naslouchat na jiném rozhraní, používat jiný port, nebo může selhat v odpovědi, protože nastává problém s upstream servery nebo DNSSEC.
Stav služby a logy aktuálního spuštění poskytují první třídění. Poté pošlete dotaz na místní resolver, bez použití systémové DNS konfigurace:
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +statsPřizpůsobte 127.0.0.1 a přidejte -p 5335, pokud vaše konfigurace zobrazuje jiný port. Odpověď s status: NOERROR a sekcí ANSWER dokazuje, že Unbound odpověděl na tento název.
connection refused se odkazuje na službu nebo port. SERVFAIL naznačuje, že démon obdržel dotaz, ale nemohl rozluštit název. Logy pak pomáhají oddělit problém sítě, kontrolu DNSSEC a konfiguraci upstream serverů.
Poté opakujte stejný dotaz. Kratší doba na druhém pokusu může pocházet z cache Unbound. Tento test neměří výkon resolveru; pouze potvrzuje, že mluvíte se správnou instancí.
Připojte systémový resolver až po přímém testu
Pokud dig @127.0.0.1 odpovídá, ale aplikace stále selhávají, Unbound pravděpodobně není v řetězci používaném systémem. Přečtěte si tento řetězec před úpravou sítě.
resolvectl statuszobrazuje DNS známé systemd-resolved.resolvectl query example.nettestuje rozlišení ze systémového resolveru.cat /etc/resolv.confukazuje soubor, který je prezentován klasickým aplikacím.
Na serveru bych si ponechal Unbound na známosti a dokumentovaném adrese a portu, a poté bych připojil systémový resolver, jakmile by byly validovány přímé testy. Na pracovním počítači může systemd-resolved zůstat před Unbound, pokud tato vrstva usnadňuje Wi-Fi, VPN nebo síťové profily.
Lokální test neříká nic o veřejném rozlišení domény. Než umístíte aplikaci za reverse proxy Caddy s HTTPS, zkontrolujte také odpověď viděnou z Internetu.
Dokumentace unbound-checkconf pokrývá kontroly konfigurace. Oficiální průvodce místním resolverem podrobně popisuje integraci se systémem. Uchovejte zálohu, dokud přímý test a systémový test nepřinesou stejné výsledky.