Almindelige fejl
Modul 8: Sikkerhed og fejlfinding · Læsetid: 10 minutter
Læringsmål: Efter denne lektion genkender du de ti mest almindelige DNS-fejl på deres symptom, og du ved, hvordan du løser dem.
Kernebegreber: punktum til sidst, dobbelt domænenavn, ændring det forkerte sted, to SPF-records, CNAME på det rene domæne, glemt AAAA, MX uden adresse, proxy for mail, gammel DS efter flytning, cache
Sådan bruger du denne lektion
Fejlene herunder kommer ikke fra en lærebog, men fra spørgsmål som hostingudbydere får hver uge. For hver fejl ser du: hvad brugeren mærker, hvordan du påviser det med ét spørgsmål, og hvad løsningen er. Ved et problem begynder du altid med de samme to spørgsmål: hvilke navneservere har domænet (dig +short NS example.com) og hvad svarer den autoritative navneserver (dig @<nameserver> <naam> <type>). Dermed løser du allerede halvdelen af tilfældene.
1. At glemme punktummet til sidst
Symptom: en CNAME, MX eller NS virker ikke; en tjeneste siger "record ikke fundet".
Påvisning: dig +short CNAME shop.example.com giver shops.platform.example.example.com.
Årsag: i en zone er et navn uden punktum til sidst relativt: panelet tilføjer selv dit eget domæne bagefter (lektion 2.2).
Løsning: skriv målnavnet som fuldt navn med punktum (shops.platform.example.). Nogle paneler sætter selv punktummet; tjek efter gemning, hvad der reelt står.
2. Domænenavnet dobbelt i navnet
Symptom: en verifikation eller DKIM-kontrol hos en tjeneste lykkes ikke, selvom recorden "står der".
Påvisning: dig +short TXT k2._domainkey.example.com giver intet, men dig +short TXT k2._domainkey.example.com.example.com giver noget.
Årsag: tjenesten angiver det fulde navn (k2._domainkey.example.com), og dit panel tilføjer domænet endnu en gang.
Løsning: udfyld kun den del, der kommer før dit domæne, i navnefeltet: k2._domainkey. Panelet viser som regel det fulde navn under feltet: kontrollér det.
3. At ændre det forkerte sted
Symptom: du tilpasser en record, men der sker ingenting, selv ikke efter en dag.
Påvisning: dig +short NS example.com giver navneservere fra en anden udbyder end den, du ændrede hos (f.eks. fra en hjemmesidebygger eller Cloudflare).
Årsag: kun den udbyder, der har navneserverne, bestemmer DNS'en (lektion 2.1). Records et andet sted gør ingenting.
Løsning: ændr recorden hos den udbyder, der har navneserverne, eller sæt navneserverne tilbage. Et rigtigt eksempel: nogen satte navneserverne til en hjemmesidebygger for hjemmesiden, men A-recorden for mail stod ikke der. Resultatet: afsendelse virkede, modtagelse ikke, fordi MX'en pegede på mail.example.com, og det navn fandtes ikke længere.
4. To SPF-records
Symptom: mail havner oftere i spam eller afvises, siden du koblede en ny tjeneste til.
Påvisning: dig +short TXT example.com giver to linjer, der begynder med v=spf1.
Årsag: den nye tjeneste sagde "tilføj denne SPF-record", og det er gjort bogstaveligt. Med to SPF-records er SPF ugyldig (permerror, RFC 7208), hvilket er værre end ingen SPF.
Løsning: flet dem sammen til én record: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Vær opmærksom på grænsen på ti opslag (lektion 4.3).
5. En CNAME på det rene domæne
Symptom: panelet afviser recorden, eller efter gemning virker din mail ikke længere.
Påvisning: tjenesten beder om "opret en CNAME for @".
Årsag: en CNAME må ikke stå ved siden af andre records, og på det rene domæne står der altid SOA- og NS-records (og ofte MX og TXT). Se lektion 3.2.
Løsning: brug på @ den A-record (og eventuelt AAAA), som tjenesten angiver, og CNAME'en kun for www eller et subdomæne. Nogle DNS-udbydere har en ALIAS eller "CNAME flattening" til dette tilfælde.
6. At glemme AAAA ved en flytning
Symptom: efter en flytning ser en del af de besøgende (ofte mobil) stadig den gamle hjemmeside, eller der opstår en certifikatfejl.
Påvisning: dig +short A example.com giver den nye adresse, dig +short AAAA example.com stadig en adresse fra den gamle server.
Årsag: enheder med IPv6 bruger fortrinsvis AAAA'en. Kun A'en er blevet tilpasset.
Løsning: tilpas AAAA'en med, eller fjern den, hvis den nye server ikke har IPv6. Et rigtigt eksempel: ved kobling af en webshop-platform skulle den gamle AAAA også væk ud over den nye A-record, ellers forblev butikken utilgængelig for en del af de besøgende.
7. En MX, der peger på ingenting
Symptom: du modtager ingen mail; afsendere får en fejlmelding tilbage.
Påvisning: dig +short MX example.com giver 10 mail.example.com., men dig +short A mail.example.com giver intet (NXDOMAIN).
Årsag: en MX peger på et navn, og det navn skal have en A- eller AAAA-record. Ofte er A-recorden for mail forsvundet ved en flytning af navneservere. En MX må heller ikke pege på en IP-adresse eller på en CNAME (RFC 2181).
Løsning: opret en A-record for mailservernavnet, eller lad MX'en pege på et navn, der har en adresse.
8. Mail et andet sted, men den gamle server tror, den skal aflevere mailen
Symptom: mail udefra kommer fint ind hos din nye udbyder, men mail fra din egen hjemmeside (kontaktformular, webshop) kommer aldrig frem. Nogle gange får du 550 Unknown user.
Påvisning: MX'en peger på den nye udbyder, men på webserveren er lokal mailaflevering stadig slået til.
Årsag: dette er ikke en DNS-fejl, men det ligner en. En webserver, der tror, den selv har postkasserne, kigger ikke på MX'en.
Løsning: slå den lokale aflevering fra i hostingpanelet (i DirectAdmin: afkrydsningsfeltet "Brug denne server til at håndtere mine e-mails"). Andre paneler har en lignende indstilling, ofte "Remote mail exchanger" eller "e-mail eksternt".
9. Proxy slået til for mail
Symptom: hos en DNS-udbyder med proxyfunktion (som den orange sky hos Cloudflare) virker hjemmesiden, men dit mailprogram kan ikke oprette forbindelse, eller hjemmesidens certifikat bliver ikke fornyet.
Påvisning: dig +short A mail.example.com giver en adresse fra proxyen i stedet for din mailserver.
Årsag: en webproxy videresender kun webtrafik, ikke mail.
Løsning: slå proxyen fra (grå sky, "DNS only") for mail og alle navne, som dit mailprogram bruger. For certifikater: slå proxyen midlertidigt fra, indtil certifikatet er udstedt, eller brug den rette SSL-indstilling ved proxyen.
10. Gammel DS efter en flytning
Symptom: efter en flytning af navneservere er dit domæne utilgængeligt for en del af verden; andre mærker ikke noget.
Påvisning: dig example.com @1.1.1.1 giver SERVFAIL, dig +cd example.com @1.1.1.1 giver et svar. DNSViz (https://dnsviz.net/, lektion 8.1) farver DS'en rød og tegner under den en grå, stiplet nøgle, der ikke længere findes i din zone. Zonemaster og Verisign DNSSEC Debugger melder det samme i ord.
Årsag: hos registryen står stadig DS'en fra den gamle udbyder (lektion 8.1). Kun validerende resolvere fejler, derfor mærker ikke alle det.
Løsning: få DS'en opdateret med nøglen fra den nye udbyder, eller fjern den og slå DNSSEC til igen bagefter.
Og den "fejl", der ikke er en fejl: cachen
Meget ofte er alt i orden, men du ser stadig det gamle svar. Du genkender det ved: dig @<nameserver> giver det nye svar, en online tjekker i andre lande også, kun din computer ikke. Løsning: privat vindue, telefon via 4G/5G, eller tøm din cache (lektion 8.2). Også en glemt linje i computerens hosts-fil (fra en tidligere test før en flytning) giver dette billede: fjern den linje.
En beslægtet faldgrube: at forespørge på et nyt navn, før du har oprettet det. Resolveren husker så "findes ikke" (negativ cache), og det tager længere tid, før det nye navn virker (lektion 6.2).
I praksis: sådan ser det ud i et panel
Mange paneler forebygger en del af disse fejl. Mit WebOké advarer for eksempel, hvis punktummet til sidst mangler, og viser det fulde navn under navnefeltet; DirectAdmin afviser records, der ikke er gyldige, med "Error Writing Records". Cloudflare og andre udbydere har lignende advarsler. Tag en sikkerhedskopi eller eksport af din zone før større ændringer, så du altid kan gå tilbage.
Opsummering
- Begynd altid med: hvilke navneservere, og hvad siger den autoritative navneserver.
- De fleste fejl ligger i navnet (punktum, dobbelt domænenavn) eller i stedet (forkert udbyder).
- Én SPF-record, ingen CNAME på @, flyt AAAA med, MX til et navn med adresse.
- SERVFAIL efter en flytning er som regel en gammel DS.
- Hvis kun du ser det gamle svar, er det din cache eller hosts-fil.
Quiz
Opgave
Opgave Z8.4: Genkend fejlene. Du får fem korte sager med output fra dig vedlagt (i kursusmiljøet). Vælg for hver sag, hvilken af de ti fejl det er. Derefter en rigtig efterforskning: find med dig eller et online værktøj ud af, hvilken record der er forkert for dnssec-failed.org (status og hvad +cd giver), og om wikipedia.org har præcis én SPF-record.
Læs videre
Disse artikler beskriver løsningerne i WebOkés paneler; hos andre udbydere hedder knapperne noget andet.
- Websted eller e-mail virker ikke efter en flytning eller DNS-ændring: kontroller dit domæne
- En nameserver eller DNS-ændring kan tage op til 24 til 48 timer, før den er fuldt synlig overalt. Ser du ændringen ikke efter denne periode, så kontakt vores support, så hjælper vi dig videre.
- DirectAdmin vejledning 18.7: Mit domæne virker ikke endnu efter en flytning eller ændring
- DirectAdmin vejledning 18.9: Jeg modtager ikke længere e-mails
- DirectAdmin vejledning 5.4: CNAME-poster og punktummet til sidst
- Mail kan ikke sendes via PHP, MX-poster peger et andet sted hen
- Brug dine egne eller eksterne nameservers (som Cloudflare) til dit domæne