Många svenska företag tror att de har ett domänregister när de i själva verket har flera listor: ekonomiavdelningens förnyelser, marknadens kampanjnamn, IT:s DNS-zoner och en byrås gamla kalkylblad. När en person slutar, ett projekt läggs ned eller ett kreditkort byts kan ett viktigt namn falla mellan stolarna. En domänportfölj behöver därför beskriva både vilka namn organisationen kontrollerar och vilka tjänster, avtal och ansvar som hänger ihop med varje namn.
Målet med bevakning är inte att skapa flest möjliga notifieringar. Målet är att upptäcka en förändring i tid för att kunna fatta rätt beslut. Ett förfallodatum kräver en annan åtgärd än ett oväntat namnserverbyte. Ett nytt certifikat kan vara normalt efter en migrering, medan en okänd subdomän kan behöva en snabb säkerhetsutredning. Börja därför med riskklasser och åtgärdsägare innan du väljer larmnivå.
Bygg ett portföljregister som går att använda
För varje domän bör registret innehålla exakt namn, toppdomän, registrar eller återförsäljare, kontoägare, förfallodatum, automatisk förnyelse, betalningsansvarig, namnservrar, DNS-operatör, affärsägare och kritikalitet. Lägg till användning: webb, e-post, API, omdirigering, kampanj, skydd mot förväxling eller passivt innehav. Dokumentera också om domänen omfattas av ett varumärke, avtal eller pågående tvist.
- Kritisk produktion: kundinloggning, betalning, e-post eller API.
- Viktig kommunikation: huvudwebb, support, press och transaktionsflöden.
- Skyddad portfölj: stavningsvarianter och namn som hindrar förväxling.
- Projekt: kampanj- och lanseringsdomäner med slutdatum.
- Avveckling: namn som ska förnyas tills omdirigering och historik är hanterade.
- Okänd: hittad domän utan fastställd ägare eller användning.
Importera inte en gammal lista som om den vore sann. Matcha den mot registraruppgifter, DNS, webb- och e-postobservationer och de personer som faktiskt äger tjänsterna. En domän utan DNS kan fortfarande vara viktig för varumärkesskydd eller framtida lansering. En domän som pekar mot en aktiv tjänst kan däremot vara bortglömd. Markera osäkerhet och ge varje rad en nästa utredningspunkt i stället för att gissa.
Lägg förfallodatum först i kalendern
Förnyelse är mer än en betalning. Kontrollera förfallodatum, förnyelseperiod, kontaktväg, betalningsmetod och vem som kan återställa ett misslyckat försök. Sätt påminnelser i flera nivåer, exempelvis 90, 30 och 7 dagar, men koppla varje påminnelse till en person eller grupp. Kontrollera även om registrarens datum visas i en annan tidszon eller påverkas av en pågående transfer. En påminnelse utan mandat gör inget när ett konto redan är låst.
För kritiska namn ska automatisk förnyelse vara en riskbedömning, inte en universallösning. Automatisk betalning minskar risken att någon glömmer datumet, men kräver fungerande kort, godkänd inköpsprocess och åtkomst till kontot. För projekt- och kampanjdomäner kan automatisk förnyelse i flera år skapa kostnad och en glömd tillgång. Skriv därför ett avvecklingsdatum och ansvarig även när automatisk förnyelse är påslagen.
Bevaka DNS och delegation
En ändring av NS-poster kan flytta kontrollen över hela zonen. Följ därför namnservrar, SOA, A, AAAA, CNAME, MX och kritiska TXT-poster för prioriterade namn. Förändringen i sig är inte ett bevis på intrång. En planerad migrering, DNSSEC-rotation eller ny e-posttjänst skapar legitim förändring. Larmet ska visa vad som ändrades, när det observerades och vilken baslinje som användes så att ägaren kan bekräfta eller utreda.
Använd historik som stöd, inte som absolut sanning. Observationsluckor kan bero på att en källa inte såg en kortlivad post. Dokumentera när en baslinje skapades och vilka poster som var avsiktliga. Vid en incident kan jämförelsen mellan senaste godkända konfiguration och den aktuella ge en snabbare startpunkt än en allmän fråga om vad som borde finnas.
Följ certifikat och webbadresser
TLS-certifikat och omdirigeringar bör kopplas till domänens tjänsteägare. Ett certifikat som snart löper ut kan innebära driftstopp, medan ett nytt certifikat kan vara del av en normal förnyelse. Kontrollera namn, giltighet, kedja, hostnames och om både www, apex och relevanta subdomäner svarar som planerat. Lägg inte ett larm på varje förändring utan att ange om den berör en kritisk tjänst.
När en webbplats stängs ska omdirigering, certifikat och DNS behandlas tillsammans. En gammal domän som fortsätter att peka mot en glömd server kan ge både säkerhets- och varumärkesrisk. En omdirigering till fel kampanj eller fel språk kan också skada kunder utan att något tekniskt larm blir rött. Dokumentera mål-URL, avvecklingsdatum och vem som godkänt fortsatt användning.
Prioritera larm som går att agera på
Ett bra larm innehåller domän, förändring, tidigare värde, nytt värde, observationstid, kritikalitet, bevislänk och föreslagen ägare. Sätt hög prioritet på oväntade registrar- eller namnserverändringar, förlorad kritisk DNS-post, certifikatproblem och domäner nära förfallodatum. Sätt lägre prioritet på normalt roterande certifikat eller en planerad TTL-förändring. När ett larm stängs ska orsaken dokumenteras, inte bara markeras som läst.
- Bekräfta om ändringen finns i en godkänd förändring.
- Kontakta rätt ägare med exakta observationer och tidsstämpel.
- Säkra registrar- och DNS-konton om ändringen är okänd.
- Kontrollera webb, e-post, API och certifikat som kan påverkas.
- Återställ eller behåll ändringen enligt incident- eller ändringsplan.
- Skriv rotorsak, beslut och förebyggande åtgärd i portföljregistret.
Integrera bevakning med svenska arbetsflöden
Koppla larm till de system där teamen redan arbetar, men behåll domänens ansvar och bevis synligt. Ett larm till marknad kan räcka för en kampanjdomän, medan huvuddomänens NS-byte bör nå drift och säkerhet. Om ni använder extern byrå ska avtalet ange vem som får ändra DNS, hur incidenter eskaleras och hur åtkomst avslutas. Bevakning ersätter inte en bra behörighetsmodell, men visar när modellen inte längre stämmer med verkligheten.
Gör en kvartalsvis portföljgenomgång med representanter från IT, säkerhet, marknad, juridik och ekonomi. Fråga vilka domäner som tillkommit, vilka som ska avvecklas, vilka som saknar ägare och vilka som stöder kritiska tjänster. Jämför listan med nya certifikat, DNS-observationer och förnyelser. Den gemensamma genomgången gör att en domän inte blir kvar som en teknisk detalj som ingen verksamhetsägare känner igen.
Undvik två motsatta misstag
Det första misstaget är att bevaka för lite. Då upptäcks inte ett förfallodatum eller en oväntad delegation förrän kunderna märker det. Det andra är att bevaka allt med samma känslighet. Då får teamet så många normala notifieringar att de missar det allvarliga. Segmentera efter kritikalitet, definiera planerade ändringsfönster och mät hur många larm som bekräftas inom måltid. Om ett larm saknar ägare är det ett designfel i processen.
Mät resultatet
Följ hur stor del av portföljen som har verifierad ägare, dokumenterat förfallodatum, aktuell DNS-baslinje och ansvarig förnyelse. Mät också medianen för att stänga ett larm, antal okända domäner, förnyelser som krävt manuell räddning och kritiska förändringar som upptäcktes innan användarna påverkades. Siffrorna ska hjälpa prioritering, inte skapa en falsk bild av fullständig säkerhet.
En svensk domänportfölj blir hanterbar när varje rad leder till ett beslut: förnya, bevaka, ändra, utreda eller avveckla. Samla registreringsdata, DNS, TLS, varumärke och tjänsteägare i samma arbetsflöde. Sätt begripliga larm och repetera kontrollen efter större förändringar. Då blir domänförvaltning en del av den ordinarie styrningen i stället för en akut uppgift när ett namn plötsligt slutar fungera.
Avsluta varje portföljöversyn med tre konkreta åtgärder och ett datum. Till exempel kan ni tilldela ägare till två okända namn, flytta en kritisk domän till ett gemensamt konto och avveckla en gammal kampanjadress efter kontroll av länkar. Små, spårbara beslut ger bättre effekt än en lång lista som ingen återkommer till.
Knyt domän till konto och återställning
En portföljpost ska visa vilket registrar- eller återförsäljarkonto som kontrollerar domänen, men inte innehålla lösenord eller hemliga återställningskoder. Dokumentera kontoägare, administratörer, multifaktor, backupkontakt och senaste åtkomstgranskning. Om en byrå har administrativ åtkomst ska avtalet ange hur den avslutas. En domän som har rätt namn men ligger i en före detta medarbetares privata konto är fortfarande en styrningsrisk.
När organisationen förvärvar ett bolag ska domäninventering ingå i överlämningen tillsammans med DNS och TLS. Be om export av namn, förfallodatum, avtal, kontaktroller och aktiva subdomäner. Kontrollera själv de viktigaste namnen efter överlåtelsen. En lista från säljaren kan vara ofullständig, särskilt om marknadsbyråer eller lokala team registrerat extra namn utan central dokumentation.
Bygg ett larm som berättar vad som hänt
Ett larm om ändrad DNS bör visa gammalt och nytt värde, inte bara skriva förändring upptäckt. För certifikat ska det framgå vilket namn, vilken giltighet och vilken kedja som ändrats. För förfallodatum ska larmet ange registrerad tidpunkt och vilken åtgärd som saknas. Lägg till en länk till godkänt ändringsärende där det finns. När beviset är tydligt går triage snabbare och färre normala migreringar eskaleras som incidenter.
Sätt en service-nivå för kritiska larm och en längre tidsgräns för informationslarm. Testa eskaleringen genom att låta en planerad ändring skapa ett larm och be en annan person stänga det. Om ingen vet vem som ska svara har ni hittat en viktig brist innan en verklig ändring sker. Dokumentera resultatet och uppdatera kontaktvägar när team eller leverantör byts.
Skydda även själva bevakningsdatan. Begränsa vem som ser privata kontaktuppgifter, känsliga subdomäner och tekniska detaljer som inte behövs för marknadens uppföljning. Använd sammanfattningar i breda kanaler och detaljerade bevis i begränsade ärenden. En domänportfölj är en karta över organisationen och ska behandlas därefter.
Lägg in en kontroll efter förändringar i bolagsstruktur, namnbyte och leverantörsbyte. Det är ofta då gamla registrar-konton, dubbla domäner och bortglömda kampanjnamn blir synliga. Be den nya ansvariga personen bekräfta både aktiva och avvecklade namn. En portfölj som uppdateras vid rätt händelser behöver inte förlita sig på en enda stor årlig inventering.
Dokumentera också varför ett larm inte ledde till ändring. En bekräftad planerad certifikatförnyelse ska kunna skiljas från ett larm som stängdes för att ingen hann undersöka det. Denna skillnad gör månadsrapporten mer ärlig och visar om organisationen faktiskt har kapacitet att agera. Om samma larm återkommer utan ägare är problemet sannolikt process eller behörighet, inte bara notifiering.
Låt portföljägaren varje månad kontrollera ett litet urval mot verkliga tjänster. Bekräfta att ägare, förfallodatum, DNS-baslinje och certifikatsansvar fortfarande stämmer. Stickprovet gör att registret inte långsamt glider bort från produktionen mellan de större kvartalsmötena. Om en rad inte kan verifieras får den ett nytt ärende och en tidsgräns, inte ett tyst grönt resultat.