Diagnostika DNS

Domain Name System

DNS (Domain Name System) je základní služba internetu převádějící názvy na IP adresy a naopak. Poruchy v DNS se projevují širokou škálou problémů: od pomalého načítání webů po úplnou nedostupnost služeb, chyby 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 DNS chyb na úrovni rezolveru, delegací i autoritativních serverů.

Metodika: od symptomu k vrstvě

1. Upřesněte symptom: nefunguje jen jeden název, jedna doména, či veškeré 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íť: latence, blokace 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 versus veřejné (např. 1.1.1.1, 8.8.8.8) – identifikujete, zda je problém lokální či na autoritě.
5. Proveďte trasování a kontrolu delegace: iterativní +trace, NS a SOA záznamy, glue v parent zóně, konzistence DS/DNSKEY.

Základní nástroje a kdy po nich sáhnout

• dig/kdig/drill/host: přesná syntaxe dotazů, vlajky, validace DNSSEC, trasování delegací.
• nslookup: historický nástroj; použijte jen pokud chybí dig (na 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, DO bit, NSID.
• DNsviz/Zonemaster/IntoDNS: automatizované on-line kontroly delegací a DNSSEC (v provozu použijte s opatrností a mimo incident, pokud jsou domény neveřejné).
• Autoritativní validační nástroje: named-checkzone, named-checkconf (BIND), kzonecheck (Knot DNS), nsd-checkzone (NSD), pdnsutil check-zone (PowerDNS).

Rychlá kontrola rezolveru

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

Rozumíme hlavičce a RCODE

• RCODE: NOERROR (úspěch), NXDOMAIN (jméno neexistuje), SERVFAIL (selhala validace/odpověď), REFUSED (politika), FORMERR (formát dotazu), NOTAUTH/NOTZONE (autorita/sekce).
• AD bit: autentizovaná odpověď (DNSSEC validováno v rezolveru).
• CD bit: potlačí validaci (užitečné pro porovnání chování s/bez DNSSEC).
• dig +cdflag, dig +adflag – test vlivu validace.

DNSSEC: časté zdroje 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, neodpovídající DS (algoritmus/klíč), špatně podepsané glue, neaktuální hodiny (NTP drift).
• dig +trace example.com – sleduje iterativní cestu a identifikuje, kde validace selže.
• dig +dnssec @resolver example.com A vs +cdflag – pokud +cdflag projde, je problém v DNSSEC, nikoli v dosahu/autoritu.

EDNS a velikost paketů

• Ověřte EDNS buffer a DO bit: 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.
• Symptom: některé typy (DNSKEY/DS/TXT) padají, jiné fungují → podezření na MTU/fragmentaci nebo blokování EDNS.

Trasování delegace a glue

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

TTL, kešování a negativní keš

• dig example.com A +ttlunits – sledujte zbývající TTL; staré odpovědi mohou maskovat opravy.
• dig nonexistent.example.com A – v NOERROR/NODATA versus NXDOMAIN hraje roli negativní keš a SOA záznam (RFC 2308).
• Serve-stale: některé rezolvery vrací „stale“ odpovědi při výpadku autorit – dobré vědět při incidentu.

Split-horizon a lokální rezoluce

• Rozdílné odpovědi uvnitř a vně sítě? Testujte s explicitním rezolverem: 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).
• Na macOS (mDNSResponder): scutil --dns a sudo killall -HUP mDNSResponder pro flush.
• Windows: ipconfig /all, ipconfig /flushdns, Get-DnsClientServerAddress.

Mailové problémy: MX, SPF, DKIM, DMARC

• dig example.com MX a ověřte, že MX ukazují na jmenně řešitelné A/AAAA.
• dig mail.example.com A a AAAA – často chybí AAAA nebo forward/reverse konzistence.
• dig example.com TXT – SPF/DMARC; dig selector._domainkey.example.com TXT – DKIM.
• Reverse záznamy (-x) a PTR ↔ A: některé služby odmítají spojení při nesouladu.

DoT/DoH testy (š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ěří handshake).
• 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í filtraci/CGNAT/MTU problém.

Capturing a inspekce paketů

• tcpdump -ni any port 53 -vvv – rychlá kontrola provozu; sledujte RCODE, velikosti, TC (truncated) bit.
• Wireshark filtry: 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 anycast triáži.

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árech; často selhává AXFR/IXFR kvůli ACL nebo chybějícím TSIG.

Nejčastější vzorce chyb a jejich rozpoznání

• NXDOMAIN, ale existuje CNAME: dotazujete CNAME target bez odpovídajících A/AAAA – doplňte cílové záznamy.
• SERVFAIL jen u DNSKEY/DS: rozpad DNSSEC řetězce; zkontrolujte RRSIG expiry a shodu DS s DNSKEY.
• REFUSED z autorit: server není open-resolver; dotazujete rekurzi na autoritě → použijte správný rekurzivní resolver.
• Truncated (TC=1): nedostatečný UDP buffer nebo blokace fragmentace; přejděte na TCP (+tcp) nebo snižte +bufsize.
• Intermitentní time-outy: anycast uzel nebo jeden sekundár mimo provoz; porovnejte odpovědi od všech NS (@ns1, @ns2…).
• Reverse selhání e-mailů: chybějící PTR na IP odesílacího MTA, nebo PTR ukazuje na jméno bez A/AAAA (nekompletní forward-confirmed reverse DNS).

Kontrolní seznam při incidentu

1. Reprodukujte chybu s 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 najděte nejvyšší úroveň, kde odpověď selže.
4. Ověřte DNSSEC (+dnssec, +cdflag), expiraci RRSIG a DS/DNSKEY shodu.
5. Změřte velikosti odpovědí (+stats) a otestujte +tcp, +bufsize=1232.
6. Packet capture na klientu i serveru; hledejte zahozené fragmenty a RCODE.
7. Na autoritě spusťte check-zone, proveďte AXFR test z rekurzivního resolveru (pokud je povolen) a ověřte ACL/TSIG.

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

Výkonnost a latence rezoluce

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

Bezpečnostní aspekty diagnostiky

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

Příklady „end-to-end“ triáží

1. „Web nejde jen v kanceláři“: dig @local-resolver web.example A selže, @1.1.1.1 OK → problém v lokálním rezolveru/keši. Řešení: flush keše, ověřit upstream, EDNS/MSS.
2. „E-maily se vrací“: dig example.com MX → MX na mail.example.com, ale dig mail.example.com A/AAAA NXDOMAIN → chybí A/AAAA pro host v MX; doplnit záznamy a snížit TTL během opravy.
3. „Náhodný SERVFAIL“: +dnssec padá, +cdflag OK → rozpad DNSSEC: expirované RRSIG v child; přepodepsat, zkontrolovat DS.

Shrnutí

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