Modul 8 · 8.4
Vanlige feil
Modul 8: Sikkerhet og feilsøking · Lesetid: 10 minutter
Læringsmål: Etter denne leksjonen kjenner du igjen de ti vanligste DNS-feilene på symptomet deres, og vet hvordan du løser dem.
Kjernebegreper: punktum på slutten, dobbelt domenenavn, endring på feil sted, to SPF-poster, CNAME på det rene domenet, glemt AAAA, MX uten adresse, proxy for e-post, gammel DS etter overføring, cache
Slik bruker du denne leksjonen
Feilene nedenfor kommer ikke fra en lærebok, men fra spørsmål som hostingselskaper får hver uke. For hver feil ser du: hva brukeren merker, hvordan du påviser det med ett spørsmål, og hva løsningen er. Når du har et problem, begynner du alltid med de samme to spørsmålene: hvilke navnetjenere har domenet (dig +short NS example.com) og hva svarer den autoritative navnetjeneren (dig @<navnetjener> <navn> <type>). Med det løser du allerede halvparten av tilfellene.
1. Å glemme punktumet på slutten
Symptom: en CNAME, MX eller NS fungerer ikke; en tjeneste sier "post ikke funnet".
Påvisning: dig +short CNAME shop.example.com gir shops.platform.example.example.com.
Årsak: i en sone er et navn uten punktum på slutten relativt: panelet limer ditt eget domene bak det (leksjon 2.2).
Løsning: skriv målnavnet som et fullstendig navn med punktum (shops.platform.example.). Noen paneler setter punktumet selv; sjekk hva som faktisk står der etter at du har lagret.
2. Domenenavnet dobbelt i navnet
Symptom: en verifisering eller DKIM-sjekk hos en tjeneste lykkes ikke, selv om posten "står der".
Påvisning: dig +short TXT k2._domainkey.example.com gir ingenting, men dig +short TXT k2._domainkey.example.com.example.com gir noe.
Årsak: tjenesten oppgir det fullstendige navnet (k2._domainkey.example.com) og panelet ditt setter domenet bak det én gang til.
Løsning: fyll i navnefeltet kun inn delen foran domenet ditt: k2._domainkey. Panelet viser som regel det fullstendige navnet under feltet: kontroller det.
3. Endring på feil sted
Symptom: du endrer en post, men ingenting endrer seg, selv ikke etter en dag.
Påvisning: dig +short NS example.com viser navnetjenere fra en annen part enn der du endret (for eksempel fra en nettstedbygger eller Cloudflare).
Årsak: kun parten som eier navnetjenerne, bestemmer DNS-en (leksjon 2.1). Poster et annet sted gjør ingenting.
Løsning: endre posten hos parten som har navnetjenerne, eller sett navnetjenerne tilbake. Et reelt eksempel: noen satte navnetjenerne til en nettstedbyggerplattform for nettstedet, men A-posten for mail sto ikke der. Resultat: å sende fungerte, å motta ikke, fordi MX-en pekte til mail.example.com og det navnet fantes ikke lenger.
4. To SPF-poster
Symptom: e-post havner oftere i spam eller blir avvist, siden du koblet til en ny tjeneste.
Påvisning: dig +short TXT example.com gir to linjer som begynner med v=spf1.
Årsak: den nye tjenesten sa "legg til denne SPF-posten", og det ble gjort bokstavelig. Med to SPF-poster er SPF ugyldig (permerror, RFC 7208), noe som er verre enn ingen SPF.
Løsning: slå dem sammen til én post: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Vær oppmerksom på grensen på ti oppslag (leksjon 4.3).
5. En CNAME på det rene domenet
Symptom: panelet avviser posten, eller etter lagring fungerer ikke e-posten din lenger.
Påvisning: tjenesten ber om "lag en CNAME for @".
Årsak: en CNAME kan ikke stå ved siden av andre poster, og på det rene domenet står det alltid SOA- og NS-poster (og ofte MX og TXT). Se leksjon 3.2.
Løsning: bruk på @ A-posten (og eventuelt AAAA) som tjenesten oppgir, og CNAME-en kun for www eller et underdomene. Noen DNS-leverandører har en ALIAS eller "CNAME flattening" for dette tilfellet.
6. Å glemme AAAA ved en overføring
Symptom: etter en overføring ser en del av besøkerne (ofte mobil) fortsatt den gamle siden, eller en sertifikatfeil.
Påvisning: dig +short A example.com gir den nye adressen, dig +short AAAA example.com fortsatt en adresse til den gamle serveren.
Årsak: enheter med IPv6 bruker fortrinnsvis AAAA. Kun A-en er endret.
Løsning: endre AAAA-en samtidig, eller fjern den hvis den nye serveren ikke har IPv6. Et reelt eksempel: ved kobling av en nettbutikkplattform måtte den gamle AAAA-en fjernes i tillegg til den nye A-posten, ellers forble butikken utilgjengelig for en del av besøkerne.
7. En MX som peker til ingenting
Symptom: du mottar ingen e-post; avsendere får en feilmelding tilbake.
Påvisning: dig +short MX example.com gir 10 mail.example.com., men dig +short A mail.example.com gir ingenting (NXDOMAIN).
Årsak: en MX peker til et navn, og det navnet må ha en A- eller AAAA-post. Ofte er A-posten for mail forsvunnet ved en overføring av navnetjenere. En MX kan heller ikke peke til en IP-adresse eller til en CNAME (RFC 2181).
Løsning: lag en A-post for e-postserverens navn, eller la MX-en peke til et navn som faktisk har en adresse.
8. E-post et annet sted, men den gamle serveren tror den skal levere e-posten
Symptom: e-post utenfra kommer greit inn hos den nye leverandøren din, men e-post fra ditt eget nettsted (kontaktskjema, nettbutikk) kommer aldri frem. Noen ganger får du 550 Unknown user.
Påvisning: MX-en peker til den nye leverandøren, men på webserveren er lokal e-postlevering fortsatt aktivert.
Årsak: dette er ikke en DNS-feil, men det ser slik ut. En webserver som tror den selv har postboksene, ser ikke på MX-en.
Løsning: slå av lokal levering i hostingpanelet (i DirectAdmin: avkrysningsboksen "Use this server to handle my e-mails"). Andre paneler har en tilsvarende innstilling, ofte kalt "Remote mail exchanger" eller "e-post ekstern".
9. Proxy på for e-post
Symptom: hos en DNS-leverandør med proxyfunksjon (som den oransje skyen hos Cloudflare) fungerer nettstedet, men e-postprogrammet ditt kan ikke koble til, eller sertifikatet for siden blir ikke fornyet.
Påvisning: dig +short A mail.example.com gir en adresse til proxyen i stedet for e-postserveren din.
Årsak: en webproxy videresender kun webtrafikk, ikke e-post.
Løsning: slå av proxyen (grå sky, "DNS only") for mail og alle navn som e-postprogrammet ditt bruker. For sertifikater: slå av proxyen midlertidig til sertifikatet er på plass, eller bruk riktig SSL-innstilling hos proxyen.
10. Gammel DS etter en overføring
Symptom: etter en overføring av navnetjenere er domenet ditt utilgjengelig for en del av verden; andre merker ingenting.
Påvisning: dig example.com @1.1.1.1 gir SERVFAIL, dig +cd example.com @1.1.1.1 gir et svar. DNSViz (https://dnsviz.net/, leksjon 8.1) farger DS-en rød og tegner under den en grå, stiplet nøkkel som ikke lenger står i sonen din. Zonemaster og Verisign DNSSEC Debugger melder det samme i ord.
Årsak: hos registeret står fortsatt DS-en til den gamle parten (leksjon 8.1). Kun validerende resolvere feiler, derfor merker ikke alle det.
Løsning: få DS-en oppdatert med nøkkelen til den nye parten, eller fjern den og slå på DNSSEC på nytt etterpå.
Og "feilen" som ikke er en feil: cachen
Veldig ofte er alt riktig, men du ser fortsatt det gamle svaret. Du kjenner den igjen slik: dig @<navnetjener> gir det nye svaret, en nettbasert sjekker i andre land også, bare ikke din egen datamaskin. Løsning: privat vindu, telefon via 4G/5G, eller tøm cachen din (leksjon 8.2). Også en glemt linje i hosts-filen på datamaskinen din (fra en tidligere test før en overføring) gir dette bildet: fjern den linjen.
En relatert felle: å slå opp et nytt navn før du har opprettet det. Resolveren husker da "finnes ikke" (negativ cache) og det tar lengre tid før det nye navnet fungerer (leksjon 6.2).
I praksis: slik ser det ut i et panel
Mange paneler forhindrer en del av disse feilene. Min side varsler for eksempel hvis punktumet på slutten mangler, og viser det fullstendige navnet under navnefeltet; DirectAdmin avviser poster som ikke er gyldige, med "Error Writing Records". Cloudflare og andre leverandører har tilsvarende varsler. Lag en sikkerhetskopi eller eksport av sonen din før større endringer, slik at du alltid kan gå tilbake.
Oppsummering
- Begynn alltid med: hvilke navnetjenere, og hva sier den autoritative navnetjeneren.
- De fleste feil ligger i navnet (punktum, dobbelt domenenavn) eller i stedet (feil part).
- Én SPF-post, ingen CNAME på @, flytt AAAA med, MX til et navn med adresse.
- SERVFAIL etter en overføring er som regel en gammel DS.
- Hvis bare du ser det gamle svaret, er det cachen din eller hosts-filen.
Quiz
Oppgave
Oppgave Z8.4: Gjenkjenne feil. Du får fem korte caser med utdata fra dig til hver (i kursmiljøet). Velg for hver case hvilken av de ti feilene det er. Deretter en ekte undersøkelse: finn ut med dig eller et nettbasert verktøy hvilken post som er feil for dnssec-failed.org (status og hva +cd gir), og om wikipedia.org har nøyaktig én SPF-post.
Les mer
Disse artiklene beskriver løsningene i panelene til WebOké; hos andre leverandører heter knappene noe annet.
- Nettsiden eller e-posten fungerer ikke etter en flytting eller DNS-endring: sjekk domenet ditt
- Hvor lenge tar en nameserver- eller DNS-endring, og hva om du ikke ser den?
- DirectAdmin-veiledning 18.7: Domenet mitt fungerer ikke ennå etter en flytting eller endring
- DirectAdmin-veiledning 18.9: Jeg mottar ikke lenger e-post
- DirectAdmin-veiledning 5.4: CNAME-records og punktumet til slutt
- Sending av e-post via PHP virker ikke, MX-postene peker et annet sted
- Bruk egne eller eksterne nameservere (som Cloudflare) for domenet ditt