Modul 8 · 8.4
Vanliga misstag
Modul 8: Säkerhet och felsökning · Lästid: 10 minuter
Lärandemål: Efter den här lektionen känner du igen de tio vanligaste DNS-misstagen på deras symptom och vet hur du löser dem.
Kärnbegrepp: punkt i slutet, dubbel domännamn, ändring på fel ställe, två SPF-poster, CNAME på den nakna domänen, glömd AAAA, MX utan adress, proxy för e-post, gammal DS efter domänöverföring, cache
Så använder du den här lektionen
Felen nedan kommer inte från en lärobok, utan från frågor som hostingbolag får varje vecka. För varje fel ser du: vad användaren märker, hur du bevisar det med en enda fråga, och vad lösningen är. Vid ett problem börjar du alltid med samma två frågor: vilka namnservrar har domänen (dig +short NS example.com) och vad svarar den auktoritativa namnservern (dig @<namnserver> <namn> <typ>). Med det löser du redan hälften av fallen.
1. Att glömma punkten i slutet
Symptom: en CNAME, MX eller NS fungerar inte; en tjänst säger "post hittades inte".
Bevisa: dig +short CNAME shop.example.com ger shops.platform.example.example.com.
Orsak: i en zon är ett namn utan punkt i slutet relativt: panelen lägger till ditt eget domännamn efter (lektion 2.2).
Lösning: skriv målnamnet som ett fullständigt namn med punkt (shops.platform.example.). Vissa paneler lägger till punkten själva; kontrollera efter sparandet vad som verkligen står där.
2. Domännamnet dubbelt i namnet
Symptom: en verifiering eller DKIM-kontroll hos en tjänst lyckas inte, trots att posten "finns".
Bevisa: dig +short TXT k2._domainkey.example.com ger inget, men dig +short TXT k2._domainkey.example.com.example.com ger ett resultat.
Orsak: tjänsten anger det fullständiga namnet (k2._domainkey.example.com) och din panel lägger till domänen en gång till.
Lösning: fyll bara i delen före din domän i namnfältet: k2._domainkey. Panelen visar oftast det fullständiga namnet under fältet: kontrollera det.
3. Ändring på fel ställe
Symptom: du ändrar en post, men inget förändras, inte ens efter en dag.
Bevisa: dig +short NS example.com ger namnservrar från en annan leverantör än den du ändrade hos (till exempel en webbplatsbyggare eller Cloudflare).
Orsak: endast leverantören av namnservrarna bestämmer DNS:en (lektion 2.1). Poster på ett annat ställe gör ingenting.
Lösning: ändra posten hos leverantören av namnservrarna, eller sätt tillbaka namnservrarna. Ett verkligt exempel: någon satte namnservrarna till en webbplatsbyggarplattform för webbplatsen, men A-posten för mail fanns inte där. Resultat: det gick att skicka men inte att ta emot, eftersom MX-posten pekade på mail.example.com och det namnet inte längre existerade.
4. Två SPF-poster
Symptom: e-post hamnar oftare i skräpposten eller avvisas, sedan du kopplade in en ny tjänst.
Bevisa: dig +short TXT example.com ger två rader som börjar med v=spf1.
Orsak: den nya tjänsten sa "lägg till denna SPF-post", och det gjordes bokstavligt. Med två SPF-poster blir SPF ogiltig (permerror, RFC 7208), vilket är värre än ingen SPF alls.
Lösning: slå ihop dem till en post: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Tänk på gränsen på tio uppslagningar (lektion 4.3).
5. En CNAME på den nakna domänen
Symptom: panelen vägrar posten, eller efter att du sparat slutar din e-post fungera.
Bevisa: tjänsten ber dig "skapa en CNAME för @".
Orsak: en CNAME får inte finnas bredvid andra poster, och på den nakna domänen finns alltid SOA- och NS-poster (och ofta MX och TXT). Se lektion 3.2.
Lösning: använd på @ A-posten (och eventuellt AAAA) som tjänsten anger, och CNAME endast för www eller en subdomän. Vissa DNS-leverantörer har en ALIAS eller "CNAME flattening" för detta fall.
6. Att glömma AAAA vid en flytt
Symptom: efter en flytt ser en del besökare (ofta mobila) fortfarande den gamla webbplatsen, eller ett certifikatfel.
Bevisa: dig +short A example.com ger den nya adressen, dig +short AAAA example.com ger fortfarande en adress till den gamla servern.
Orsak: enheter med IPv6 föredrar AAAA-posten. Endast A-posten har ändrats.
Lösning: ändra AAAA-posten samtidigt, eller ta bort den om den nya servern inte har IPv6. Ett verkligt exempel: vid koppling av en webbutiksplattform behövde den gamla AAAA-posten tas bort utöver den nya A-posten, annars förblev butiken oåtkomlig för en del av besökarna.
7. En MX som pekar mot ingenting
Symptom: du tar inte emot e-post; avsändare får ett felmeddelande tillbaka.
Bevisa: dig +short MX example.com ger 10 mail.example.com., men dig +short A mail.example.com ger inget (NXDOMAIN).
Orsak: en MX pekar mot ett namn, och det namnet måste ha en A- eller AAAA-post. Ofta har A-posten för mail försvunnit vid en namnserverflytt. En MX får inte heller peka mot en IP-adress eller mot en CNAME (RFC 2181).
Lösning: skapa en A-post för e-postserverns namn, eller låt MX-posten peka mot ett namn som har en adress.
8. E-post på annan plats, men den gamla servern tror att den ska leverera e-posten
Symptom: e-post utifrån kommer fram bra till din nya leverantör, men e-post från din egen webbplats (kontaktformulär, webbutik) kommer aldrig fram. Ibland får du 550 Unknown user.
Bevisa: MX-posten pekar mot den nya leverantören, men på webbservern är lokal e-postleverans fortfarande påslagen.
Orsak: det här är inget DNS-fel, men ser ut som ett. En webbserver som tror att den själv har e-postlådorna tittar inte på MX-posten.
Lösning: stäng av lokal leverans i din hostingpanel (i DirectAdmin: kryssrutan "Använd denna server för att hantera min e-post"). Andra paneler har en liknande inställning, ofta "Remote mail exchanger" eller "extern e-post".
9. Proxy påslagen för e-post
Symptom: hos en DNS-leverantör med proxyfunktion (som det orangea molnet hos Cloudflare) fungerar webbplatsen, men ditt e-postprogram kan inte ansluta, eller så förnyas inte webbplatsens certifikat.
Bevisa: dig +short A mail.example.com ger en adress till proxyn i stället för din e-postserver.
Orsak: en webbproxy vidarebefordrar bara webbtrafik, ingen e-post.
Lösning: stäng av proxyn (grått moln, "DNS only") för mail och alla namn som ditt e-postprogram använder. För certifikat: stäng av proxyn tillfälligt tills certifikatet finns, eller använd rätt SSL-läge hos proxyn.
10. Gammal DS efter en domänöverföring
Symptom: efter en namnserverflytt är din domän oåtkomlig för en del av världen; andra märker ingenting.
Bevisa: dig example.com @1.1.1.1 ger SERVFAIL, dig +cd example.com @1.1.1.1 ger ett svar. DNSViz (https://dnsviz.net/, lektion 8.1) färgar DS-posten röd och ritar under den en grå, prickad nyckel som inte längre finns i din zon. Zonemaster och Verisign DNSSEC Debugger rapporterar samma sak i ord.
Orsak: hos registeransvarig finns fortfarande DS-posten från den gamla leverantören (lektion 8.1). Endast validerande resolvers misslyckas, därför märker inte alla av det.
Lösning: låt uppdatera DS-posten med nyckeln från den nya leverantören, eller ta bort den och aktivera DNSSEC igen efteråt.
Och "felet" som inte är ett fel: cachen
Väldigt ofta är allt korrekt, men du ser fortfarande det gamla svaret. Du känner igen det på: dig @<namnserver> ger det nya svaret, en nätbaserad kontrolltjänst i andra länder också, bara din egen dator inte. Lösning: privat fönster, telefon via 4G/5G, eller att tömma din cache (lektion 8.2). Även en glömd rad i din dators hosts-fil (från ett tidigare test före en flytt) ger denna bild: ta bort den raden.
En besläktad fälla: att fråga efter ett nytt namn innan du har skapat det. Resolvern minns då "finns inte" (negativ cache) och det tar längre tid innan det nya namnet fungerar (lektion 6.2).
I praktiken: så här ser det ut i en panel
Många paneler förhindrar en del av dessa fel. Mitt WebOké varnar till exempel om punkten i slutet saknas och visar under namnfältet det fullständiga namnet; DirectAdmin vägrar poster som inte är giltiga med "Error Writing Records". Cloudflare och andra leverantörer har liknande varningar. Gör en säkerhetskopia eller export av din zon innan större ändringar, så kan du alltid gå tillbaka.
Sammanfattning
- Börja alltid med: vilka namnservrar, och vad säger den auktoritativa namnservern.
- De flesta felen finns i namnet (punkt, dubbelt domännamn) eller på platsen (fel leverantör).
- En SPF-post, ingen CNAME på @, flytta AAAA tillsammans med A, MX mot ett namn med en adress.
- SERVFAIL efter en flytt är oftast en gammal DS-post.
- Om bara du ser det gamla svaret, är det din cache eller hosts-fil.
Quiz
Uppgift
Uppgift Z8.4: Känna igen fel. Du får fem korta fall med utdata från dig (i kursmiljön). Välj för varje fall vilket av de tio felen det handlar om. Därefter en verklig efterforskning: ta reda på med dig eller ett nätbaserat verktyg vilken post som är fel för dnssec-failed.org (status och vad +cd ger), och om wikipedia.org har exakt en SPF-post.
Läs mer
Dessa artiklar beskriver lösningarna i panelerna hos WebOké; hos andra leverantörer heter knapparna annorlunda.
- Webbplatsen eller e-posten fungerar inte efter en flytt eller DNS-ändring: kontrollera din domän
- Hur lång tid tar en ändring av nameserver eller DNS, och vad gör du om du inte ser den?
- DirectAdmin-guide 18.7: Min domän fungerar inte efter en flytt eller ändring
- DirectAdmin-guide 18.9: Jag får inte längre e-post
- DirectAdmin-guide 5.4: CNAME-poster och punkten på slutet
- Det går inte att skicka e-post via PHP, MX-posterna pekar till en annan leverantör
- Använd egna eller externa nameservers (som Cloudflare) för din domän