Sajten eller mejlen strular? Så diagnosticerar du domän, DNS och server själv, steg för steg
Något är fel efter en ändring på sajten. Kanske har du bytt webbhotell och gamla adresser dyker upp, kanske varnar webbläsaren för att anslutningen inte är säker, kanske hamnar mejl i skräpposten istället för hos mottagaren. Symtomen ser olika ut men går ofta att spåra med samma handfull gratisverktyg, direkt i webbläsaren, utan konto. Det här är ordningen jag själv kollar i när något strular efter en ändring. Du behöver inte läsa hela guiden i ett svep, symtomtabellen nedan räcker för att peka dig åt rätt håll.
Vilket symtom har du? Så hittar du rätt verktyg
Innan du gräver i DNS-poster eller certifikatkedjor lönar det sig att slå fast vilket symtom du faktiskt ser. Våra gratis webbverktyg körs direkt i webbläsaren utan registrering, och rätt verktyg beror helt på vad som strular. Tabellen nedan är en snabb ingång, hitta din rad och läs vidare i motsvarande avsnitt.
| Symtom | Verktyg | Vad du letar efter i resultatet |
|---|---|---|
| Sidan visar en gammal version eller fel innehåll efter byte av webbhotell | Redirect-kollaren | Antal hopp, statuskoden för varje hopp, och var kedjan till slut landar |
| www.dinsajt.se fungerar men dinsajt.se gör det inte (eller tvärtom) | Redirect-kollaren | Om det finns en 301 mellan de två adressvarianterna |
| Webbläsaren varnar "Anslutningen är inte privat" eller "Ej säker" | SSL-kollaren | Utfärdare, giltighetstid och om din domän finns med i certifikatets SAN-fält |
| Du vet inte vilket företag som äger eller registrerat domänen | Whois | Registrar, namnservrar, registrerings- och utgångsdatum |
| Du vill se vilket nät eller vilken leverantör en IP-adress hör till | IP-lookup | Nätägare, AS-nummer och PTR-post |
| DNS-posterna verkar peka fel efter ett byte av webbhotell | DNS-lookup | A- och AAAA-poster, NS-poster, och om de matchar det nya hotellets instruktioner |
| Mejl hamnar i mottagarens skräppost | Epost-kollaren | SPF-, DKIM- och DMARC-status |
| Mejl kommer inte fram alls, varken i inkorg eller skräppost | Epost-kollaren | MX-poster och om SPF-uppslagen håller sig under gränsen |
| Ett vidarebefordrat mejl studsar hos slutmottagaren | Epost-kollaren | Samma SPF-status, ofta orsaken bakom just vidarebefordran |
Omdirigeringar och HTTPS, så läser du kedjan
Om sidan visar fel innehåll efter ett byte av webbhotell, eller om en av adressvarianterna (med eller utan www) inte fungerar, är redirect-kollaren rätt startpunkt. Verktyget följer varje omdirigering (eng. redirect) från adressen du anger, ett hopp i taget, och visar statuskoden för varje steg tills sidan till slut svarar med en riktig sida. Testar du till exempel http://wikipedia.org ser du en kedja i tre led, först en 301 som flyttar från http till https, sedan ytterligare en 301 som lägger till www, och till sist ett 200 som säger att sidan faktiskt laddades.
Permanenta vs. tillfälliga hopp
Statuskoden avgör vad hoppet egentligen betyder. En 301 betyder "flyttad permanent", sökmotorer och webbläsare uppdaterar då sin uppfattning om var sidan bor. En 308 gör samma sak fast strängare, metoden i det ursprungliga anropet bevaras. En 302 eller 307 är en tillfällig omdirigering, adressen antas flytta tillbaka senare, vilket är helt normalt att se vid till exempel kampanjsidor eller planerat underhåll. En 303 (See Other) dyker oftast upp efter att ett formulär skickats in. Ser du en 302 där du egentligen förväntar dig en permanent flytt, exempelvis från en gammal till en ny domän efter ett hotellbyte, är det värt att fixa till en 301 istället. Sökmotorer tolkar annars flytten som tillfällig och kan fortsätta visa den gamla adressen i sökresultat.
Ett vanligt missförstånd är att en omdirigering i sig betyder att något är fel eller att sajten är hackad. Så är det nästan aldrig. Både www till icke-www och http till https är regler som styrs av webbserverns konfiguration, inte av DNS, vilket förklarar varför en fungerande DNS-konfiguration mycket väl kan finnas samtidigt som en av adressvarianterna ändå inte laddar rätt. Felet sitter i så fall i webbserverns omdirigeringsregler, inte i namnuppslagningen.
När kedjan aldrig tar slut
Ibland pekar en adress i cirkel, A omdirigerar till B som omdirigerar tillbaka till A. Redirect-kollaren känner igen mönstret och avbryter med meddelandet "Omdirigeringsloop upptäckt" istället för att fortsätta i all oändlighet. Verktyget sätter också ett tak på 15 hopp totalt, en kedja som är längre än så är i praktiken trasig oavsett om den formellt är en loop eller inte. Testar du en adress som pekar mot ett privat eller internt nätverk svarar verktyget istället "Blockerad (privat eller intern adress)", av samma säkerhetsskäl som gör att ett verktyg i vår serverdrift aldrig ska kunna nå interna resurser.
Certifikat och varningen "Ej säker"
En varning om att anslutningen inte är säker beror nästan alltid på en av fyra saker, och ssl-kollaren visar vilken. Verktyget hämtar certifikatet för domänen du anger och redovisar utfärdare, giltighetstid och hela kedjan av certifikat fram till en betrodd rot.
Den vanligaste orsaken är att certifikatet helt enkelt har gått ut, ssl-kollaren visar giltig från- och tilldatum plus en markering som växlar färg beroende på hur nära utgångsdatumet ligger. Näst vanligast är en ofullständig kedja, servern skickar bara sitt eget certifikat men glömmer mellanledet upp till roten, vilket gör att vissa webbläsare litar på det medan andra inte gör det. Den tredje orsaken är att certifikatet gäller fel domän, och här är fältet SAN (eng. Subject Alternative Name) den egentliga diagnosen. Ett certifikat kan se giltigt ut, men om domänen du besöker inte finns listad i SAN-fältet varnar webbläsaren ändå. Provar du med webguide.se ser du att certifikatet är utfärdat av Let's Encrypt och att SAN täcker både *.webguide.se och webguide.se, precis den bredd som krävs för att både huvuddomänen och alla subdomäner ska räknas som giltiga. Den fjärde och enklaste orsaken är att https inte är konfigurerat alls, då finns helt enkelt inget certifikat att hämta.
Ssl-kollaren listar även sex vanliga säkerhetsrelaterade HTTP-huvuden (eng. security headers), bland annat HSTS och CSP, och länkar vidare till hur du härdar en VPS om de saknas, ett naturligt nästa steg om du driver egen server. Det finns också en DNS-post som heter CAA (eng. Certification Authority Authorization) och som begränsar vilka certifikatutfärdare som får utfärda certifikat för din domän. Du stöter sällan på den i vardagen, men den är värd att känna till om du läser om vilka DNS-poster som är värda att hålla koll på.
Ett giltigt certifikat intygar bara att anslutningen är krypterad, inte att innehållet på sidan är tryggt eller korrekt. Certifikatet är heller inte kopplat till webbhotellet i sig, det gäller domänen, oavsett vilken server den för tillfället pekar mot. Chrome förklarar varningen på ungefär samma sätt.
Vem äger domänen, och vem driver servern den pekar mot?
Domänägande och serverdrift är två olika saker, och de är lätta att blanda ihop. En domän kan vara registrerad hos ett företag samtidigt som den pekar mot servrar hos ett helt annat. Två verktyg svarar på var sin del av frågan.
Whois, vem som registrerat domänen
Whois-verktyget slår upp domänens registreringsuppgifter, registrar, namnservrar (eng. nameservers), samt registrerings- och utgångsdatum. Slår du upp en domän, exempelvis wikipedia.org, ser du registraren (här MarkMonitor), vilka namnservrar domänen använder och när den registrerades respektive löper ut.
Här finns en svensk egenhet värd att känna till. Toppdomänerna .se och .nu saknar ett publikt RDAP-gränssnitt (den nyare, strukturerade efterföljaren till protokollet WHOIS), och den klassiska uppslagningen via port 43 är blockerad i vår serverdrift, av samma säkerhetsskäl som håller övriga verktyg borta från interna adresser. För dessa två toppdomäner hänvisar whois-verktyget därför vidare till Internetstiftelsens egen WHOIS-tjänst, som är den instans som faktiskt sköter registret för svenska domäner. Testar du en svensk domän som vår egen webguide.se är det alltså den hänvisningen du får, inte en tabell. För övriga toppdomäner går uppslaget via det ordinarie WHOIS/RDAP-systemet, som i sin tur utgår från IANA:s RDAP-tjänst.
Innehavaren som står i whois-uppgifterna är inte alltid samma företag som driver webbhotellet, många låter domänen ligga kvar hos en registrar samtidigt som själva sajten flyttar mellan olika hotell över åren. Och har ett utgångsdatum passerat utan att domänen förnyats hamnar den normalt i en kort återköpsperiod (eng. redemption period) innan den blir tillgänglig för andra att registrera, en extra marginal på några dagar som räddat många som glömt en förnyelse.
IP-lookup, vem som driver servern
Medan whois svarar på vem som äger domänen svarar ip-lookup på vem som driver nätet en IP-adress hör till. Anger du adressen 8.8.8.8 ser du att den tillhör Google LLC, med AS-nummer (eng. Autonomous System) AS15169, en PTR-post (omvänd DNS, eng. reverse DNS) som pekar mot dns.google, och att adressen ligger i nätblocket 8.8.8.0/24 registrerat hos regionregistret ARIN.
Som verktyget själv uttrycker det pekar en IP-adress på ett nät och ett datacenter, inte på en enskild person. Det är också helt normalt att flera domäner delar samma IP-adress, delad hosting (eng. shared hosting) fungerar precis så, och en tom PTR-post är i sig inget fel, långt ifrån alla servrar har en konfigurerad omvänd DNS-post. Har du hittat ett nät du vill undersöka vidare går det ofta att korsreferera, en PTR-post pekar i sin tur mot ett domännamn som går att slå upp i whois-verktyget för att se vem som registrerat det.
DNS-lookup, jämför mot hotellets instruktioner
Dns-lookup visar samtliga publika DNS-poster för en domän i en tabell, typ, värde och TTL (eng. Time To Live, hur länge posten cachas). Kör du webguide.se genom verktyget ser du A- och AAAA-poster, fyra MX-poster, tre NS-poster, samt TXT-poster för både SPF och en verifieringspost från Google, tillsammans med en SOA-post.
Nyttan ligger i jämförelsen. Ta resultatet och lägg det bredvid det nya hotellets instruktioner för A-post och namnservrar, avvikelser där är oftast hela förklaringen till att sajten visar fel innehåll efter ett byte. Läs gärna vilka DNS-poster du måste tänka på vid ett byte om du står mitt i ett hotellbyte just nu. Alla DNS-resolvrar i världen har inte nödvändigtvis hunnit se en ändring samtidigt, så ett resultat direkt efter en uppdatering kan skilja sig något från vad andra ser precis då.
E-postautentisering, en snabb koll
Epost-kollaren samlar SPF, DKIM och DMARC för en domän i en enda vy. Kontrollerar du webguide.se ser du SPF med sina uppslag, DMARC-policyn, DKIM-selektorn "default" och samtliga MX-poster.
Verktyget har en egen "Så tolkar du resultatet"-guide direkt på sidan, så vi upprepar den inte här. Några vanliga vägar vidare beroende på vad du ser, saknas SPF eller DKIM helt är varför WordPress-mejl hamnar i spam en bra utgångspunkt. Är DMARC svag eller saknas helt är Outlooks nya DMARC-krav relevant läsning, kraven har sin grund i standarden RFC 7489. Ligger SPF nära eller över gränsen på tio uppslag förklarar SPF med för många uppslag varför. Och studsar specifikt vidarebefordrad post finns svaret i varför vidarebefordrad e-post inte alltid kommer fram.
Om du fortfarande sitter fast
Visar alla verktygen rena resultat men problemet kvarstår ändå, sitter felet sannolikt på servernivå snarare än i domän eller DNS. Driver du egen VPS är felsökning av en seg eller nedlagd VPS nästa steg. Sitter du på delad hosting är det istället dags att kontakta supporten, med skärmdumparna från verktygen ovan som konkret underlag för felsökningen.