Diagnostika chyb DNS pomocí nástrojů pro řešení problémů

Systém doménových jmen

DNS (Domain Name System) je základní služba internetu, která převádí názvy na IP adresy a naopak. Poruchy DNS se projevují širokou škálou problémů: od pomalého načítání webů až po úplnou nedostupnost služeb, chyby při odesílání e-mailů nebo selhání ověřování. Tento článek představuje systematický postup diagnostiky a praktické použití nástrojů pro analýzu chyb DNS na úrovni resolveru, delegací i autoritativních serverů.

Metodika: od příznaku k vrstvě

1. Upřesněte příznak: nefunguje jen jeden název, jedna doména, nebo všechny názvy? Týká se problém forward i reverse dotazů?
2. Izolujte vrstvu: klient → stub resolver → rekurzivní resolver → autoritativní servery → registr/registry.
3. Ověřte síť: latenci, blokování portu 53/udp, 53/tcp, případně 853/tcp (DoT) nebo DoH přes 443/tcp.
4. Porovnejte odpovědi: dotaz na lokální resolver oproti veřejným (např. 1.1.1.1, 8.8.8.8) – zjistíte, zda je problém lokální, nebo na autoritativním serveru.
5. Proveďte trasování a kontrolu delegace: iterativní +trace, záznamy NS a SOA, glue v parent zóně, konzistenci DS/DNSKEY.

Základní nástroje a kdy je použít

• dig/kdig/drill/host: přesná syntaxe dotazů, příznaky, validace DNSSEC, trasování delegací.
• nslookup: historický nástroj; použijte ho jen tehdy, pokud chybí dig (ve Windows raději PowerShell Resolve-DnsName).
• PowerShell (Windows): Resolve-DnsName, Test-DnsServer, Get-DnsClientServerAddress.
• tcpdump/Wireshark: zachytávání paketů, analýza EDNS, fragmentace, RCODE, bitu DO, NSID.
• DNsviz/Zonemaster/IntoDNS: automatizované online kontroly delegací a DNSSEC (v provozu je používejte opatrně a mimo incident, pokud domény nejsou veřejné).
• Autoritativní validační nástroje: named-checkzone, named-checkconf (BIND), kzonecheck (Knot DNS), nsd-checkzone (NSD), pdnsutil check-zone (PowerDNS).

Rychlá kontrola resolveru

• dig example.com A – základní dotaz přes systémový resolver.
• dig @1.1.1.1 example.com AAAA – obejde lokální resolver a odhalí lokální mezipaměť/chybu.
• dig +short example.com MX – stručný výstup pro rychlý přehled.
• dig -x 93.184.216.34 – reverzní dotaz, častý zdroj odlišných problémů (záznamy PTR, delegace in-addr.arpa/ip6.arpa).
• Resolve-DnsName example.com -Type A – ekvivalent ve Windows.

Jak porozumět hlavičce a RCODE

• RCODE: NOERROR (úspěch), NXDOMAIN (název neexistuje), SERVFAIL (selhala validace/odpověď), REFUSED (politika), FORMERR (formát dotazu), NOTAUTH/NOTZONE (autorita/zóna).
• AD bit: autentizovaná odpověď (DNSSEC ověřeno v resolveru).
• CD bit: potlačí validaci (užitečné pro porovnání chování s DNSSEC a bez něj).
• dig +cdflag, dig +adflag – test vlivu validace.

DNSSEC: časté zdroje chyb SERVFAIL

• dig example.com DNSKEY +dnssec a dig example.com DS +dnssec @a.gtld-servers.net – ověřte řetězec důvěry parent → child.
• Typické chyby: expirovaný RRSIG, neshodující se DS (algoritmus/klíč), nesprávně podepsaný glue, nepřesný čas (odchylka NTP).
• dig +trace example.com – sleduje iterativní cestu a určuje, kde validace selže.
• dig +dnssec @resolver example.com A vs +cdflag – pokud dotaz s +cdflag projde, je problém v DNSSEC, nikoli v dostupnosti/autoritatívních serverech.

EDNS a velikost paketů

• Ověřte velikost bufferu EDNS a bit DO: dig example.com A +dnssec +bufsize=1232. Hodnota 1232 B minimalizuje riziko fragmentace na moderním internetu.
• Pokud odpovědi mizí (firewally zahazují fragmenty), vynucení TCP: dig +tcp example.com DNSKEY.
• Příznak: některé typy záznamů (DNSKEY/DS/TXT) selhávají, jiné fungují → podezření na problém s MTU/fragmentací nebo blokování EDNS.

Trasování delegace a glue

• dig +trace example.com – postup od kořenových serverů; sledujte záznamy NS a glue.
• dig example.com NS a dig @tld-server example.com NS – porovnejte parent a child autority; nekonzistence způsobuje střídavé výpadky.
• dig ns1.example.com A – ověřte dostupnost glue; pokud chybí nebo je nesprávný, resolver nedohledá autoritu.
• dig example.com SOA – kontrola serialu, refresh/retry/expire; důležitá pro sekundární servery.

TTL, ukládání do mezipaměti a negativní mezipaměť

• dig example.com A +ttlunits – sledujte zbývající TTL; zastaralé odpovědi mohou maskovat opravy.
• dig nonexistent.example.com A – při rozlišení NOERROR/NODATA oproti NXDOMAIN hraje roli negativní mezipaměť a záznam SOA (RFC 2308).
• Serve-stale: některé resolvery při výpadku autorit vracejí zastaralé odpovědi – při incidentu je dobré o tom vědět.

Split-horizon a lokální překlad názvů

• Liší se odpovědi uvnitř a vně sítě? Testujte s výslovně zadaným resolverem: dig @10.0.0.53 intranet.corp A vs dig @1.1.1.1 intranet.corp A.
• Kontrolujte /etc/resolv.conf, systemd-resolved (resolvectl status), NetworkManager a vyhledávací domény (search).
• V macOS (mDNSResponder): scutil --dns a sudo killall -HUP mDNSResponder pro vyprázdnění mezipaměti.
• Windows: ipconfig /all, ipconfig /flushdns, Get-DnsClientServerAddress.

Problémy s e-mailem: MX, SPF, DKIM, DMARC

• dig example.com MX a ověřte, že MX odkazují na názvy, které lze přeložit na A/AAAA.
• dig mail.example.com A a AAAA – často chybí AAAA nebo není konzistentní dopředný/zpětný překlad.
• dig example.com TXT – SPF/DMARC; dig selector._domainkey.example.com TXT – DKIM.
• Reverzní záznamy (-x) a PTR ↔ A: některé služby odmítají spojení při nesouladu.

Testy DoT/DoH (šifrované DNS)

• DNS-over-TLS: kdig @1.1.1.1 +tls example.com nebo openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com (ověří navázání spojení).
• DNS-over-HTTPS: curl -s -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A".
• Pokud DoT/DoH funguje, ale klasické UDP/TCP ne, hledejte lokální filtrování/CGNAT/problém s MTU.

Zachytávání a kontrola paketů

• tcpdump -ni any port 53 -vvv – rychlá kontrola provozu; sledujte RCODE, velikosti a bit TC (truncated).
• Filtry Wiresharku: dns, udp.port==53, tcp.port==53; pro TLS tcp.port==853.
• Ověření NSID: některé autority vkládají NSID – užitečné při analýze anycastu.

Autoritativní servery: kontrola zóny a konfigurace

• BIND: named-checkconf, named-checkzone example.com /path/zonefile, rndc reload, rndc zonestatus example.com.
• Knot DNS: kzonecheck example.com, knotc zone-status example.com.
• NSD: nsd-checkzone example.com /path/zonefile.
• PowerDNS: pdnsutil check-zone example.com, pdnsutil rectify-zone (DNSSEC NSEC3).
• Ověřte serial (SOA) a replikaci na sekundárních serverech; často selhává AXFR/IXFR kvůli ACL nebo chybějícímu TSIG.

Nejčastější vzorce chyb a jak je rozpoznat

• NXDOMAIN, ale existuje CNAME: dotazujete se na CNAME target bez odpovídajících A/AAAA – doplňte cílové záznamy.
• SERVFAIL pouze u DNSKEY/DS: rozpad řetězce DNSSEC; zkontrolujte expiraci RRSIG a shodu DS s DNSKEY.
• REFUSED od autorit: server není otevřený resolver; požadujete rekurzi od autoritativního serveru → použijte správný rekurzivní resolver.
• Truncated (TC=1): nedostatečný UDP buffer nebo blokování fragmentace; přejděte na TCP (+tcp) nebo snižte +bufsize.
• Občasné timeouty: uzel anycastu nebo jeden sekundární server mimo provoz; porovnejte odpovědi od všech NS (@ns1, @ns2…).
• Selhání reverzního překladu u e-mailů: chybějící PTR pro IP adresu odesílacího MTA nebo PTR odkazující na název bez A/AAAA (neúplný forward-confirmed reverse DNS).

Kontrolní seznam při incidentu

1. Reprodukujte chybu pomocí dig (A/AAAA/MX/NS/SOA) a uložte výstupy.
2. Porovnejte lokální a veřejný resolver (@1.1.1.1, @8.8.8.8).
3. Spusťte +trace a určete nejvyšší úroveň, na které odpověď selže.
4. Ověřte DNSSEC (+dnssec, +cdflag), expiraci RRSIG a shodu DS/DNSKEY.
5. Změřte velikosti odpovědí (+stats) a otestujte +tcp, +bufsize=1232.
6. Zachyťte pakety na klientu i serveru; hledejte zahozené fragmenty a RCODE.
7. Na autoritativním serveru spusťte check-zone, proveďte test AXFR z rekurzivního resolveru (pokud je povolen) a ověřte ACL/TSIG.

Tabulka: přehled příkazů a jejich interpretace

Výkonnost a latence překladu názvů

• Opakujte dotazy s +stats/+time=; první dotaz zahrnuje rekurzi, další se obslouží z mezipaměti.
• Měřte latenci k NS serverům (mtr/traceroute) – pokud je vzdálený sekundární server pomalý, upřednostněte anycast a regionální NS.
• Zvažte přednačítání, serve-stale a vhodné TTL pro vyvážení aktuálnosti a zátěže.

Bezpečnostní aspekty diagnostiky

• Pozor na únik informací při dotazu version.bind (CHAOS); omezte recursion a version disclosure pouze na management sítě.
• Neprovádějte bezhlavě AXFR; povolte jej pouze s TSIG a zdrojovými ACL.
• Při sdílení výstupů anonymizujte interní názvy a IP adresy.

Příklady diagnostiky „end-to-end“

1. „Web nefunguje jen v kanceláři“: dig @local-resolver web.example A selže, @1.1.1.1 funguje → problém v lokálním resolveru/mezipaměti. Řešení: vyprázdnit mezipaměť, ověřit upstream, EDNS/MSS.
2. „E-maily se vracejí“: dig example.com MX → MX odkazuje na mail.example.com, ale dig mail.example.com A/AAAA vrací NXDOMAIN → pro hostitele uvedeného v MX chybí A/AAAA; doplňte záznamy a během opravy snižte TTL.
3. „Náhodný SERVFAIL“: +dnssec selže, +cdflag funguje → rozpad DNSSEC: v child zóně vypršel RRSIG; zónu znovu podepište a zkontrolujte DS.

Shrnutí

Úspěšná diagnostika DNS stojí na disciplinovaném postupu: izolujte problém, porovnávejte odpovědi různých resolverů, sledujte signály RCODE a DNSSEC, trasujte delegace a měřte velikost odpovědí. Nástroje jako dig/kdig, tcpdump/Wireshark, validační nástroje autoritativních serverů a online analyzátory vám umožní rychle lokalizovat chybu mezi klientem, rekurzí a autoritou. Důsledná kontrola EDNS/MTU, glue, DS/DNSKEY a TTL v mezipaměti zkrátí dobu incidentu a zabrání opakovaným výpadkům.