DNS: oppløsning, delegering og drift

DNS svarer på spørsmålet om hvilken informasjon som er publisert for et bestemt navn, og hvem som er ansvarlig for det. Systemet er samtidig et hierarkisk navnerom, en distribuert database og en binær spørreprotokoll. Det leverer ikke bare IP-adresser, men også navneservere, e-postmål, tjenesteendepunkter, nøkler og retningslinjer. De som bare betrakter DNS som «navneoppløsning», overser derfor nettopp postene som meldingsutveksling og identitet er avhengige av (RFC 9499).

Den følgende veien starter ved en applikasjons stub-resolver, følger cache og delegeringer frem til den autoritative serveren og fører deretter svaret tilbake. Denne prosessen gjør det mulig å plassere TTL, Glue, TCP-fallback, DNSSEC, soneadministrasjon og typiske feilbilder i sammenheng.

For meldingsadministratorer er DNS et overordnet styringssystem. En MTA finner neste e-postmål via DNS, avsenderautentisering leser retningslinjer og nøkler, sertifikatprosesser kan bruke DNSSEC-sikrede data, og katalog- eller Kerberos-klienter finner tjenester via SRV-poster. DNS kontrollerer imidlertid ikke om den funne tjenesten er frisk. Et syntaktisk korrekt MX-svar kan peke på en utilgjengelig SMTP-lytter; et vellykket A-oppslag sier ingenting om TLS, autentisering eller applikasjonstilstand.

Arkitektur og roller

Ansvaret for navn er organisert som et tre. Ved den navnløse roten . begynner toppnivådomener som ch., og under dem følger delegerte domener og flere etiketter. Et avsluttende punktum gjør et navn fullt kvalifisert og hindrer lokale søkesuffikser. Denne lille skrivemåten er relevant i drift: mail.example.ch kan på en klient suppleres med et søkedomen, mens mail.example.ch. ikke kan det.

Et domene er en del av navnerommet. En sone er derimot den administrativt sammenhengende datamengden som en autoritativ server har lokalt ansvar for. En delegering skiller en underordnet sone fra foreldresonen. Forelderen publiserer da et NS-RRset og, når et navneservernavn ligger innenfor den delegerte underordnede sonen, nødvendige A- eller AAAA-data som Glue for å nå den. Det grunnleggende skillet mellom navnerom, soner og delegering stammer fra RFC 1034; aktuelle begreper oppsummeres i RFC 9499, seksjon 7.

Fire logiske roller forklarer oppløsningsveien:

Et produkt kan implementere flere roller, men de bør likevel betraktes separat i drift. En feil i den autoritative tjenesten påvirker publiseringen av egne soner; en feil i den rekursive tjenesten påvirker navneoppløsningen for egne klienter. Felles prosesser, adresser eller feilområder gjør dette skillet vanskeligere.

Navneoppløsning trinn for trinn

En applikasjon spør normalt ikke selv rot- og autoritative servere. Stub-resolveren overleverer en rekursiv forespørsel til en resolver. Hvis denne mangler en brukbar cacheoppføring, følger den delegeringene fra roten via toppnivådomenet til ansvarlig sone. Hver henvisning angir neste NS-RRset og eventuelt Glue-adresser. Resolveren setter sammen det endelige svaret, validerer eventuelt DNSSEC og cacher resultatet (RFC 1034, seksjon 4.3).

Den tegnede lineære veien er en kaldstartmodell. I en varm resolvercache finnes vanligvis allerede rot- og TLD-delegeringer, slik at bare en del av trinnene er nødvendige. Også QNAME-minimering, videresending, lokale soner eller aggressive DNSSEC-cacher kan endre den synlige pakkestien. Det avgjørende er fortsatt å tilordne hver observasjon til en rolle: Et ikke-autoritativt cachesvar er ikke bevis på hva den ansvarlige autoritative serveren leverer akkurat nå.

Teknisk oppbygning av en DNS-melding

På wire-nivå består en DNS-melding av Header, Question, Answer, Authority og Additional Section. Spørsmålet angir QNAME, QTYPE og QCLASS. Svar og henvisninger vises som Resource Records i de øvrige seksjonene. Flagg viser blant annet autoritet, ønske om rekursjon og trunkering; Response Code beskriver resultatet. For analysen teller derfor ikke bare Answer-teksten, men også hvilken server den kom fra og med hvilke flagg (RFC 1035, seksjon 4.1).

For diagnostikk er disse spesielt relevante:

EDNS(0) utvider med en pseudoaktig OPT-post ekstra flagg, alternativer og en større annonsert UDP-nyttelast uten å erstatte grunnformatet (RFC 6891). DNSSEC-DO-biten befinner seg i dette utvidede flaggfeltet, ikke i den opprinnelige DNS-headeren.

Resource Records og RRset

Det faglige innholdet ligger i Resource Records. Eiernavn, type og klasse bestemmer hva dataene hører til; TTL og RDATA gir cachetid og typespesifikk verdi. Alle poster med samme eier, type og klasse utgjør et RRset og deler én TTL. Flere MX-, A- eller AAAA-verdier er derfor en samlet cachet mengde, ikke enkeltobjekter som kan styres uavhengig (RFC 2181, seksjon 5).

Teksten i en sonefil er bare Presentation Form. På nettverket overføres navn etikett for etikett, tall binært og enkelte navn eventuelt komprimert. Den som kopierer en tegnstreng fra et brukergrensesnitt, bør derfor skille mellom om brukergrensesnittet allerede har satt sammen anførselstegn, escape-sekvenser eller flere TXT-strenger til én logisk nyttelast.

Delegering, Glue og autoritet

Med en delegering overfører en sone ansvaret for et undertre. Forelderen publiserer NS-RRset for den underordnede sonen; den underordnede sonen oppgir selv sine autoritative servere på nytt. Dersom sidene avviker fra hverandre, kan resolverne velge ulike veier. Glue-adresser i forelderen løser bare høna-og-egget-problemet med tilgjengelighet. De autoritative A-/AAAA-verdiene ved navneservernavnet forblir selvstendige data med egen TTL og vedlikehold.

Særlig kritisk er in-bailiwick Glue: Hvis example.ch. delegeres til ns1.example.ch., trenger resolveren adressen til ns1.example.ch. før den kan spørre den underordnede sonen. Uten Glue oppstår en oppløsningssløyfe. Hvis delegeringen derimot peker på ns1.provider.net., kan adressen finnes via en annen delegeringskjede.

Ved bytte av navneserver må derfor minst fire tilstander kontrolleres: ny sone lastet på alle servere, Child-NS-RRset tilpasset, Parent-delegering tilpasset og nødvendig Glue oppdatert. Først deretter bør gamle servere tas ut av drift eller tilgjengelighet.

Cache, TTL og negative svar

Etter oppløsning lever et svar videre i cacher. TTL-en er maksimal brukstid fra tidspunktet den aktuelle resolveren lærte det. Det finnes derfor ingen global felles nedtelling. Stub-resolvere, videresendere, rekursive resolvere og applikasjoner kan forkaste samme gamle RRset på ulike tidspunkter. En TTL som senkes før en migrering, hjelper bare for svar som lastes på nytt etterpå; allerede cachede data kan ikke tilbakekalles.

Også ikke-eksistens caches. NXDOMAIN betyr at det forespurte navnet ikke finnes; NODATA er et NOERROR-svar der navnet finnes, men ikke noe RRset av den forespurte typen. Den autoritative serveren legger ved sin SOA-RR i Authority Section i begge svarene. Den negative cachetiden er minimum av SOA-TTL og SOA.MINIMUM (RFC 2308, seksjon 3 til 5). Dette forklarer hvorfor en nyopprettet DKIM-selektor eller et vertsnavn etter et tidligere mislykket forsøk fortsatt først kan fremstå som ikke-eksisterende.

SERVFAIL må skilles fra dette: Resolveren klarte ikke å opprette et brukbart svar. Årsaker er blant annet tidsavbrudd mot autoritative servere, en ødelagt delegering, en DNSSEC-valideringsfeil eller en intern ressursbegrensning. REFUSED betyr derimot at den forespurte serveren ikke utfører operasjonen på grunn av sin policy. Et diagnoseverktøy må derfor vise RCODE, AA-bit, svarende server og seksjoner; en utdata som bare melder «ingen adresse», visker ut avgjørende forskjeller.

Transport: UDP, TCP og krypterte resolverbaner

For denne utvekslingen må nettverksbanen tillate UDP og TCP på port 53. TCP er ikke begrenset til soneoverføringer: En resolver kan bruke det direkte og må kunne falle tilbake til det etter et avkortet UDP-svar. Blokkert TCP blir derfor ofte først synlig ved store, DNSSEC-rike eller svarrike RRset. Små A-forespørsler forblir grønne og gir et feilaktig bilde (RFC 7766).

Uten EDNS er DNS-nyttelasten over UDP begrenset til 512 byte. EDNS lar den spørrende annonsere en større mottakbar nyttelast. En for stor verdi kan imidlertid tvinge frem IP-fragmentering; dersom en bane mister eller blokkerer fragmenter, oppstår det typiske bildet der små svar fungerer og store svar får tidsavbrudd. EDNS-spesifikasjonen anbefaler å ta hensyn til faktisk mottakskapasitet og banen, og ved problemer falle tilbake til mindre verdier eller TCP (RFC 6891, seksjon 6.2).

DNS over TLS, DNS over HTTPS eller DNS over QUIC krypterer en DNS-transportbane. Disse prosedyrene endrer verken soneinnhold eller delegering og erstatter ikke DNSSEC: Transportkryptering beskytter forbindelsen til en resolver, mens DNSSEC autentiserer data langs delegeringskjeden. Klassisk DNS på port 53 er ukryptert; den felles terminologien for transporttypene er definert i RFC 9499, seksjon 6.

DNSSEC og tillitskjeden

DNSSEC utvider navneoppløsningen med verifiserbar opprinnelse og integritet. En sone signerer RRset med RRSIG og publiserer de offentlige nøklene som DNSKEY. Forelderen kobler den underordnede sonen via DS til den overliggende tillitskjeden; NSEC eller NSEC3 kan også bevise ikke-eksistens. En validerende resolver starter ved sitt Trust Anchor og kontrollerer denne kjeden frem til svaret. Innholdet forblir offentlig: DNSSEC krypterer ingen forespørsel (RFC 4033, RFC 4034).

For drift er ikke bare nøkkelfiler relevante, men flere tidsmessig koblede tilstander:

• RRSIG-er har start og utløp; feil systemtid eller manglende re-signering kan gjøre en hel sone bogus.
• En DS i forelderen må samsvare med en brukbar DNSKEY i den underordnede sonen. En foreldreløs DS er verre for validerende resolvere enn en bevisst usignert delegering.
• Ved rollover må publisering, signering, endring i forelderen, TTL-er og cachetider planlegges som en tilstandsmaskin.
• En validerende resolver leverer ofte SERVFAIL for bogus data. En test uten validering kan samtidig vise et tilsynelatende normalt svar.

AD-flagget alene er bare så pålitelig som resolveren og veien til den. For en uavhengig kontroll må en administrator undersøke kjeden med et validerende verktøy og lokalisere den feilende overgangen mellom DS, DNSKEY og RRSIG.

Autoritativ drift og dataflyt

Bak det autoritative svaret ligger en egen distribusjonsvei. I en klassisk modell leder en primærkilde sonen, DNS NOTIFY informerer sekundærservere om en ny SOA-Serial, og AXFR eller IXFR overfører henholdsvis komplette eller inkrementelle data. En frisk lytter beviser derfor ikke at serveren har lastet den nye sonen. Serial, overføringsstatus og svar fra hver autoritative node må sees samlet (RFC 1996, RFC 5936, RFC 1995).

Sonen kan genereres fra tekstfiler, en database, et API, Active Directory eller en Git-/CI-pipeline. Dette implementeringsvalget endrer ikke DNS-wire-protokollen, men bestemmer transaksjonsgrenser, revisjonsmulighet og gjenoppretting. RFC 2136 definerer atomiske dynamiske oppdateringer med Prerequisites; et leverandør-API-kall er derimot en separat styringsprotokoll og må dokumentere sine egne konsistens- og feilregler (RFC 2136).

En DNS-sikkerhetskopi er først brukbar når den kan gjenopprette sonen som faktisk leveres. Avhengig av plattform inkluderer dette:

• sone eller kildedatabase, inkludert SOA-Serial og dynamisk journal;
• serverkonfigurasjon, Views, ACL-er, videresendere og katalogtilordning;
• TSIG-secrets, DNSSEC-private nøkler og tilstander for automatiske rollover;
• foreldedata utenfor egen sone, særlig delegering, Glue og DS;
• en testet vei for å forsyne sekundærservere på nytt og kontrollere sonedata semantisk.

Sekundærservere er tilgjengelighetskopier, men ikke automatisk historiske sikkerhetskopier. En feilaktig eller ondsinnet endring kan raskt replikeres til alle autoritative servere via NOTIFY og soneoverføring.

Implementerings- og teknologistack

DNS betegner ikke én enkelt daemon. Den felles teknologistacken består av navn og RRset, binært Query-/Response-format, UDP og TCP, cachelogikk og eventuelt DNSSEC. Autoritative servere, rekursive resolvere, videresendere og administrert DNS implementerer disse byggesteinene forskjellig. For drift teller derfor først et produkts rolle, deretter språk eller pakking:

Skillet mellom rollene er viktigere enn produktnavnet. For en offentlig autoritativ plattform teller sonedistribusjon, sekundærservere, DNSSEC-signering og DDoS-resiliens; for en bedriftsresolver teller cache, videresending, interne navnerom, policy, personvern og validering.

DNS i e-post- og identitetsdrift

I meldingsutveksling blir et DNS-svar umiddelbart en leveringsvei. En sendende MTA spør MX-RRset for mottakerdomenet, foretrekker den laveste verdien og behandler like preferanser som likeverdige. Bare hvis ingen MX finnes, gjelder domenet selv som implisitt mål. Når MX-poster finnes, er en A-/AAAA-verdi ved domene-apex ikke en erstatning. Hvert MX-mål trenger egne adresser og kan ikke være et alias; et domene uten e-postmottak publiserer Null MX 0 . (RFC 5321, seksjon 5, RFC 2181, seksjon 10.3, RFC 7505).

PTR-poster løses via det omvendte adressetreet. Fremover- og reverssone har ofte ulike eiere; endringer må derfor koordineres mellom domene- og IP-adresseoperatør. En PTR er et navn, ikke et kryptografisk identitetsbevis. Mottakende e-postplattformer kan bruke konsistent fremover-/reversoppløsning som et signal, men deres konkrete omdømme- eller akseptpolicy er ingen DNS-egenskap.

SPF, DKIM og DMARC bruker DNS som publiseringskanal, men definerer egne evalueringsregler. SPF leser én logisk TXT-nyttelast og begrenser DNS-utløsende termer; DKIM adresserer nøkler via selektorer; DMARC ligger under _dmarc. Disse mekanismene hører faglig hjemme i SPF, DKIM og DMARC. DNS-administratoren må for dem først og fremst beherske eiernavn, TXT-strengoppdeling, svarstørrelse, TTL, delegering og negative cachetider korrekt.

Også LDAP og Kerberos bruker ofte SRV-poster for tjenesteoppdagelse. En SRV-post inneholder i tillegg til mål og port en prioritet og en vekt. Disse verdiene er ikke en universell konfigurasjon for lastbalansering; bare klienter som implementerer den aktuelle SRV-prosedyren, tolker dem.

Diagnostikk

Diagnostikken begynner derfor aldri med «DNS fungerer ikke», men med navn, type, klasse, forespurt server, transport og tidspunkt. Bedriftsresolovere, offentlige resolvere og autoritative servere kan midlertidig eller gjennom Split DNS og policy levere ulike svar. Dette avviket er ikke målingsstøy, men det viktigste tegnet på hvor oppløsningsveien divergerer.

Spør RRset målrettet

Resolve-DnsName kan tvinge frem en bestemt server, posttype, kun DNS og TCP. dig viser i tillegg flagg, seksjoner, RCODE, svarende server og spørringstid. Uten eksplisitt -Server eller @server testes den konfigurerte resolveren, ikke nødvendigvis den autoritative kilden.

Test TCP og DNSSEC separat

delv bruker BIND-resolver- og validatorlogikken for å kontrollere en DNSSEC-kjede. En vellykket forespørsel med +dnssec beviser derimot bare at DNSSEC-data ble forespurt og levert; den validerer ikke automatisk kjeden. Den separate TCP-testen avdekker brannmurer som tillater UDP/53, men blokkerer TCP/53.

Tøm lokale cacher målrettet

Clear-DnsClientCache tømmer cachen til Windows DNS-klienten. resolvectl styrer cachen til systemd-resolved; på systemer med nscd, dnsmasq, en lokal Unbound eller en applikasjonscache er en annen cache ansvarlig. En tømming av klienten endrer aldri cachen til en oppstrømsresolver.

Tilordne feilbildet til overleveringspunktet

Overvåking og driftskriterier

Overvåking må gjenspeile samme vei. Ett enkelt A-oppslag mot lokal standardresolver oppdager verken en ødelagt delegering, blokkert TCP, utløpte signaturer eller en sekundærserver med gammel Serial. For meldingsutveksling og identitet bør derfor minst følgende signaler samles inn separat:

• autoritative svar fra hver publiserte NS over UDP og TCP, inkludert AA-bit og SOA-Serial;
• Parent-delegering, Child-NS-RRset, Glue og ved signerte soner DS/DNSKEY-overgangen;
• rekursiv latenstid, cache-treffforhold, frekvens for Timeout, SERVFAIL, REFUSED og NXDOMAIN;
• svarstørrelse, trunkering, EDNS-feil og TCP-fallback;
• utløpstidspunkter for RRSIG-er, status for key rollover og signeringskøer;
• NOTIFY-, AXFR- og IXFR-suksess samt sonealder på hver sekundærserver;
• faglige RRset som MX, tilhørende A/AAAA-adresser, PTR og TXT-navnene som kreves for e-postautentisering.

En syntetisk test bør kontrollere både den vanlige klientveien og den autoritative kilden. Bare slik kan man skille mellom om en feil ligger i det publiserte datasettet, delegeringen, en resolvercache eller applikasjonen.

Sikkerhet og feilområder

De to serverrollene krever ulike beskyttelsestiltak. Rekursjon skal bare være tilgjengelig for pålitelige klienter; en åpen resolver kan misbrukes til refleksjons- og forsterkningsangrep. Autoritative servere må derimot forbli tilgjengelige globalt, men må ikke løse vilkårlige fremmede navn rekursivt. Å blande roller øker angrepsflaten og gjør lastårsaker vanskeligere å oppdage (RFC 5358).

DNSSEC beskytter publiserte RRset mot uoppdaget endring, men ikke serverprosessen eller tilgjengeligheten. TSIG autentiserer enkeltstående DNS-meldinger med en delt nøkkel og brukes blant annet for oppdateringer og soneoverføringer; det er ingen offentlig signatur av sonedataene (RFC 8945). Overførings-ACL-er, TSIG-secrets og DNSSEC-private nøkler er separate beskyttelsesobjekter.

Split DNS og policy-svar kan være nødvendige, men skaper flere sannheter for samme QNAME/QTYPE. Minst tilordningskriterium, kildesone, videresendingsvei, DNSSEC-atferd og overvåking per View må dokumenteres. Ellers blir et ønsket avvik tolket som cachefeil eller replikeringsproblem ved neste feil.

Teknisk historie

Før DNS distribuerte Internett sentralt vedlikeholdte vertstabeller. Med flere nettverk, verter og uavhengige operatører ble denne metoden en flaskehals. Paul Mockapetris beskrev i 1983 en hierarkisk delegerbar navnetjeneste i RFC 882 og RFC 883. RFC 1034 og RFC 1035 erstattet denne versjonen i 1987 og utgjør fortsatt kjernen i systemet som STD 13.

Den første fungerende serverimplementeringen Jeeves kjørte i 1983/84 på DEC-TOPS-20-systemer. Kort tid etter oppsto Berkeley Internet Name Domain Package BIND for Unix ved University of California, Berkeley, med DARPA-finansiering. BIND 8 kom i 1997, og BIND 9 i september 2000 som en omfattende nyutvikling. Denne utviklingshistorien dokumenteres av ISC i A Brief History of the DNS and BIND.

Protokollen vokste gradvis uten å erstatte den hierarkiske kjernen: NOTIFY og IXFR fremskyndet soneavstemming på 1990-tallet, EDNS utvidet meldingsmodellen i 1999 og ble senere konsolidert i RFC 6891, DNSSEC fikk de grunnleggende DNSKEY-/DS-/RRSIG-mekanismene som gjelder i dag i 2005, og krypterte resolvertransporter kom til med DoT, DoH og DoQ. DNS er derfor ikke en frosset protokoll fra 1987, men et utvidbart system der bakoverkompatibilitet og lange cachetilstander preger enhver endring i drift.

Kilder

• RFC Editor – STD 13: Domain Name System
• RFC 9499 – DNS Terminology – aktuelle begreper for roller, soner, cache, DNSSEC og transport.
• RFC 1034 – Domain Names: Concepts and Facilities – navnerom, soner, delegering, resolvere og serverroller.
• RFC 1035 – Domain Names: Implementation and Specification – wire-format, Resource Records, meldingsseksjoner og masterfiler.
• RFC 6891 – Extension Mechanisms for DNS (EDNS(0)) – OPT, utvidede flagg og UDP-nyttelast.
• RFC 2181, seksjon 5
• AAAA
• RFC 2782 – A DNS RR for specifying the location of services – oppbygning og valg av SRV-poster.
• RFC 8659 – DNS Certification Authority Authorization – CAA-poster og evaluering av sertifikatmyndigheter.
• RFC 2308 – Negative Caching of DNS Queries – NXDOMAIN, NODATA, SOA og negativ cachetid.
• RFC 7766 – DNS Transport over TCP – obligatorisk TCP-støtte og forbindelsesatferd.
• RFC 7858 – DNS over TLS – DNS over TLS.
• RFC 8484 – DNS Queries over HTTPS – DNS over HTTPS.
• RFC 9250 – DNS over Dedicated QUIC Connections – DNS over QUIC.
• RFC 4033 – DNS Security Introduction and Requirements – DNSSEC-beskyttelsesmål, validering og grenser.
• RFC 4034 – Resource Records for DNSSEC – DNSKEY, DS, RRSIG og NSEC.
• RFC 1996 – DNS NOTIFY – varsling av sekundærservere.
• RFC 5936 – DNS Zone Transfer Protocol (AXFR) – komplette soneoverføringer over TCP.
• RFC 1995 – Incremental Zone Transfer (IXFR) – inkrementell soneavstemming.
• RFC 2136 – Dynamic Updates in DNS – atomiske endringer med Prerequisites.
• BIND 9
• Unbound Documentation – unbound(8) – rekursiv cache og DNSSEC-validering.
• Knot DNS – kun autoritativ implementering og driftsfunksjoner.
• Microsoft Learn – DNS in Windows Server – Windows-DNS-roller, AD-integrasjon, cache og videresending.
• RFC 5321, seksjon 5
• RFC 7505 – Null MX – eksplisitt merking av domener uten e-postmottak.
• Microsoft Learn – Resolve-DnsName – DNS-forespørsler i Windows.
• ISC BIND 9 – dig – forespørselsalternativer, servervalg og tolkning av utdata.
• Clear-DnsClientCache
• resolvectl
• RFC 5358 – Preventing Use of Recursive Nameservers in Reflector Attacks – rekursjonsbegrensning og misbruksbeskyttelse.
• RFC 8945 – Secret Key Transaction Authentication for DNS (TSIG) – meldingsautentisering for oppdateringer og overføringer.
• ISC – A Brief History of the DNS and BIND – Jeeves, Berkeley, BIND 8 og BIND 9.