DNS Resolver

En DNS resolver mottar forespørsler fra klienter og finner riktig IP-adresse eller DNS-record ved å kontakte andre DNS-servere på deres vegne. Den er inngangspunktet de fleste applikasjoner bruker mot DNS-systemet, og skjuler kompleksiteten i å traversere det globale navnehierarkiet for hvert enkelt program.

To typer resolvere finnes i praksis. En *stub-resolver* ligger i operativsystemet eller i applikasjonsbiblioteket og videresender hver forespørsel til en konfigurert oppstrømsresolver — typisk hentet fra /etc/resolv.conf, DHCP eller manuell konfigurasjon. En *rekursiv resolver*, også kalt full-service resolver, er selve oppstrømsen: den traverserer rot → TLD → autoritativ server og returnerer ett ferdig svar. De fleste operatører kjører dedikerte rekursive DNS-servere — Unbound, BIND, Knot Resolver — mens sluttenheter snakker stub mot disse.

For å holde latency og trafikk lav vedlikeholder enhver resolver en cache nøklet på navn og record-type, og respekterer TTL-en på hvert svar. Negative svar (NXDOMAIN, tomt NODATA) caches også, begrenset av SOA-minimumsfeltet, og det er grunnen til at DNS-propagering av et helt nytt navn kan henge etter den faktiske publiseringen. Validerende resolvere utfører i tillegg DNSSEC-kontroller og returnerer SERVFAIL i stedet for usignerte data dersom tillitskjeden er brutt.

Offentlige eksempler er Cloudflare 1.1.1.1, Google 8.8.8.8 og Quad9 9.9.9.9. ISP-er kjører typisk egne resolvere og deler dem ut via DHCP, mens bedriftsnett ofte har interne resolvere som kombinerer offentlig rot-traversering med split-horizon-svar for private soner. Resolvere henter også MX-, PTR-, SPF-, DKIM- og DMARC-records som brukes i e-postflyt, og derfor bryter et utfall i det rekursive laget langt mer enn bare nettlesing.