Vanlige DNS-feil – feilsøk nettside og e-post steg for steg

DNS-feil er små linjer med stor rekkevidde. Én gammel A-post kan sende kunder til feil nettside. En glemt MX-post kan stoppe mottak av e-post. En utdatert DS-post kan gjøre hele domenet ugyldig for resolvere som validerer DNSSEC.

Den tryggeste metoden er ikke å gjette posten. Start med symptomet, finn autoritative navnetjenere og sammenlign svaret som faktisk publiseres med det dokumenterte oppsettet. Endre én ting om gangen.

Før dere endrer noe

Sikre et øyeblikksbilde av:

• alle DNS-poster og TTL-verdier
• navnetjenerne som er registrert hos registrar
• tidspunkt og tidssone for feilen
• siste DNS-, hosting-, e-post- eller sertifikatendring
• resultater fra minst to uavhengige nettverk eller resolvere
• den eksakte nettleser-, DNS- eller SMTP-feilen

Eksporter sonen hvis leverandøren støtter det. Skjermbilder er bedre enn ingenting, men en tekstlig eksport er enklere å sammenligne og gjenopprette.

Ikke bytt navnetjenere, slett ukjente poster eller «nullstill DNS» før dere vet hva sonen inneholder. Domenet kan ha e-post, verifisering, underdomener og tredjepartstjenester som ikke er synlige på forsiden.

Finn stedet som faktisk publiserer DNS

Et domene kan vises i kontrollpanelet hos registrar, webhotell, e-postleverandør og Cloudflare samtidig. Bare navnetjenerne i den aktive delegeringen er autoritative for sonen.

På macOS eller Linux:

dig eksempel.no NS +short

På Windows:

nslookup -type=NS eksempel.no

Bytt eksempel.no med domenet dere har ansvar for. Endre poster i systemet som styrer disse navnetjenerne. Et gammelt DNS-panel kan fortsatt la dere lagre endringer uten at de blir publisert på internett.

Hvis registrarens delegering og NS-postene i sonen er forskjellige, må avviket undersøkes. Rekursive resolvere følger delegeringen fra foreldresonen, ikke kontrollpanelet dere tilfeldigvis er logget inn i.

Spør autoritativ navnetjener direkte

Finn ett av navnene fra NS-oppslaget og spør det direkte:

dig @ns1.leverandor.example eksempel.no A
dig @ns1.leverandor.example eksempel.no MX

Gjenta mot alle autoritative navnetjenere. Ulike svar kan bety at sonen ikke er synkronisert, at endringen ikke er publisert til alle noder, eller at dere spør tjenere som ikke tilhører samme aktive oppsett.

Sammenlign deretter rekursive resolvere:

dig @1.1.1.1 eksempel.no A
dig @8.8.8.8 eksempel.no A

Autoritative svar viser hva kilden publiserer nå. Rekursive svar kan være eldre til TTL utløper. Denne forskjellen skiller en cacheforsinkelse fra en feil i selve sonen.

NXDOMAIN, NODATA og SERVFAIL betyr ulike ting

NXDOMAIN

NXDOMAIN betyr at det spurte navnet oppgis som ikke-eksisterende. Kontroller:

• om hele domenet fortsatt er registrert
• om navnet er skrevet riktig
• om delegeringen finnes
• om den aktuelle underdomeneposten er opprettet
• om en wildcard-post var forventet, men mangler

Viser Chrome DNS_PROBE_FINISHED_NXDOMAIN, bruk den målrettede NXDOMAIN-guiden for å finne om navnet mangler lokalt eller autoritativt.

NODATA

Et svar kan være vellykket, men uten den posttypen dere spurte etter. Domenet kan for eksempel finnes med MX og TXT, men mangle A. Dette er ikke NXDOMAIN. Sjekk om en annen type, som CNAME eller AAAA, var forventet.

SERVFAIL

SERVFAIL betyr at resolveren ikke kunne returnere et gyldig svar. Vanlige årsaker er:

• DNSSEC-validering feiler
• autoritative navnetjenere svarer ikke eller nekter
• delegering eller glue er feil
• svar er for store eller virker ikke over TCP
• en navnetjener har intern feil

Når navnetjeneren ligger under domenet den betjener, bør dere sammenligne parent glue med A- og AAAA-svarene i barnesonen før dere antar at feilen bare er cache.

Googles offisielle feilsøking for domener i Public DNS viser hvordan utvidede DNS-feil, flere resolvere og direkte autoritative oppslag kan snevre inn årsaken.

Ikke «løse» en DNSSEC-feil ved å bruke en resolver som ikke validerer. Rett nøkkel-, signatur- eller DS-kjeden.

Nettsiden går til feil server

Kontroller både IPv4 og IPv6:

dig eksempel.no A +short
dig eksempel.no AAAA +short

En vanlig feil etter flytting er at A peker til ny server, mens en gammel AAAA-post fortsatt peker til forrige server. Brukere med fungerende IPv6 kan da få en annen side eller feil, mens andre ser riktig nettsted.

Sammenlign alle adresser med leverandørens instruks. Ikke slett AAAA bare fordi dere ikke kjenner den; bekreft først om den inngår i aktiv hosting eller CDN.

Hvis DNS-svaret er riktig, fortsetter feilsøkingen på TLS, proxy, webserver og applikasjon. Bruk runbooken når nettsiden er nede i stedet for å fortsette å endre DNS.

www virker, men rotdomenet feiler

www.eksempel.no og eksempel.no er to forskjellige DNS-navn. Begge må ha et gyldig oppsett hvis begge skal brukes.

Et vanlig mønster er:

eksempel.no.      A      192.0.2.30
www.eksempel.no.  CNAME  eksempel.no.

Plattformen kan i stedet gi egne A-, AAAA- eller CNAME-verdier. Følg dens dokumentasjon og velg én offentlig hovedvariant med HTTP-redirect fra den andre.

CNAME på soneapex

Et vanlig CNAME kan ikke stå på samme navn som andre data. Soneapex må allerede ha SOA og NS, og kan derfor ikke være en ordinær CNAME. Noen DNS-leverandører tilbyr ALIAS, ANAME eller CNAME flattening og returnerer adresseinformasjon på vegne av kunden. Det er en leverandørfunksjon, ikke en vanlig CNAME på apex. Se hva et flattened svar skal inneholde og hvordan det testes hvis panelet og dig viser ulike typer.

Les CNAME og A-post sammenlignet før dere endrer rotdomenet.

Endringen synes bare for noen

Dette er ofte cache, men ikke alltid. Kontroller:

• gammel TTL før endringen
• om alle autoritative navnetjenere svarer likt
• om IPv4 og IPv6 peker samme sted
• om kontor-DNS bruker intern eller filtrert sone
• om CDN eller nettleser viser cachet innhold etter at DNS er riktig

Å senke TTL etter endringen tømmer ikke svar som allerede er cachet med gammel verdi. Senk den minst én gammel TTL-periode før et planlagt bytte. Etter stabilisering bør TTL settes tilbake til en verdi som passer driften.

Ikke bruk globale «DNS propagation checkers» som eneste bevis. De kan spørre ulike resolvertyper og presentere cache som om hver by var en autoritativ kilde. Sammenlign parent, autoritative tjenere og navngitte resolvere.

E-post mottas ikke

Kontroller MX:

dig eksempel.no MX +short

Sammenlign alle mål og prioriteter med den aktive e-postleverandørens instruks. Gamle og nye MX-sett samtidig kan splitte levering. Et MX-mål må være et vertsnavn med A- eller AAAA-adresser, ikke en IP-adresse eller CNAME.

MX styrer mottak, men ikke om en bestemt postboks finnes. Hvis MX er riktig, test mottakeren, leverandørstatus, kvote og SMTP-returmelding. Se MX-poster forklart og feilsøking når e-post ikke mottas .

E-post sendes, men autentisering feiler

Flere SPF-poster

Et navn skal ha én SPF-policy. Flere separate TXT-poster som begynner med v=spf1 er ikke en måte å legge sammen tjenester på. RFC 7208 sier at flere SPF-poster for samme eiernavn ikke er tillatt; resultatet blir en permanent tolkningsfeil.

Samle bare autoriserte sendere i én kontrollert policy og pass grensen for DNS-oppslag. Ikke kopier inn en ny policy uten å beholde legitime eksisterende avsendere.

DKIM på feil selector

DKIM-nøkkelen ligger vanligvis på et navn som:

selector1._domainkey.eksempel.no

selector1 kommer fra avsendertjenesten. En nøkkel på @, _domainkey eller feil selector blir ikke funnet av mottakeren. Kontroller selector i den faktiske DKIM-signaturen eller leverandørens oppsett.

DMARC på feil navn

DMARC-policyen ligger på:

_dmarc.eksempel.no

En DMARC-verdi på rotdomenet er bare en TXT-tekst; mottakere slår den ikke opp der som DMARC-policy. Start med overvåking og rapporter før streng avvisning. Se SPF, DKIM og DMARC samlet for kontrollert innføring.

SSL kan ikke utstedes

DNS kan påvirke både domenevalidering og hvem som får utstede sertifikat.

Kontroller:

• at A og AAAA peker til plattformen som utfører valideringen
• at en forventet validerings-CNAME eller TXT finnes på riktig navn
• om HTTP- eller DNS-utfordringen blir endret av proxy
• om CAA tillater sertifikatutstederen plattformen bruker
• om DNSSEC gjør at CAA-oppslaget feiler

CAA autoriserer sertifikatutstedere før utstedelse. RFC 8659 beskriver CAA som en nødvendig, men ikke tilstrekkelig kontroll for utstedelse. En CAA-feil opphever ikke i seg selv et allerede utstedt sertifikat, men kan blokkere nyutstedelse eller fornyelse.

Ikke slett CAA permanent for å skjule problemet. Finn riktig utsteder og publiser en bevisst policy. Les CAA-poster forklart .

Cloudflare-proxy brukes på feil navn

MX-posten kan ikke proxieres gjennom en vanlig webproxy. Vertsnavnet MX peker til, må også følge e-postleverandørens krav. Cloudflares veiledning for e-postrelaterte DNS-feil sier at MX alltid er DNS-only, og at målet også må løses til et DNS-only-oppsett.

Vanlige kandidater for DNS-only er:

• e-posttjenere
• FTP, SFTP og SSH når leverandøren krever direkte forbindelse
• tredjepartsverifiseringer
• tjenester Cloudflare ikke proxyer

Websidens A-, AAAA- og CNAME-poster kan stå proxied når arkitekturen er laget for det. Ikke aktiver eller deaktiver proxy på alle poster i en masseendring.

DNSSEC feiler etter bytte

Et vanlig scenario er at sonen flyttes til ny DNS-leverandør, mens DS-posten hos .no fortsatt viser til gammel nøkkel. Validerende resolvere mottar da svar de ikke kan knytte til kjeden og returnerer ofte SERVFAIL.

Kontroller:

• DS i foreldresonen
• DNSKEY hos aktiv DNS-leverandør
• gyldige RRSIG-signaturer
• om alle navnetjenere publiserer samme signerte sone
• om nøkkelbyttet fulgte leverandørens rekkefølge

Endre ikke DS ved å gjette digest eller nøkkel-ID. Bruk verdien fra den aktive signeringstjenesten og prosessen hos registraren. Se DNSSEC forklart .

Gamle poster kan være en sikkerhetsrisiko

Gamle TXT-verifiseringer er ofte bare støy. En gammel CNAME til en avsluttet sky- eller publiseringstjeneste kan være farligere. Hvis leverandøren har frigitt ressursen, kan andre i enkelte plattformer gjøre krav på navnet og få trafikk til underdomenet.

Før sletting:

1. identifiser hvem som opprettet posten
2. kontroller om tjenesten fortsatt brukes
3. fjern bindingen hos tjenesten når det er mulig
4. fjern DNS-posten
5. test at ingen lenker, sertifikater eller integrasjoner avhenger av den

Bruk guiden til subdomain takeover når et gammelt mål peker til en ekstern plattform.

Rask beslutningstabell

Etter rettingen

Test fra autoritative tjenere og minst to rekursive resolvere. Kontroller både nettside med og uten www, innkommende og utgående e-post, sertifikat og kritiske underdomener. Noter hva som ble endret og sett midlertidig lav TTL tilbake når løsningen er stabil.

Hvis hendelsen påvirket kunder, skriv en kort tidslinje og ett forebyggende tiltak. Det kan være tilgangskontroll, soneeksport, overvåking, endringsgodkjenning eller en ferdig rollback-plan.

Hvis domenet er bestilt gjennom Vymo

Vymo har ikke et selvbetjent registrar- eller DNS-panel i standardtilbudet. Domeneordrer og endringer håndteres manuelt og bekreftes på e-post. Det reduserer tilfeldige klikk, men gjør det viktig å sende presise opplysninger.

Ved en DNS-feil kan dere kontakte Vymo med domenet, tidspunkt, nøyaktig symptom, hvilke tjenester som er berørt og hvilke endringer som nylig er gjort. Send gjerne tekst fra dig eller skjermbilde, men ikke passord, API-nøkler, private nøkler eller sensitivt e-postinnhold.

Har dere bare .no-domenet hos Vymo, mens DNS, nettside eller e-post ligger hos en annen leverandør, kan Vymo hjelpe med å bekrefte delegeringen. Den ansvarlige tjenesteleverandøren må rette feil i sin sone, server eller applikasjon.

DNS-feilsøking blir raskere når dere skiller kilde fra cache og navn fra posttype. Bevar sonen, spør autoritativt og rett én dokumentert feil om gangen.