Rekursiv og autoritativ DNS – finn hvor feilen ligger

Når to personer får ulike DNS-svar, betyr det ikke nødvendigvis at den ene testen er feil. De kan spørre ulike rekursive resolvere, med ulik cache, mens domenets autoritative navnetjenere publiserer ett annet svar.

Skillet er praktisk: Et autoritativt svar viser hva DNS-sonen publiserer nå. Et rekursivt svar viser hva en bestemt resolver gir brukeren akkurat nå.

Forskjellen på 30 sekunder

En internettleverandør, bedrifts-DNS eller offentlig tjeneste som Cloudflare Public DNS, Google Public DNS og Quad9 kan være rekursiv resolver. Navnetjenerne som domenet er delegert til, er autoritative for domenets sone.

Samme leverandør kan tilby begge typer tjenester. Rollen avgjøres av hva serveren gjør i det aktuelle oppslaget.

Slik går ett DNS-oppslag

Anta at en bruker åpner www.bedrift.no, og at resolveren ikke har et brukbart svar i cache:

1. Nettleseren ber operativsystemets stub-resolver om adressen.
2. Stub-resolveren spør den valgte rekursive resolveren.
3. Resolveren starter med rotsonen eller data den allerede har i cache.
4. Roten henviser resolveren til navnetjenere for .no.
5. .no henviser resolveren til navnetjenerne for bedrift.no.
6. En autoritativ navnetjener svarer med A, AAAA, CNAME eller et negativt svar.
7. Resolveren validerer DNSSEC når det er aktivt og resolveren støtter validering.
8. Resolveren cacher resultatet etter gjeldende TTL og returnerer det til klienten.

IANA beskriver rotsonen som toppen av DNS-hierarkiet, hovedsakelig med delegeringer til toppdomener. Det finnes 13 navngitte rotserveridentiteter, men tjenesten leveres av mange serverinstanser over hele verden. Resolveren starter altså ikke med et tilfeldig nettsøk eller en komplett kopi av internett.

RFC 1034 beskriver de to grunnmåtene å få hjelp på: Ved rekursjon skal serveren følge spørsmålet videre for klienten. Ved iterasjon returnerer serveren det beste svaret eller en henvisning, slik at den spørrende resolveren fortsetter selv.

Rekursiv betyr ikke at alle serverne spør rekursivt

Klienten ber gjerne sin resolver om et ferdig svar. Den rekursive resolveren gjør deretter normalt iterative oppslag mot DNS-hierarkiet. Rotserveren løser ikke hele www.bedrift.no på vegne av resolveren; den gir en henvisning til neste ledd.

Dette er grunnen til at «rekursiv DNS» beskriver tjenesten klienten får, mens mye av arbeidet mellom resolver og autoritative servere skjer gjennom iterative spørsmål og henvisninger.

En åpen rekursiv resolver bør ikke forveksles med en autoritativ navnetjener. Autoritative servere trenger normalt ikke tilby rekursjon til vilkårlige internettbrukere, og feilkonfigurert åpen rekursjon kan misbrukes.

Autoritativ betyr ansvar for en bestemt sone

En navnetjener er ikke autoritativ for alle navn bare fordi den kan svare på DNS. Den er autoritativ for sonene den er konfigurert til å publisere.

For bedrift.no finnes to viktige lag:

• .no-sonen publiserer delegeringen, vanligvis NS og eventuelt DS
• bedrift.no-sonen publiserer A, AAAA, MX, TXT, CNAME og øvrige poster for domenet

Foreldresonen og barnesonen kan derfor begge inneholde NS-data knyttet til domenet. De har ulike roller. Ved bytte av navnetjenere må delegeringen hos registraren og sonen hos DNS-leverandøren stemme.

Les NS-poster og delegering hvis navnetjenerbyttet er selve problemet.

Hva DNS-flaggene forteller

Kjør et vanlig oppslag:

dig bedrift.no A

I svaret kan flaggene blant annet inneholde:

Et vanlig svar fra en rekursiv resolver kan være korrekt uten aa, fordi resolveren returnerer cachet eller innhentet data. ad er bare meningsfullt når du stoler på forbindelsen til resolveren; flagget er ikke i seg selv et bevis fra den autoritative serveren.

dig +dnssec ber om DNSSEC-relaterte data. Kommandoen er ikke automatisk en full, uavhengig validering av kjeden.

Finn de autoritative navnetjenerne

Start med NS-oppslag:

dig bedrift.no NS +short

Anta at svaret inkluderer ns1.dnsleverandor.example. Spør den direkte:

dig @ns1.dnsleverandor.example bedrift.no A +norecurse
dig @ns1.dnsleverandor.example www.bedrift.no CNAME +norecurse
dig @ns1.dnsleverandor.example bedrift.no MX +norecurse

+norecurse gjør hensikten tydelig: Serveren skal svare fra egen autoritet eller gi det den ellers kan svare uten å utføre rekursjon for deg.

Gjenta mot alle autoritative navnetjenere. Hvis én server publiserer gammel sone eller ikke svarer, kan feilen virke tilfeldig fordi resolvere fordeler spørsmålene mellom serverne.

Sammenlign autoritativt og rekursivt svar

Test deretter resolvere som er relevante for berørte brukere:

dig @1.1.1.1 bedrift.no A
dig @8.8.8.8 bedrift.no A
dig @9.9.9.9 bedrift.no A

Det gir fire nyttige situasjoner:

Ikke vent på «propagering» dersom alle autoritative servere fortsatt publiserer feil verdi. Tid reparerer ikke en feil sone.

Cache forklarer forsinkelsen, men ikke alt

TTL angir hvor lenge en ressursoppføring kan beholdes i cache. Hvis en resolver hentet gammel A-post rett før endringen, kan den normalt bruke den til TTL utløper.

Også negative svar kan caches. Et nylig opprettet navn kan derfor returnere riktig autoritativt, mens en resolver fortsatt husker at navnet ikke fantes. Negativ caching styres av sonens SOA-data etter reglene for negative svar.

Moderne resolvere kan i enkelte feilsituasjoner servere utløpte data for å holde tjenester tilgjengelige, slik RFC 8767 beskriver. Derfor bør en feilsøking notere både hvilken resolver som svarte, TTL i svaret og om autoritative servere var tilgjengelige.

Følg guiden til DNS-propagering for planlagte endringer.

DNSSEC-feil vises ofte hos resolveren

Den autoritative serveren publiserer signerte data, mens en validerende rekursiv resolver kontrollerer tillitskjeden. Hvis DS i foreldresonen ikke stemmer med DNSKEY i barnesonen, kan den autoritative serveren fortsatt returnere poster. En validerende resolver kan samtidig nekte å gi dataene videre og svare SERVFAIL.

Sammenlign:

dig @1.1.1.1 bedrift.no A +dnssec
dig @ns1.dnsleverandor.example bedrift.no A +dnssec +norecurse
dig bedrift.no DS +short
dig bedrift.no DNSKEY +short

Ikke «løs» problemet permanent ved å omgå validering. Kontroller DS, DNSKEY, signaturer, klokke og delegering. RFC 4035 beskriver valideringen en sikkerhetsbevisst resolver utfører.

Se DNSSEC forklart før nøkkel- eller navnetjenerbytte.

Nettleseren kan bruke en annen resolver enn terminalen

Et dig-oppslag og et nettleserbesøk trenger ikke gå samme vei. Nettleseren kan bruke sikker DNS, bedriften kan ha intern DNS, VPN kan overstyre oppsettet, og operativsystemet kan ha egen cache.

Når bare én gruppe er berørt, noter:

• nettverk og VPN-status
• resolveradressen som faktisk brukes
• om nettleseren har egen DNS-innstilling
• om navnet bare finnes i intern DNS
• A og AAAA hver for seg
• eksakt tidspunkt og TTL

Intern og ekstern DNS kan med vilje gi ulike svar, ofte kalt split-horizon eller split DNS. Ikke publiser interne adresser eksternt for å få testene til å «matche».

Bruk +trace til å se henvisningene

dig +trace bedrift.no A

+trace lar dig følge delegeringen trinnvis fra roten. Det er nyttig når:

• foreldresonen peker til feil navnetjenere
• glue mangler eller er feil
• autoritative servere ikke svarer
• en CNAME fører til en annen sone

Sporingen viser ikke nødvendigvis samme cachede opplevelse som sluttbrukeren. Den tester selve henvisningskjeden fra maskinen som kjører kommandoen. Brannmurer og nettverk som blokkerer direkte DNS kan også påvirke resultatet.

En feilsøkingsrekkefølge som sparer tid

1. Skriv ned nøyaktig navn og posttype, for eksempel www.bedrift.no AAAA.
2. Finn delegerte navnetjenere fra foreldresonen.
3. Spør alle autoritative navnetjenere direkte.
4. Kontroller at serienummer og relevante postsett er konsistente.
5. Sammenlign med resolveren den berørte brukeren faktisk bruker.
6. Kontroller TTL, negativ cache og tidspunkt for siste endring.
7. Undersøk DNSSEC hvis validerende resolvere gir SERVFAIL.
8. Test A og AAAA separat før du går videre til HTTP, TLS eller e-post.

Lagre rå svar sammen med tidspunkt. «DNS virker ikke» er vanskelig å handle på; «resolver X returnerte gammel AAAA med 412 sekunder TTL mens begge autoritative servere returnerte ny adresse» peker på et avgrenset forhold.

Hvem skal rette hva?

Vymo kan hjelpe med domenet, DNS-oppsettet og koblingen til den enkle bedriftsnettsiden vi leverer. Send domenenavnet, posten som feiler, forventet verdi, tidspunkt og gjerne rå dig-svar via kontaktsiden . Ikke send passord, API-nøkler, flyttekoder eller private DNS-nøkler.

Begynn med autoritativ DNS for å kontrollere fasiten. Sammenlign deretter den berørte resolveren for å se hva brukeren får. Det skillet gjør cache, delegering, DNSSEC og reelle tjenestefeil langt enklere å skille fra hverandre.