Sjekke DNS-poster – finn fasit, cache og feil svar

Når nettstedet viser feil side, e-post ikke kommer frem eller domeneverifisering feiler, må dere kontrollere hva DNS faktisk publiserer – ikke bare hva et kontrollpanel viser.

Et godt DNS-bevis inneholder fire ting:

navn + posttype + server som svarte + tidspunkt

«DNS er feil» er for uklart. «Autoritative servere returnerer ny A, mens resolver X fortsatt returnerer gammel adresse med 420 sekunder TTL» peker på cache og et avgrenset ventevindu.

Start med hele dig-svaret

dig bedrift.no A

Ikke bruk +short i første feilsøking. Det skjuler status, flagg, TTL og serveren som svarte.

Se etter:

Når grunnlaget er forstått, er +short praktisk i skript og raske kontroller:

dig bedrift.no A +short

Skriv alltid hele navnet og typen

Disse er ulike spørsmål:

dig bedrift.no A
dig www.bedrift.no A
dig bedrift.no AAAA
dig www.bedrift.no CNAME

Et tomt CNAME-svar betyr ikke at www mangler. Navnet kan ha A/AAAA direkte. Et tomt A-svar betyr ikke at hele navnet mangler; det kan finnes med MX, TXT eller bare AAAA.

Bruk det fullstendige vertsnavnet i supportsaken, ikke «domenet» dersom feilen gjelder butikk.bedrift.no.

Finn de autoritative navnetjenerne

dig bedrift.no NS +short

Dette vanlige oppslaget går gjennom en rekursiv resolver og kan være cachet. For delegeringsfeil kan dere følge kjeden:

dig +trace bedrift.no NS

En trace spør trinnvis fra roten via toppdomenet til barnesonen. Den viser delegeringsveien fra maskinen som kjører testen, men ikke nødvendigvis samme cache som en berørt bruker.

Spør autoritativ DNS direkte

Anta at en aktiv server heter ns1.dnsleverandor.example:

dig @ns1.dnsleverandor.example bedrift.no A +norecurse
dig @ns1.dnsleverandor.example bedrift.no SOA +norecurse

Gjenta mot alle navnetjenerne. De skal svare autoritativt og publisere konsistente sonedata.

Hvis én server avviker, kan brukerne få tilfeldige svar avhengig av hvilken autoritativ server resolveren spør. Det er ikke vanlig propagering; DNS-leverandøren må synkronisere sonen.

Autoritativt svar er fasiten for hva sonen publiserer nå. Det beviser ikke at IP-en har riktig nettsted, at MX-serveren godtar mottakere eller at TXT-policyen er forretningsmessig korrekt.

Sammenlign med rekursive resolvere

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

Offentlige resolveradresser er eksempler. Test også resolveren den berørte enheten faktisk bruker, særlig i bedrift, VPN eller mobilnett.

Nettleseren kan bruke DoH, operativsystemet en annen resolver og dig en tredje. Noter derfor hvilken klient og resolver testen representerer.

Sjekk nettstedets A, AAAA og CNAME

dig bedrift.no A
dig bedrift.no AAAA
dig www.bedrift.no CNAME
dig www.bedrift.no A
dig www.bedrift.no AAAA

Kontroller IPv4 og IPv6 separat. En gammel AAAA-post kan sende IPv6-brukere til en annen server selv om A er riktig.

Et CNAME-oppslag viser aliasmålet. A-oppslaget for samme navn kan vise hele eller deler av kjeden og sluttadressene. Ved proxied DNS eller CNAME flattening kan offentlig A/AAAA være plattformens adresser selv om panelet viser et vertsnavn.

DNS viser nettverksmålet, ikke:

• riktig HTTP-redirect
• gyldig TLS-sertifikat
• riktig virtuelt nettsted
• om skjemaet sender
• om siden har ønsket innhold

Test tjenesten etter DNS-oppslaget.

Sjekk MX og e-postmottak

dig bedrift.no MX

Et MX-svar inneholder prioritet og mål:

bedrift.no. 3600 IN MX 10 mx1.epostleverandor.example.

Lavere tall har høyere prioritet. Sammenlign hele settet med e-postleverandørens dokumentasjon.

Hvis MX-spørsmålet gir NOERROR uten Answer, finnes navnet, men ikke MX-typen. Det kalles ofte NODATA. En sender kan i enkelte eldre fallbackmodeller forsøke adressen til domenet, men det er ikke et riktig oppsett for en administrert e-posttjeneste. Publiser leverandørens dokumenterte MX.

Et korrekt MX-svar beviser ikke at mottakeren finnes, at spamfilteret godtar meldingen eller at utgående e-post er autentisert. Test en ekte melding begge veier og les fullstendige headere.

Sjekk TXT og SPF uten å miste sammenhengen

dig bedrift.no TXT

TXT kan inneholde flere uavhengige verdier. Finn SPF-posten som starter med v=spf1 og kontroller at det bare finnes én SPF-policy på navnet.

Lange TXT-verdier kan vises som flere anførte tekstbiter i ett DNS-svar. De kan være én ressursoppføring som settes sammen ved tolkning, ikke nødvendigvis flere poster.

grep spf kan være praktisk, men skjuler status og andre TXT-data. Behold råsvaret i dokumentasjonen.

Sjekk DKIM med riktig selector

DKIM ligger ikke på ett universelt navn. E-postleverandøren oppgir selector, for eksempel selector1:

dig selector1._domainkey.bedrift.no TXT
dig selector1._domainkey.bedrift.no CNAME

Noen leverandører bruker TXT med offentlig nøkkel, andre CNAME til et leverandørnavn. Et tomt svar på feil type er derfor ikke nok.

Ikke gjett selector ved å prøve en lang liste mot andres domener. Bruk konfigurasjonen eller en signert meldings DKIM-Signature-header.

Sjekk DMARC på _dmarc

dig _dmarc.bedrift.no TXT

DMARC-posten skal begynne med v=DMARC1. Kontroller at det bare finnes én DMARC-post for policy-navnet, og at p, eventuelle underdomeneregler og rapportadresser er tilsiktet.

At teksten kan hentes betyr ikke at SPF/DKIM alignment er riktig for alle avsendere. Bruk autentiseringsresultater i faktiske meldinger og rapportdata.

Sjekk CAA før sertifikatutstedelse

dig bedrift.no CAA
dig www.bedrift.no CAA

CAA kan arves fra overliggende navn etter oppslagsreglene. Kontroller hvert sertifikatnavn og eventuell CNAME-kjede. En feil CAA kan stoppe utstedelse eller fornyelse uten å påvirke et sertifikat som allerede er aktivt.

Sjekk NS, SOA og serial

dig bedrift.no NS
dig bedrift.no SOA

NS viser autoritative navn. SOA viser blant annet MNAME, kontakt, serial og tidsverdier. Sammenlign SOA mot hver navnetjener:

dig @ns1.dnsleverandor.example bedrift.no SOA +short
dig @ns2.dnsleverandor.example bedrift.no SOA +short

Ulik serial kan være et kort synkroniseringsvindu, men skal ikke bli stående. Samme serial med ulike kritiske poster er også en feil og viser at serial alene ikke er full konsistenskontroll.

Sjekk DNSSEC og HTTPS/SVCB

dig bedrift.no A +dnssec
dig bedrift.no DS +dnssec
dig bedrift.no DNSKEY +dnssec
dig bedrift.no HTTPS +dnssec

+dnssec ber om DNSSEC-data, men er ikke alene en full lokal validering. Sammenlign en validerende resolver og bruk en DNSSEC-analyse når SERVFAIL mistenkes.

Eldre dig kan vise HTTPS-posten som TYPE65:

dig bedrift.no TYPE65

Tolk statuskodene riktig

Et tomt +short-resultat skjuler forskjellen mellom NODATA, NXDOMAIN, SERVFAIL og timeout. Det er derfor «vent og prøv igjen» ofte er feil tiltak.

ANY er ikke en soneeksport

dig bedrift.no ANY

Servere kan begrense ANY-svar, og spørsmålet gjelder bare ett navn. Det finner ikke automatisk www, DKIM-selectorer, underdomener eller alle poster i sonen.

Bruk kontrollpanelets eksport, intern dokumentasjon eller et autorisert soneinventar ved flytting. Ikke forsøk AXFR mot domener dere ikke drifter.

Nettbaserte verktøy er sekundære observatører

En nettbasert DNS-sjekker kan være nyttig for å se svar fra flere steder, men:

• den bruker sin egen resolver og sitt eget nettverk
• «grønne» regler kan være leverandørens mening, ikke en DNS-standard
• den vet ikke hvilke verdier avtalen deres krever
• testdomener og resultater deles med en tredjepart
• den viser ikke nødvendigvis autoritativ fasit

Bruk slike verktøy som ekstra observasjon. Behold direkte autoritative og relevante rekursive oppslag som hovedbevis.

En feilsøkingsrapport som kan handles på

Ta med:

• domenenavn og eksakt vertsnavn
• posttype
• forventet verdi og kilden til forventningen
• aktive navnetjenere
• rått autoritativt svar fra hver server
• rått svar fra berørt resolver
• tidspunkt og tidssone
• TTL og statuskode
• om IPv4, IPv6, VPN eller DoH er brukt
• hva tjenestetesten faktisk viste

Fjern passord, API-nøkler, flyttekoder, TSIG-hemmeligheter og private DNSSEC-nøkler. Offentlige DNS-svar kan deles, men en hel soneeksport kan inneholde driftsinformasjon som bør behandles kontrollert.

Riktig neste steg

• Gammel resolvercache: vent ut gjenværende TTL og følg autoritativ fasit.
• Feil autoritativ verdi: rett posten hos aktiv DNS-leverandør.
• Ulike autoritative svar: eskaler synkronisering til DNS-operatøren.
• DNSSEC-SERVFAIL: rett DS, DNSKEY eller signaturkjeden.
• DNS riktig, tjeneste feil: feilsøk TLS, webserver, e-post eller applikasjon.

Bruk guiden til rekursiv og autoritativ DNS for hele oppslagskjeden og vanlige DNS-feil for hendelsesrekkefølgen.

Vymo kan hjelpe med domenet og DNS-koblingen til den enkle bedriftsnettsiden vi leverer. Send eksakt navn, type, forventet verdi og rått offentlig svar via kontaktsiden . Ikke send innloggingsinformasjon eller hemmeligheter.

Den viktigste vanen er enkel: spør den autoritative kilden først, sammenlign deretter resolveren brukeren faktisk har, og test til slutt tjenesten DNS peker til.