DNS et SSL : enregistrements DNS, DNSSEC, TLS, certificats et checklist complète

Exemples :

• un certificat valide ne sert à rien si l'enregistrement A pointe vers un ancien serveur,
• un enregistrement A correct ne suffit pas si AAAA dirige le trafic IPv6 vers une machine hors service,
• le renouvellement automatique du certificat ne fonctionnera pas si l'enregistrement _acme-challenge ne peut pas être créé ou si le port 80 est bloqué,
• DNSSEC peut accroître la confiance dans les réponses DNS, mais un enregistrement DS erroné peut provoquer un SERVFAIL pour tout le domaine,
• un TTL court ne corrigera pas une mauvaise délégation des serveurs de noms,
• un certificat wildcard ne couvre ni le domaine principal ni les sous-domaines à plusieurs niveaux s'ils n'ont pas été saisis séparément.

En 2026, la gestion des certificats devrait être entièrement automatique. À partir du 15 mars 2026, les certificats TLS publics de type Subscriber Certificate peuvent avoir une validité maximale de 200 jours. Cette limite passera à 100 jours en mars 2027 et à 47 jours en mars 2029. Let's Encrypt continue d'émettre par défaut des certificats de 90 jours, mais propose également des profils plus courts, et depuis mai 2026 le profil tlsserver émet des certificats de 45 jours pour les utilisateurs qui le choisissent en connaissance de cause.

TL;DR : maintenez au moins deux serveurs DNS faisant autorité accessibles de façon indépendante, contrôlez les enregistrements A et AAAA, déployez DNSSEC uniquement avec un processus sûr de gestion des DS, limitez les autorités de certification via CAA, utilisez TLS 1.3 avec TLS 1.2 comme minimum compatible, automatisez l'émission et le renouvellement des certificats via ACME et surveillez la date d'expiration, la chaîne de certificats, SNI, HSTS et les erreurs de validation depuis plusieurs emplacements.

Les informations et exigences ont été vérifiées le 23 juillet 2026.

DNS, SSL et TLS en un seul tableau

Couche	Responsable de	Éléments les plus importants	Pannes typiques
Bureau d'enregistrement du domaine	propriété du domaine et délégation	serveurs de noms, verrouillage du transfert, DS	compromission du compte, mauvaise délégation, ancien DS
DNS faisant autorité	véritables enregistrements de la zone	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	mauvaise adresse, enregistrement manquant, split-brain, signature erronée
Resolver récursif	recherche et mise en cache des réponses	TTL, cache, validation DNSSEC, DoH/DoT	données obsolètes en cache, validation erronée
TCP/QUIC et TLS	canal sécurisé vers le serveur	TLS 1.2/1.3, SNI, ALPN, certificat	protocole faible, chaîne erronée, hostname mismatch
Certificat	confirmation de l'identité du nom	SAN, émetteur, validité, clé, signature	expiration, nom manquant, mauvais intermédiaire
HTTP	redirection et politique HTTPS	301/308, HSTS, en-têtes de sécurité	boucle de redirection, mixed content, absence de HSTS

Comment fonctionne réellement la résolution d'un domaine ?

Le DNS est un système de noms hiérarchique et distribué. Le resolver ne reçoit pas la réponse complète d'un unique serveur central. En simplifiant :

1. le navigateur et le système consultent le cache local,
2. le resolver récursif interroge les serveurs root,
3. les serveurs root indiquent les serveurs du domaine de premier niveau approprié, par exemple .pl,
4. le serveur TLD indique les serveurs faisant autorité du domaine,
5. le serveur faisant autorité renvoie l'enregistrement, par exemple A, AAAA ou CNAME,
6. la réponse est conservée selon le TTL.

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

Le DNS ne garantit pas que le serveur indiqué est sain ni que la réponse HTTP sera correcte. Il renvoie les données enregistrées dans la zone. La surveillance du DNS doit donc être associée à des tests TCP, TLS et HTTP.

1. Les enregistrements DNS les plus importants

A et AAAA

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

• A pointe vers une adresse IPv4,
• AAAA pointe vers une adresse IPv6.

L'enregistrement AAAA n'est pas un ajout sans conséquence. S'il existe, les clients prenant en charge IPv6 peuvent tenter de s'y connecter en priorité. Ne publiez pas d'enregistrement AAAA tant que le pare-feu, le routage, le serveur web, le certificat et le challenge ACME ne fonctionnent pas correctement en IPv6.

Lors de la validation http-01, Let's Encrypt privilégie IPv6 lorsque le domaine possède un enregistrement AAAA. Un IPv6 erroné peut entraîner l'échec de l'émission ou du renouvellement du certificat même lorsque l'IPv4 est correct.

CNAME

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

CNAME crée un alias vers un autre nom DNS. Un nom possédant un CNAME ne devrait pas avoir en même temps d'autres données ordinaires telles que A, AAAA ou MX, car CNAME indique que les données réelles se trouvent sous un autre nom.

À l'apex de la zone, c'est-à-dire example.com, un CNAME classique entre en conflit avec les enregistrements obligatoires SOA et NS. Les fournisseurs contournent cela au moyen de leurs propres mécanismes ALIAS, ANAME ou flattening, mais il ne s'agit pas d'enregistrements CNAME ordinaires transmis dans la zone.

NS et SOA

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

NS définit les serveurs de noms faisant autorité. La délégation chez le bureau d'enregistrement et les enregistrements NS à l'intérieur de la zone doivent être cohérents.

SOA contient les données administratives de la zone, notamment le numéro de série et les paramètres utilisés par les serveurs secondaires. Lors d'une maintenance manuelle de la zone, le numéro de série doit augmenter après chaque modification.

Une bonne pratique opérationnelle consiste à disposer d'au moins deux serveurs faisant autorité fonctionnant dans des réseaux ou des emplacements distincts. L'ICANN recommande plusieurs serveurs faisant autorité distincts, de préférence répartis géographiquement et topologiquement.

MX

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

Un nombre plus faible signifie une priorité plus élevée. La cible d'un enregistrement MX doit être un nom d'hôte, et non une adresse IP ni un CNAME.

Un changement d'hébergement web ne devrait pas modifier automatiquement la messagerie. Avant une migration DNS, notez les enregistrements MX, SPF, DKIM et DMARC.

TXT

TXT est un conteneur textuel utilisé notamment par :

• SPF,
• DKIM,
• DMARC,
• la validation de la propriété du domaine,
• ACME dns-01,
• les intégrations SaaS.

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

Plusieurs enregistrements TXT sous un même nom peuvent être valides, mais plusieurs enregistrements SPF concurrents commençant par v=spf1 constituent une erreur de conception.

CAA

CAA permet au propriétaire du domaine d'indiquer quelles autorités de certification peuvent émettre des certificats pour le domaine.

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 concerne les certificats ordinaires,
• issuewild concerne les certificats wildcard,
• iodef indique le canal de signalement des violations de la politique.

CAA ne remplace pas le contrôle du compte chez le bureau d'enregistrement, DNSSEC ni la surveillance de la Certificate Transparency. Il s'agit d'une restriction supplémentaire pour les CA publiques. L'absence de CAA signifie généralement que toute CA publiquement reconnue peut émettre un certificat après une validation correcte du domaine.

PTR

PTR réalise le reverse DNS, c'est-à-dire la correspondance d'une adresse IP vers un nom. Cet enregistrement est défini par le propriétaire de la plage d'adresses IP, généralement le fournisseur de VPS ou d'hébergement. Il est particulièrement important pour les serveurs de messagerie.

192.0.2.10 → mail.example.com

Pour la messagerie, le nom PTR devrait généralement ramener, via A ou AAAA, à la même adresse.

HTTPS et SVCB

Les enregistrements HTTPS et SVCB peuvent transmettre au client des informations sur la manière de se connecter au service, les endpoints alternatifs, les protocoles pris en charge ainsi que les paramètres nécessaires avant l'établissement de la connexion.

Exemple conceptuel :

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

Il ne faut pas saisir ipv4hint ou ipv6hint en remplacement d'enregistrements d'adresse corrects sans comprendre le comportement des clients. L'enregistrement HTTPS RR est un mécanisme d'optimisation et de signalisation, et non une correction d'un DNS ou d'un TLS erroné.

2. Le TTL et la « propagation DNS »

Le TTL détermine combien de temps un resolver peut conserver une réponse en cache. Il n'existe pas d'horloge de propagation globale unique. Après une modification :

• une partie des resolvers dispose encore de l'ancienne réponse,
• une autre partie interroge le serveur immédiatement,
• les réponses négatives, telles que NXDOMAIN, peuvent également être mises en cache,
• le système local, le navigateur, l'opérateur et l'application peuvent avoir des caches distincts.

Valeurs de TTL raisonnables

Situation	Valeur typique
enregistrement de production stable	3600-86400 s
préparation d'une migration	300-600 s
enregistrement ACME DNS-01	30-300 s, si le fournisseur le permet
enregistrement NS ou SOA	généralement plus long
basculement d'urgence	un TTL bas n'aide qu'après l'expiration du cache précédent

Avant une migration, réduisez le TTL au moins un ancien intervalle de TTL à l'avance. Abaisser le TTL cinq minutes avant le changement ne supprime pas les réponses que le resolver a déjà enregistrées pour 24 heures.

Une fois la migration terminée, augmentez le TTL afin de réduire le nombre de requêtes et la dépendance aux problèmes temporaires du DNS faisant autorité.

3. DNSSEC : l'intégrité des réponses, pas le chiffrement

DNSSEC ajoute une authentification de l'origine des données DNS et une protection de l'intégrité au moyen de signatures numériques. Il ne chiffre pas les requêtes et ne masque pas les noms de domaine au fournisseur réseau ni au resolver.

La chaîne de confiance utilise notamment :

• DNSKEY - les clés publiques de la zone,
• RRSIG - les signatures des ensembles d'enregistrements,
• DS - l'empreinte de la clé enregistrée dans la zone parente,
• NSEC ou NSEC3 - la confirmation cryptographique de l'inexistence d'un nom ou d'un type.

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

La RFC 9364 définit l'utilisation de DNSSEC pour l'authentification de l'origine des données DNS comme une bonne pratique actuelle.

Le principal risque de DNSSEC

Le problème le plus fréquent n'est pas l'absence de DNSSEC, mais une chaîne DNSSEC erronée. Si un enregistrement DS pointant vers une ancienne clé subsiste chez le bureau d'enregistrement alors que le nouvel opérateur DNS signe la zone avec une autre clé, les resolvers validants renverront un SERVFAIL.

Une migration DNSSEC sûre nécessite :

1. de vérifier qui signe la zone,
2. de déterminer la méthode de transfert ou de rollover des clés,
3. de publier le DS correct dans le domaine parent,
4. d'attendre le TTL des enregistrements DNSKEY et DS,
5. de ne supprimer qu'ensuite les anciennes clés ou l'ancienne zone,
6. de tester au moyen de resolvers validants.

N'activez pas DNSSEC si le fournisseur ne garantit pas un processus clair de gestion des DS et de rotation des clés.

4. DNSSEC face à DoH et DoT

Ces mécanismes résolvent des problèmes différents :

Mécanisme	Protège	N'assure pas
DNSSEC	l'authenticité et l'intégrité des données DNS	la confidentialité de la requête
DNS over TLS	le chiffrement entre le client et le resolver via TLS, généralement le port 853	l'authenticité des données sans validation DNSSEC
DNS over HTTPS	le chiffrement du DNS dans HTTPS	l'authenticité des données sans DNSSEC
DNS ordinaire	la résolution de noms de base	la confidentialité et l'intégrité cryptographique

DNS over TLS est décrit par la RFC 7858, et DNS over HTTPS par la RFC 8484. Le transport chiffré protège la requête contre une écoute simple sur le segment client-resolver, mais l'opérateur du resolver voit toujours les requêtes, et la suite de la résolution dépend de sa politique.

5. SSL et TLS : la terminologie correcte

« Certificat SSL » reste une expression marketing courante, mais les sites modernes utilisent TLS. SSL 2.0 et SSL 3.0 sont obsolètes, et TLS 1.0 et 1.1 ont été formellement retirés par l'IETF.

En 2026 :

• TLS 1.3 doit être privilégié,
• TLS 1.2 reste le minimum compatible pour les clients plus anciens encore pris en charge,
• TLS 1.0, TLS 1.1, SSLv2 et SSLv3 doivent être désactivés,
• la configuration TLS 1.2 doit utiliser des suites modernes avec AEAD et forward secrecy,
• le serveur ne doit pas proposer d'algorithmes ni d'échanges de clés obsolètes.

La RFC 9325 contient les recommandations actuelles pour une utilisation sécurisée de TLS et a remplacé le BCP 195 précédent.

6. Que vérifie le navigateur dans un certificat ?

Lors d'une connexion TLS, le client vérifie notamment :

1. si le certificat est dans sa période de validité,
2. si le nom d'hôte figure dans subjectAltName,
3. si la signature mène, via une chaîne intermédiaire correcte, à une root CA de confiance,
4. si le certificat n'est pas utilisé à des fins inappropriées,
5. si les paramètres de la connexion sont acceptables,
6. si les politiques du navigateur ne rejettent pas le certificat.

L'identité du serveur est désormais vérifiée à partir du SAN, et non du champ Common Name comme source principale du nom.

SAN

Un seul certificat peut couvrir plusieurs noms :

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

Chaque nom doit figurer dans le SAN.

Wildcard

*.example.com

couvre :

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

mais ne couvre pas automatiquement :

example.com
www.eu.example.com

Le domaine principal doit être ajouté séparément, et le wildcard ne fonctionne que pour un seul niveau d'étiquette.

SNI

Le Server Name Indication permet au client de transmettre le nom d'hôte pendant le handshake, ce qui permet à une même adresse IP de gérer plusieurs certificats. Une mauvaise configuration de SNI provoque souvent l'affichage du certificat d'un autre domaine.

La chaîne de certificats

Le serveur doit envoyer le certificat du domaine ainsi que les certificats intermédiaires nécessaires, mais généralement pas la root. L'absence d'intermédiaire peut fonctionner sur un appareil qui a précédemment enregistré le certificat et échouer sur un autre.

7. La validité des certificats en 2026

Le CA/Browser Forum a adopté un calendrier de réduction de la durée des certificats TLS publics :

Date d'émission	Validité maximale
avant le 15 mars 2026	398 jours
15 mars 2026 - 14 mars 2027	200 jours
15 mars 2027 - 14 mars 2029	100 jours
à partir du 15 mars 2029	47 jours

Cela ne signifie pas que chaque CA émet un certificat pour la durée maximale. Let's Encrypt émet toujours par défaut des certificats de 90 jours, propose des certificats optionnels de six jours et un profil tlsserver avec des certificats de 45 jours disponible pour les déploiements précoces depuis mai 2026.

La conclusion est simple : le renouvellement manuel des certificats cesse d'être une pratique opérationnelle raisonnable.

8. ACME et l'automatisation des certificats

ACME est un protocole standard qui automatise l'enregistrement du compte, la validation du contrôle du domaine, l'émission, le renouvellement et la révocation du certificat.

HTTP-01

La CA récupère un fichier :

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

Avantages :

• configuration simple pour un serveur web unique,
• automatisation facile,
• ne nécessite pas d'API DNS.

Limitations :

• nécessite un port 80 accessible,
• n'émet pas de certificat wildcard,
• le challenge doit atteindre le bon serveur,
• un enregistrement AAAA erroné, un proxy, une redirection ou un load balancer peuvent interrompre la validation.

Let's Encrypt recommande de laisser le port 80 ouvert pour les serveurs web publics et de rediriger le trafic normal vers HTTPS.

DNS-01

Le client publie un enregistrement TXT :

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

Avantages :

• prend en charge les certificats wildcard,
• fonctionne sans serveur HTTP public,
• convient à une gestion centralisée des certificats.

Risques :

• nécessite un accès sécurisé à l'API DNS,
• la propagation et le cache peuvent retarder la validation,
• un token d'API autorisant la modification de toute la zone accroît les conséquences d'une fuite,
• d'anciens enregistrements TXT peuvent compliquer le diagnostic.

Let's Encrypt recommande explicitement d'utiliser DNS-01 avec un fournisseur proposant une API, car l'automatisation des renouvellements est essentielle. Attribuez au token la portée la plus restreinte possible : de préférence uniquement les enregistrements _acme-challenge, et non la gestion du domaine, du compte ou de toutes les zones.

Les certificats wildcard chez Let's Encrypt nécessitent DNS-01.

TLS-ALPN-01

La validation s'effectue via une connexion TLS spéciale sur le port 443 et le protocole ALPN. Elle est utile pour les proxys spécialisés et les systèmes de gestion des certificats, mais elle est plus rarement configurée manuellement.

Renewal Information

Un client ACME moderne devrait prendre en charge l'ACME Renewal Information, à savoir ARI. Au lieu de renouveler chaque certificat selon un seuil fixe unique, le client peut recevoir de la CA une fenêtre de renouvellement suggérée. Let's Encrypt recommande de consulter les informations ARI au moins deux fois par jour.

9. CAA et ACME : exemple pratique

Pour les certificats Let's Encrypt :

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

Si vous ne voulez pas de wildcard :

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

Avant l'émission, une CA publique est tenue de vérifier le CAA. À partir du 15 mars 2026, les exigences du CA/Browser Forum imposent également la validation DNSSEC pour les requêtes liées au CAA effectuées depuis la perspective réseau principale, et une erreur de validation DNSSEC ne doit pas être interprétée comme une autorisation d'émission.

Après un changement de CA, pensez à mettre à jour le CAA avant de lancer le nouveau processus d'émission.

10. HTTPS, redirections et HSTS

Schéma minimal :

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

Après avoir confirmé le bon fonctionnement complet de HTTPS, vous pouvez ajouter :

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

HSTS indique au navigateur d'utiliser à l'avenir uniquement HTTPS et de ne pas permettre de contourner certaines erreurs de certificat.

Ne commencez pas par un max-age long, includeSubDomains et preload si :

• il existe des sous-domaines sans HTTPS,
• une partie de l'infrastructure est gérée par un partenaire,
• le processus de renouvellement n'a pas été testé,
• il n'existe pas de surveillance des certificats,
• on ne sait pas si l'ancien service sera encore nécessaire.

Le HSTS preload inscrit la règle dans la distribution des navigateurs. La suppression de l'entrée peut prendre des semaines.

11. Les erreurs DNS les plus fréquentes

Enregistrement AAAA erroné

L'IPv4 fonctionne, mais une partie des clients choisit un IPv6 hors service. Les symptômes sont aléatoires selon le réseau de l'utilisateur.

CNAME et autres enregistrements sous le même nom

L'alias entre en conflit avec les enregistrements d'adresse, MX ou TXT. Le panneau du fournisseur peut bloquer la modification ou générer une zone ambiguë.

Délégation NS incohérente

Le bureau d'enregistrement indique des serveurs différents de ceux de la zone, ou l'un des serveurs possède une version plus ancienne des données.

Ancien DS après un changement de DNS

Le domaine renvoie un SERVFAIL uniquement chez les resolvers validant DNSSEC.

TTL trop bas en permanence

Il augmente le nombre de requêtes et la sensibilité à une indisponibilité temporaire du DNS, sans garantir automatiquement un failover rapide.

TTL trop élevé avant une migration

Les anciennes adresses restent en cache pendant de nombreuses heures.

Enregistrements TXT laissés en place

Les anciens tokens de vérification et ACME compliquent l'audit et accroissent le chaos opérationnel.

Manque de cohérence entre www et l'apex

example.com et www.example.com pointent vers des systèmes différents, possèdent des certificats différents ou créent une boucle de redirection.

12. Les erreurs TLS et de certificats les plus fréquentes

Certificat expiré

Le plus souvent, la cause n'est pas l'absence d'automatisation, mais un automate qui a cessé de fonctionner sans alerte.

Le certificat ne couvre pas l'hôte

Un certificat pour example.com ne protège pas automatiquement www.example.com.

Chaîne incomplète

Il manque un certificat intermédiaire. Le problème peut n'apparaître que sur des appareils récents ou certains clients.

Mauvais certificat à cause de SNI

Le reverse proxy possède un virtual host par défaut erroné, ou le nouveau domaine n'a pas été ajouté au mappage.

Anciens protocoles et cipher suites

Le serveur propose encore TLS 1.0/1.1 ou d'anciennes suites, car la configuration date de nombreuses années.

Absence de cohérence sur plusieurs couches

Le CDN possède un certificat public valide, mais la connexion CDN→origin n'est pas chiffrée ou ne vérifie pas le nom d'hôte.

Renouvellement effectué, mais le processus n'a pas rechargé le serveur

Le nouveau fichier de certificat existe sur le disque, mais Nginx, Apache, HAProxy ou l'application utilise toujours l'ancien certificat en mémoire.

13. Diagnostic étape par étape

Enregistrements DNS

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

Délégation

dig example.com NS
dig +trace example.com

DNSSEC

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

Un SERVFAIL alors que tout fonctionne sans validation est un signe fort d'un problème DNSSEC.

Certificat et SNI

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

Dates du certificat

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 et HSTS

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

Vérifiez la redirection, Strict-Transport-Security, le hostname, le statut final et l'absence de boucle.

Vous pouvez également utiliser gratuitement l'Inspecteur DNS et SSL POLPROG, qui affiche les enregistrements DNS ainsi que les informations sur le certificat TLS. Complétez le test avec l'Inspecteur des en-têtes de sécurité, la Santé du site et l'article Les bases de la sécurité des applications web.

14. Surveillance en production

Ne surveillez pas uniquement la page d'accueil depuis un seul emplacement. Ensemble minimal :

• la réponse du DNS faisant autorité,
• les enregistrements A, AAAA, CNAME, NS, MX et CAA,
• la validation DNSSEC,
• la disponibilité en IPv4 et IPv6,
• les dates du certificat,
• la conformité du SAN,
• la chaîne complète,
• TLS 1.2 et TLS 1.3,
• la redirection finale HTTP→HTTPS,
• HSTS,
• la réponse de l'origin derrière le CDN,
• le fonctionnement d'ACME et le dernier renouvellement réussi.

Seuils d'alerte pour les certificats

Pour un système entièrement automatique :

Temps restant	Réaction
30 jours	avertissement ou contrôle de tendance
14 jours	alerte nécessitant une analyse
7 jours	incident opérationnel
3 jours	alerte critique et escalade
moins de 24 h	panne imminente

Les seuils doivent être adaptés à la durée du certificat. Pour les certificats de six jours ou de 45 jours, la surveillance doit réagir bien plus tôt, proportionnellement au cycle de renouvellement.

15. Checklist de sécurité DNS et TLS

Bureau d'enregistrement et DNS

• Le compte du bureau d'enregistrement dispose de MFA.
• Le transfert du domaine est verrouillé.
• Les coordonnées et le processus de récupération sont à jour.
• Au moins deux serveurs DNS faisant autorité sont utilisés.
• Les serveurs fonctionnent dans des réseaux ou des emplacements distincts.
• La délégation NS chez le bureau d'enregistrement et dans la zone est cohérente.
• Les enregistrements A et AAAA pointent vers une infrastructure active.
• IPv6 est réellement surveillé.
• Les enregistrements MX, SPF, DKIM et DMARC sont conservés lors des migrations.
• CAA n'autorise que les CA utilisées.
• Il n'y a pas d'enregistrements TXT ni de tokens de vérification superflus.
• Le TTL a été abaissé à l'avance avant la migration.
• Le TTL a été augmenté après stabilisation.
• L'accès à l'API DNS dispose de privilèges minimaux.

DNSSEC

• Le fournisseur prend en charge DNSSEC et la rotation des clés.
• L'enregistrement DS chez le bureau d'enregistrement correspond au DNSKEY actif.
• Les changements d'opérateur DNS disposent d'un plan de migration DNSSEC.
• Les anciens DS et clés ne sont supprimés qu'après l'expiration du cache.
• Le domaine est testé au moyen d'un resolver validant.
• Une alerte détecte les SERVFAIL et l'expiration des signatures.

Certificats

• Les certificats sont émis et renouvelés via ACME.
• Le renouvellement a été testé, pas seulement la première émission.
• Le processus recharge le serveur après l'installation d'un nouveau certificat.
• Tous les hôtes figurent dans le SAN.
• Le wildcard est utilisé en connaissance de cause.
• La chaîne contient les intermédiaires appropriés.
• La clé privée ne quitte pas le système approprié.
• Les autorisations d'accès à la clé sont restreintes.
• Les alertes fonctionnent indépendamment du client ACME lui-même.
• DNS-01 utilise un token d'API restreint.
• HTTP-01 fonctionne en IPv4 et IPv6.
• La CA de staging est utilisée pour les tests d'automatisation.

TLS et HTTPS

• TLS 1.3 est activé.
• TLS 1.2 n'est conservé que pour la compatibilité nécessaire.
• TLS 1.0, TLS 1.1 et SSL sont désactivés.
• Le serveur ne propose pas de cipher suites obsolètes.
• SNI renvoie le certificat approprié pour chaque hôte.
• HTTP redirige directement vers HTTPS.
• Il n'y a pas de mixed content.
• HSTS a été déployé par étapes.
• includeSubDomains est sûr pour l'ensemble du domaine.
• Le preload a été analysé avant la soumission.
• CDN→origin utilise également un TLS correctement vérifié.

Verdict

Une bonne configuration DNS et TLS en 2026 repose sur quatre principes :

1. Le DNS doit être cohérent et résilient sur le plan opérationnel.
2. DNSSEC ne doit être déployé qu'avec une gestion correcte des DS et des clés.
3. Les certificats doivent être gérés automatiquement via ACME.
4. TLS 1.3, une chaîne correcte, la surveillance et HSTS font partie d'un même processus, et non de tâches distinctes.

Le principal risque n'est pas l'absence de « cadenas vert » le jour du lancement. C'est une panne silencieuse quelques mois plus tard : un certificat expiré, un enregistrement AAAA obsolète, un DS laissé en place, un token DNS aux privilèges excessifs ou un automate de renouvellement que personne n'a surveillé.