WHOIS, SSL og DNS: hvad et webbureau bør overvåge på alle kundedomæner

Hvis du driver et webbureau eller arbejder som freelance webudvikler, er der tre tekniske kontroller som dækker langt størstedelen af "uventede nedbrud" på et kundedomæne. De er simple at lave, lette at automatisere, og de fanger problemer 30-90 dage før kunden mærker noget. Her er hvad de gør, hvor de typisk fejler, og hvordan I selv kan teste dem.

1. WHOIS: domænets registreringsudløb

Et domænenavn er en lejeaftale, ikke et købt aktiv. Det udløber, og hvis ingen forny inden, falder det tilbage i markedet. Den dato findes i WHOIS-databasen for det relevante TLD.

Eksempel — manuel kontrol af et .dk-domæne:

whois example.dk | grep -i 'expir'

For andre TLDs hedder feltet "Registry Expiry Date", "Expiration Date", "paid-till" eller noget tredje. Det er det første irritationsmoment: WHOIS-format er ikke standardiseret på tværs af TLDs.

Hvor det fejler:

• Renewal-mails ryger til en mailadresse der ikke længere bliver læst (se vores artikel om hvordan man mister et kundedomæne).
• Auto-renewal er slået fra fordi betalingskortet udløb sidste år.
• Kunden tror at det er jer der fornyer; I tror det er kunden.

Hvad I bør automatisere: dagligt WHOIS-opslag pr. domæne, advarsel ved 90, 30, 7 og 1 dag før udløb. Bemærk at .dk og visse andre TLDs har en grace-periode efter udløb hvor domænet kan reddes, men prisen stiger drastisk, og den periode er ikke en garanti.

2. SSL: certifikatets udløbsdato

TLS-certifikater udløber. Let's Encrypt-certifikater har 90 dages gyldighed; kommercielle certifikater typisk 12 måneder. Automatisk fornyelse (certbot, acme.sh, Cloudflare, hosting-provider) er normen, men automatisk fornyelse fejler stille langt oftere end folk regner med.

Eksempel — manuel kontrol af et certifikats udløb:

echo | openssl s_client -servername example.dk -connect example.dk:443 2>/dev/null \
    | openssl x509 -noout -dates

Output:

notBefore=Apr  3 12:00:00 2026 GMT
notAfter=Jul  2 12:00:00 2026 GMT

notAfter er den eneste sandhed. Den fortæller jer hvornår sitet rent praktisk holder op med at virke.

Hvor det fejler:

• ACME HTTP-01 challenges blokeret af en Apache- eller nginx-konfigurationsændring.
• Rate limit fra CA (typisk 5 fejlede forsøg pr. domæne pr. time = 12 timers cooldown).
• DNS-record ændret så certbot validerer mod den forkerte server.
• Cron-job for renewal forsvandt da serveren blev migreret.

Hvad I bør automatisere: dagligt TLS-opslag pr. FQDN (inklusive subdomæner med separate certifikater), advarsel ved 30, 7 og 1 dag før udløb. SSL-overvågning skal lave en faktisk TLS-forbindelse, ikke kun læse certbots logs — det er det eneste der fanger "renewal sker, men det er gammelt cert der serveres".

3. DNS: ændringer i NS, A, MX og TXT

DNS er det lag flest forskellige mennesker har adgang til. Kunden, en konsulent, jeres tidligere webudvikler, det mailhouse der skulle sætte DKIM op, en cloud-platform der "automatisk konfigurerer" records ved deploy. Det skaber et permanent risikolag.

De fire records I bør have et dagligt snapshot af:

• NS — fortæller om DNS-leverandøren er blevet skiftet. En forkert NS kan parkere et helt domæne på et ukontrolleret DNS-svar.
• A (og AAAA) — fortæller om hjemmesiden peger det rigtige sted hen. Hvis en kunde "lige har migreret" og glemte at sige det, ser I det her.
• MX — fortæller hvor mail leveres til. Ændringer her er ofte forbundet med mail-migrering der ikke gik som planlagt.
• TXT — indeholder SPF, DKIM og DMARC. Lille ændring her kan ødelægge mail-deliverability uden at give synlige fejl.

Eksempel — manuel kontrol af et domænes records:

dig +short NS example.dk
dig +short A example.dk
dig +short MX example.dk
dig +short TXT example.dk
dig +short TXT _dmarc.example.dk

Hvor det fejler:

• SPF-record fjernet ved en kundes hosting-migration. Mail begynder at lande i spam.
• NS-records peger pludselig på en ny DNS-leverandør, og en gammel NS bliver ved med at svare med forældede data.
• MX-prioritet ændret så mail leveres til en deprecated server.

Hvad I bør automatisere: dagligt snapshot af NS, A, MX og TXT (inklusive _dmarc) for hvert kundedomæne. Notifikation når et snapshot adskiller sig fra dagen før. Det betyder ikke at hver ændring er et problem — kunden har måske gjort det med vilje — men I vil aldrig blive overrasket over en ændring der allerede har eksisteret i tre uger.

Sådan kører I det selv

Det er ikke kompliceret at bygge selv. En cron-job på en Linux-server kan dagligt loope over et CSV med kundedomæner, kalde whois, openssl og dig, gemme resultaterne i en lille SQLite eller Postgres, sammenligne med gårsdagens snapshot, og sende en mail når noget er ændret eller nærmer sig udløb.

Det tager en eftermiddag at få op at køre. Det tager to-tre dage om året at vedligeholde. Hvis I har under 30 kundedomæner og en god teknisk fornemmelse, kan det fint være den rigtige løsning.

For større porteføljer, eller hvis I ikke vil bruge tid på selv at fejlsøge når et opslag fejler for en ny .dev eller .io-TLD, er der et SaaS-marked. domainwd er én af mulighederne, der målrettet betjener danske bureauer med EU-hosting og dansk webside. Det er ikke det eneste valg; det er det vi laver.