DNS en SSL: DNS-records, DNSSEC, TLS, certificaten en complete checklist

Voorbeelden:

• een geldig certificaat helpt niet als het A-record naar een oude server verwijst,
• een correct A-record is niet voldoende als AAAA IPv6-verkeer naar een niet-werkende machine leidt,
• de automatische vernieuwing van een certificaat werkt niet als het _acme-challenge-record niet kan worden aangemaakt of port 80 is geblokkeerd,
• DNSSEC kan het vertrouwen in DNS-antwoorden vergroten, maar een onjuist DS-record kan een SERVFAIL voor het hele domein veroorzaken,
• een korte TTL verhelpt geen verkeerde delegatie van naamservers,
• een wildcard-certificaat dekt niet het hoofddomein en ook geen meervoudige subdomeinen als die niet apart zijn ingevoerd.

In 2026 hoort het beheer van certificaten volledig geautomatiseerd te zijn. Vanaf 15 maart 2026 mogen publieke TLS-certificaten van het type Subscriber Certificate maximaal 200 dagen geldig zijn. De limiet daalt naar 100 dagen in maart 2027 en naar 47 dagen in maart 2029. Let’s Encrypt geeft standaard nog steeds certificaten van 90 dagen uit, maar biedt ook kortere profielen, en vanaf mei 2026 geeft het profiel tlsserver certificaten van 45 dagen uit voor gebruikers die daar bewust voor kiezen.

TL;DR: houd minstens twee onafhankelijk bereikbare autoritatieve DNS-servers aan, beheer de A- en AAAA-records, implementeer DNSSEC alleen met een veilig proces voor het beheer van DS, beperk de certificaatautoriteiten met CAA, gebruik TLS 1.3 met TLS 1.2 als compatibel minimum, automatiseer het uitgeven en vernieuwen van certificaten met ACME en monitor de vervaldatum, de certificaatketen, SNI, HSTS en validatiefouten vanuit meerdere locaties.

De informatie en vereisten zijn geverifieerd op 23 juli 2026.

DNS, SSL en TLS in één tabel

Laag	Verantwoordelijk voor	Belangrijkste elementen	Typische storingen
Domeinregistrar	domeineigendom en delegatie	naamservers, transferblokkering, DS	accountovername, verkeerde delegatie, oude DS
Autoritatieve DNS	de echte zone-records	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	verkeerd adres, ontbrekend record, split-brain, verkeerde handtekening
Recursieve resolver	het vinden en cachen van antwoorden	TTL, cache, DNSSEC-validatie, DoH/DoT	oude gegevens in de cache, foutieve validatie
TCP/QUIC en TLS	een veilig kanaal naar de server	TLS 1.2/1.3, SNI, ALPN, certificaat	zwak protocol, verkeerde chain, hostname mismatch
Certificaat	bevestiging van de identiteit van de naam	SAN, issuer, geldigheid, sleutel, handtekening	verloop, ontbrekende naam, verkeerde intermediate
HTTP	doorverwijzing en HTTPS-beleid	301/308, HSTS, beveiligingsheaders	redirect loop, mixed content, ontbrekende HSTS

Hoe werkt domeinresolutie echt?

DNS is een hiërarchisch en gedistribueerd naamsysteem. De resolver ontvangt niet het volledige antwoord van één centrale server. Vereenvoudigd:

1. de browser en het systeem controleren de lokale cache,
2. de recursieve resolver bevraagt de root-servers,
3. de root verwijst naar de servers van het betreffende topleveldomein, bijvoorbeeld .pl,
4. de TLD-server verwijst naar de autoritatieve servers van het domein,
5. de autoritatieve server geeft een record terug, bijvoorbeeld A, AAAA of CNAME,
6. het antwoord wordt bewaard volgens de TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS garandeert niet dat de aangewezen server gezond is en ook niet dat het HTTP-antwoord correct is. Het geeft de gegevens terug die in de zone zijn opgeslagen. DNS-monitoring moet daarom worden gecombineerd met TCP-, TLS- en HTTP-tests.

1. De belangrijkste DNS-records

A en AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A verwijst naar een IPv4-adres,
• AAAA verwijst naar een IPv6-adres.

Het AAAA-record is geen toevoeging zonder gevolgen. Als het bestaat, kunnen clients die IPv6 ondersteunen juist daarmee proberen verbinding te maken. Publiceer geen AAAA zolang de firewall, routing, webserver, het certificaat en de ACME-challenge niet correct werken via IPv6.

Let’s Encrypt geeft bij de http-01-validatie de voorkeur aan IPv6 wanneer het domein een AAAA-record heeft. Verkeerde IPv6 kan leiden tot een mislukte uitgifte of vernieuwing van het certificaat, zelfs wanneer IPv4 correct is.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

CNAME maakt een alias naar een andere DNS-naam. Een naam met een CNAME mag niet tegelijkertijd andere gewone gegevens hebben, zoals A, AAAA of MX, omdat CNAME aangeeft dat de eigenlijke gegevens onder een andere naam staan.

Op de apex van de zone, dus example.com, botst een klassieke CNAME met de verplichte SOA- en NS-records. Providers omzeilen dit met eigen mechanismen zoals ALIAS, ANAME of flattening, maar dat zijn geen gewone CNAME-records die in de zone worden verzonden.

NS en SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS geeft de autoritatieve naamservers aan. De delegatie bij de registrar en de NS-records binnen de zone moeten consistent zijn.

SOA bevat de administratieve gegevens van de zone, waaronder het serienummer en parameters die door secundaire servers worden gebruikt. Bij handmatig beheer van de zone moet het serienummer na wijzigingen toenemen.

Een goede operationele praktijk is minstens twee autoritatieve servers die in gescheiden netwerken of locaties draaien. ICANN raadt meerdere, gescheiden autoritatieve servers aan, bij voorkeur geografisch en topologisch verspreid.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Een lager getal betekent een hogere prioriteit. Het doel van een MX-record moet een hostnaam zijn, geen IP-adres en geen CNAME.

Het wijzigen van de webhosting mag de e-mail niet automatisch veranderen. Noteer vóór de DNS-migratie de MX-, SPF-, DKIM- en DMARC-records.

TXT

TXT is een tekstcontainer die onder meer wordt gebruikt door:

• SPF,
• DKIM,
• DMARC,
• validatie van domeineigendom,
• ACME dns-01,
• SaaS-integraties.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Meerdere TXT-records onder één naam kunnen correct zijn, maar meerdere concurrerende SPF-records die met v=spf1 beginnen, zijn een ontwerpfout.

CAA

Met CAA kan de eigenaar van een domein aangeven welke certificaatautoriteiten certificaten voor het domein mogen uitgeven.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue heeft betrekking op gewone certificaten,
• issuewild heeft betrekking op wildcards,
• iodef geeft het kanaal aan voor het rapporteren van beleidsschendingen.

CAA vervangt niet de beveiliging van het account bij de registrar, DNSSEC of de monitoring van Certificate Transparency. Het is een aanvullende beperking voor publieke CA’s. Het ontbreken van CAA betekent doorgaans dat elke publiek vertrouwde CA een certificaat kan uitgeven na een correcte validatie van het domein.

PTR

PTR realiseert reverse DNS, ofwel het toewijzen van een IP-adres aan een naam. Het record wordt ingesteld door de eigenaar van het IP-bereik, meestal de VPS- of hostingprovider. Het is vooral belangrijk voor mailservers.

192.0.2.10 → mail.example.com

Voor e-mail moet de PTR-naam doorgaans via A of AAAA terugleiden naar hetzelfde adres.

HTTPS en SVCB

De HTTPS- en SVCB-records kunnen de client informatie doorgeven over de manier van verbinden met de dienst, alternatieve endpoints, ondersteunde protocollen en parameters die nodig zijn voordat de verbinding tot stand komt.

Conceptueel voorbeeld:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

Voer ipv4hint of ipv6hint niet in als vervanging voor correcte adresrecords zonder het gedrag van clients te begrijpen. HTTPS RR is een mechanisme voor optimalisatie en signalering, geen oplossing voor onjuiste DNS of TLS.

2. TTL en “DNS-propagatie”

TTL bepaalt hoe lang een resolver een antwoord in de cache mag bewaren. Er bestaat geen enkele globale propagatieklok. Na een wijziging:

• een deel van de resolvers heeft nog het oude antwoord,
• een deel bevraagt de server onmiddellijk,
• negatieve antwoorden, zoals NXDOMAIN, kunnen eveneens worden gecachet,
• het lokale systeem, de browser, de provider en de applicatie kunnen elk een eigen cache hebben.

Redelijke TTL-waarden

Situatie	Typische waarde
stabiel productierecord	3600-86400 s
voorbereiding van een migratie	300-600 s
ACME DNS-01-record	30-300 s, als de provider dit toestaat
NS- of SOA-record	meestal langer
noodomschakeling	een lage TTL helpt pas nadat de eerdere cache is verlopen

Verlaag de TTL vóór de migratie minstens één oude TTL-periode van tevoren. De TTL vijf minuten voor de wijziging verlagen verwijdert niet de antwoorden die de resolver al voor 24 uur heeft opgeslagen.

Verhoog na afronding van de migratie de TTL om het aantal query’s en de afhankelijkheid van tijdelijke problemen met de autoritatieve DNS te beperken.

3. DNSSEC: integriteit van antwoorden, geen versleuteling

DNSSEC voegt authenticatie van de herkomst van DNS-gegevens en bescherming van de integriteit toe met behulp van digitale handtekeningen. Het versleutelt geen query’s en verbergt de domeinnamen niet voor de netwerkprovider of de resolver.

De vertrouwensketen maakt onder meer gebruik van:

• DNSKEY - de publieke sleutels van de zone,
• RRSIG - de handtekeningen van recordsets,
• DS - de sleutelvingerafdruk die in de bovenliggende zone is opgeslagen,
• NSEC of NSEC3 - de cryptografische bevestiging van het niet-bestaan van een naam of type.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

RFC 9364 beschrijft het gebruik van DNSSEC voor de authenticatie van de herkomst van DNS-gegevens als de huidige goede praktijk.

Het grootste risico van DNSSEC

Het meest voorkomende probleem is niet het ontbreken van DNSSEC, maar een onjuiste DNSSEC-keten. Als er bij de registrar een DS-record achterblijft dat naar een oude sleutel verwijst, terwijl de nieuwe DNS-operator de zone met een andere sleutel ondertekent, geven validerende resolvers een SERVFAIL terug.

Een veilige DNSSEC-migratie vereist:

1. controleren wie de zone ondertekent,
2. de methode voor de overdracht of rollover van sleutels vaststellen,
3. het juiste DS in het bovenliggende domein publiceren,
4. de TTL van de DNSKEY- en DS-records afwachten,
5. pas daarna de oude sleutels of de oude zone verwijderen,
6. testen via validerende resolvers.

Schakel DNSSEC niet in als de provider geen duidelijk proces biedt voor het beheer van DS en de rotatie van sleutels.

4. DNSSEC versus DoH en DoT

Deze mechanismen lossen verschillende problemen op:

Mechanisme	Beschermt	Biedt niet
DNSSEC	authenticiteit en integriteit van DNS-gegevens	vertrouwelijkheid van de query
DNS over TLS	versleuteling tussen client en resolver via TLS, meestal port 853	authenticiteit van gegevens zonder DNSSEC-validatie
DNS over HTTPS	versleuteling van DNS in HTTPS	authenticiteit van gegevens zonder DNSSEC
gewone DNS	basale naamresolutie	vertrouwelijkheid en cryptografische integriteit

DNS over TLS wordt beschreven in RFC 7858 en DNS over HTTPS in RFC 8484. Versleuteld transport beschermt de query tegen eenvoudig afluisteren op het traject client-resolver, maar de operator van de resolver ziet de query’s nog steeds, en de verdere resolutie hangt af van zijn beleid.

5. SSL versus TLS: de juiste terminologie

“SSL-certificaat” is nog steeds een gangbare marketingterm, maar moderne sites gebruiken TLS. SSL 2.0 en SSL 3.0 zijn verouderd, en TLS 1.0 en 1.1 zijn formeel ingetrokken door de IETF.

In 2026:

• TLS 1.3 verdient de voorkeur,
• TLS 1.2 blijft het compatibele minimum voor oudere, nog ondersteunde clients,
• TLS 1.0, TLS 1.1, SSLv2 en SSLv3 moeten uitgeschakeld zijn,
• de TLS 1.2-configuratie moet moderne suites met AEAD en forward secrecy gebruiken,
• de server mag geen verouderde algoritmen en sleuteluitwisselingen aanbieden.

RFC 9325 bevat de actuele aanbevelingen voor het veilige gebruik van TLS en heeft het eerdere BCP 195 vervangen.

6. Wat controleert de browser in het certificaat?

Tijdens een TLS-verbinding controleert de client onder meer:

1. of het certificaat binnen de geldigheidsperiode valt,
2. of de hostnaam voorkomt in subjectAltName,
3. of de handtekening via een correcte tussenketen naar een vertrouwde root-CA leidt,
4. of het certificaat niet voor een verkeerd doel wordt gebruikt,
5. of de verbindingsparameters acceptabel zijn,
6. of het beleid van de browser het certificaat niet afwijst.

De identiteit van de server wordt tegenwoordig geverifieerd op basis van de SAN, niet op basis van het veld Common Name als primaire bron van de naam.

SAN

Eén certificaat kan meerdere namen dekken:

example.com
www.example.com
api.example.com

Elke naam moet in de SAN staan.

Wildcard

*.example.com

dekt:

www.example.com
api.example.com
shop.example.com

maar dekt niet automatisch:

example.com
www.eu.example.com

Het hoofddomein moet apart worden toegevoegd, en een wildcard werkt slechts voor één labelniveau.

SNI

Server Name Indication stelt de client in staat de hostnaam tijdens de handshake door te geven, waardoor één IP-adres meerdere certificaten kan bedienen. Een onjuiste SNI-configuratie leidt er vaak toe dat het certificaat van een ander domein wordt weergegeven.

De certificaatketen

De server moet het domeincertificaat en de benodigde tussencertificaten verzenden, maar meestal niet de root. Een ontbrekende intermediate kan werken op één apparaat dat het certificaat eerder heeft opgeslagen en falen op een ander.

7. Geldigheid van certificaten in 2026

Het CA/Browser Forum heeft een schema aangenomen voor het verkorten van publieke TLS-certificaten:

Uitgiftedatum	Maximale geldigheid
vóór 15 maart 2026	398 dagen
15 maart 2026 - 14 maart 2027	200 dagen
15 maart 2027 - 14 maart 2029	100 dagen
vanaf 15 maart 2029	47 dagen

Dit betekent niet dat elke CA een certificaat voor de maximale periode uitgeeft. Let’s Encrypt geeft standaard nog steeds certificaten van 90 dagen uit, heeft optionele certificaten van zes dagen en een tlsserver-profiel met certificaten van 45 dagen dat vanaf mei 2026 beschikbaar is voor vroege implementaties.

De conclusie is eenvoudig: het handmatig vernieuwen van certificaten is geen verstandige operationele praktijk meer.

8. ACME en de automatisering van certificaten

ACME is het standaardprotocol dat de accountregistratie, de validatie van domeincontrole, de uitgifte, vernieuwing en intrekking van een certificaat automatiseert.

HTTP-01

De CA haalt een bestand op:

http://example.com/.well-known/acme-challenge/TOKEN

Voordelen:

• eenvoudige configuratie voor een enkele webserver,
• eenvoudige automatisering,
• vereist geen DNS-API.

Beperkingen:

• vereist een bereikbare port 80,
• geeft geen wildcards uit,
• de challenge moet de juiste server bereiken,
• verkeerde AAAA, proxy, redirect of load balancer kunnen de validatie onderbreken.

Let’s Encrypt raadt aan port 80 open te houden voor publieke webservers en het normale verkeer door te verwijzen naar HTTPS.

DNS-01

De client publiceert een TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Voordelen:

• ondersteunt wildcards,
• werkt zonder publieke HTTP-server,
• is geschikt voor centraal beheer van certificaten.

Risico’s:

• vereist veilige toegang tot de DNS-API,
• propagatie en cache kunnen de validatie vertragen,
• een API-token met bewerkingsrechten voor de hele zone vergroot de gevolgen van een lek,
• oude TXT’s kunnen de diagnose bemoeilijken.

Let’s Encrypt raadt uitdrukkelijk aan DNS-01 te gebruiken met een provider die een API biedt, omdat de automatisering van vernieuwingen cruciaal is. Ken het token het kleinst mogelijke bereik toe: bij voorkeur alleen voor de _acme-challenge-records, niet voor het beheer van het domein, het account of alle zones.

Een wildcard bij Let’s Encrypt vereist DNS-01.

TLS-ALPN-01

De validatie verloopt via een speciale TLS-verbinding op port 443 en het ALPN-protocol. Het is nuttig voor gespecialiseerde proxy’s en certificaatbeheersystemen, maar wordt minder vaak handmatig geconfigureerd.

Renewal Information

Een moderne ACME-client moet ACME Renewal Information, ofwel ARI, ondersteunen. In plaats van elk certificaat volgens één vaste drempel te vernieuwen, kan de client van de CA een voorgesteld vernieuwingsvenster ontvangen. Let’s Encrypt raadt aan de ARI-informatie minstens twee keer per dag te controleren.

9. CAA en ACME: een praktisch voorbeeld

Voor certificaten van Let’s Encrypt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Als je geen wildcard wilt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Vóór de uitgifte is een publieke CA verplicht de CAA te controleren. Vanaf 15 maart 2026 verplichten de vereisten van het CA/Browser Forum ook DNSSEC-validatie voor CAA-gerelateerde query’s die vanuit het primaire netwerkperspectief worden uitgevoerd, en een DNSSEC-validatiefout mag niet worden opgevat als toestemming voor uitgifte.

Vergeet na een wisseling van CA niet de CAA bij te werken voordat je het nieuwe uitgifteproces start.

10. HTTPS, doorverwijzingen en HSTS

Minimaal schema:

http://example.com
        ↓ 301 lub 308
https://example.com

Nadat de volledige werking van HTTPS is bevestigd, kun je toevoegen:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS informeert de browser om in de toekomst alleen HTTPS te gebruiken en het omzeilen van bepaalde certificaatfouten niet toe te staan.

Begin niet met een lange max-age, includeSubDomains en preload als:

• er subdomeinen bestaan zonder HTTPS,
• een deel van de infrastructuur door een partner wordt beheerd,
• het vernieuwingsproces niet is getest,
• er geen monitoring van certificaten is,
• het onduidelijk is of de oude dienst nog nodig zal zijn.

HSTS preload plaatst de regel in de distributie van browsers. Het verwijderen van een vermelding kan weken duren.

11. De meest voorkomende DNS-fouten

Onjuist AAAA-record

IPv4 werkt, maar een deel van de clients kiest niet-werkend IPv6. De symptomen zijn willekeurig, afhankelijk van het netwerk van de gebruiker.

CNAME en andere records onder dezelfde naam

De alias botst met de adresrecords, MX of TXT. Het paneel van de provider kan de wijziging blokkeren of een dubbelzinnige zone genereren.

Inconsistente NS-delegatie

De registrar verwijst naar andere servers dan de zone, of een van de servers heeft een oudere versie van de gegevens.

Oude DS na een DNS-wijziging

Het domein geeft alleen bij DNSSEC-validerende resolvers een SERVFAIL terug.

Permanent te lage TTL

Verhoogt het aantal query’s en de gevoeligheid voor tijdelijke onbereikbaarheid van de DNS, maar zorgt niet automatisch voor snelle failover.

Te hoge TTL vóór een migratie

Oude adressen blijven vele uren in de cache staan.

Achtergebleven TXT-records

Oude verificatietokens en ACME-tokens bemoeilijken de audit en vergroten de operationele chaos.

Gebrek aan consistentie tussen www en apex

example.com en www.example.com verwijzen naar verschillende systemen, hebben andere certificaten of vormen een redirect loop.

12. De meest voorkomende TLS- en certificaatfouten

Certificaat verlopen

Meestal is de oorzaak niet het ontbreken van automatisering, maar een geautomatiseerd proces dat zonder waarschuwing is gestopt.

Certificaat dekt de host niet

Een certificaat voor example.com beveiligt niet automatisch www.example.com.

Onvolledige chain

Er ontbreekt een tussencertificaat. Het probleem kan zich alleen op nieuwe apparaten of bepaalde clients voordoen.

Verkeerd certificaat door SNI

De reverse proxy heeft een verkeerde default virtual host of het nieuwe domein is niet aan de mapping toegevoegd.

Oude protocollen en cipher suites

De server biedt nog steeds TLS 1.0/1.1 of oude suites aan, omdat de configuratie van vele jaren geleden dateert.

Gebrek aan consistentie over meerdere lagen

De CDN heeft een geldig publiek certificaat, maar de verbinding CDN→origin is onversleuteld of verifieert de hostnaam niet.

Vernieuwing uitgevoerd, maar het proces heeft de server niet herladen

Het nieuwe certificaatbestand staat op de schijf, maar Nginx, Apache, HAProxy of de applicatie gebruikt nog steeds het oude certificaat uit het geheugen.

13. Stapsgewijze diagnose

DNS-records

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegatie

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

Een SERVFAIL terwijl het zonder validatie werkt, is een sterk signaal van een DNSSEC-probleem.

Certificaat en SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Certificaatdatums

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP en HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Controleer de redirect, Strict-Transport-Security, de hostnaam, de eindstatus en de afwezigheid van een loop.

Je kunt ook gebruikmaken van de gratis DNS- en SSL-inspector van POLPROG, die de DNS-records en informatie over het TLS-certificaat toont. Vul de test aan met de Inspector voor beveiligingsheaders, de Websitegezondheid en het artikel Basisprincipes van de beveiliging van webapplicaties.

14. Productiemonitoring

Monitor niet alleen de homepage vanuit één locatie. Minimale set:

• het antwoord van de autoritatieve DNS,
• de A-, AAAA-, CNAME-, NS-, MX- en CAA-records,
• DNSSEC-validatie,
• bereikbaarheid via IPv4 en IPv6,
• de certificaatdatums,
• de SAN-overeenstemming,
• de volledige chain,
• TLS 1.2 en TLS 1.3,
• de uiteindelijke redirect HTTP→HTTPS,
• HSTS,
• het antwoord van de origin achter de CDN,
• de werking van ACME en de laatste geslaagde vernieuwing.

Alarmdrempels voor certificaten

Voor een volledig geautomatiseerd systeem:

Resterende tijd	Reactie
30 dagen	waarschuwing of trendcontrole
14 dagen	alarm dat analyse vereist
7 dagen	operationeel incident
3 dagen	kritiek alarm en escalatie
minder dan 24 h	aanstaande storing

De drempels moeten worden afgestemd op de looptijd van het certificaat. Voor certificaten van zes dagen of 45 dagen moet de monitoring veel eerder reageren, in verhouding tot de vernieuwingscyclus.

15. Veilige checklist voor DNS en TLS

Registrar en DNS

• Het account bij de registrar heeft MFA.
• De domeinoverdracht is geblokkeerd.
• De contactgegevens en het herstelproces zijn actueel.
• Er worden minstens twee autoritatieve DNS-servers gebruikt.
• De servers draaien in gescheiden netwerken of locaties.
• De NS-delegatie bij de registrar en in de zone is consistent.
• De A- en AAAA-records verwijzen naar actieve infrastructuur.
• IPv6 wordt daadwerkelijk gemonitord.
• De MX-, SPF-, DKIM- en DMARC-records blijven behouden bij migraties.
• CAA staat alleen de gebruikte CA’s toe.
• Er zijn geen overbodige TXT-records en verificatietokens.
• De TTL is ruim vóór de migratie verlaagd.
• De TTL is na stabilisatie verhoogd.
• De toegang tot de DNS-API heeft minimale rechten.

DNSSEC

• De provider ondersteunt DNSSEC en sleutelrotatie.
• Het DS-record bij de registrar komt overeen met de actieve DNSKEY.
• Wijzigingen van DNS-operator hebben een DNSSEC-migratieplan.
• Oude DS en sleutels worden pas verwijderd nadat de cache is verlopen.
• Het domein wordt getest via een validerende resolver.
• Een alarm detecteert SERVFAIL en het verlopen van handtekeningen.

Certificaten

• De certificaten worden uitgegeven en vernieuwd via ACME.
• De vernieuwing is getest, niet alleen de eerste uitgifte.
• Het proces herlaadt de server na de installatie van een nieuw certificaat.
• Alle hosts komen voor in de SAN.
• Wildcards worden bewust gebruikt.
• De chain bevat de juiste intermediates.
• De private sleutel verlaat het juiste systeem niet.
• De rechten op de sleutel zijn beperkt.
• De alarmen werken onafhankelijk van de ACME-client zelf.
• DNS-01 gebruikt een beperkt API-token.
• HTTP-01 werkt via IPv4 en IPv6.
• Een staging-CA wordt gebruikt voor het testen van de automatisering.

TLS en HTTPS

• TLS 1.3 is ingeschakeld.
• TLS 1.2 blijft alleen voor de benodigde compatibiliteit.
• TLS 1.0, TLS 1.1 en SSL zijn uitgeschakeld.
• De server biedt geen verouderde cipher suites aan.
• SNI geeft voor elke host het juiste certificaat terug.
• HTTP verwijst rechtstreeks door naar HTTPS.
• Er is geen mixed content.
• HSTS is gefaseerd geïmplementeerd.
• includeSubDomains is veilig voor het hele domein.
• Preload is geanalyseerd vóór de aanmelding.
• CDN→origin gebruikt eveneens correct geverifieerd TLS.

Conclusie

Een goede configuratie van DNS en TLS in 2026 berust op vier principes:

1. DNS moet consistent en operationeel bestendig zijn.
2. DNSSEC mag alleen worden geïmplementeerd met correct beheer van DS en sleutels.
3. Certificaten moeten automatisch worden beheerd via ACME.
4. TLS 1.3, een correcte chain, monitoring en HSTS maken deel uit van één proces en zijn geen afzonderlijke taken.

Het grootste risico is niet het ontbreken van een “groen slotje” op de dag van lancering. Het is de stille storing enkele maanden later: een verlopen certificaat, een verouderd AAAA-record, een achtergebleven DS, een DNS-token met te veel rechten of een vernieuwingsproces dat door niemand werd gemonitord.