Migrez les domaines DNS et de messagerie vers Cloudflare avec DNSSEC, SPF/DKIM/DMARC et zéro temps d'arrêt

Situation initiale : il existe 18 domaines (10 .com, 6 .ru, 2 .io) provenant de deux bureaux d'enregistrement. Le DNS est désormais sur l'ancien hébergement (BIND), certaines zones sont maintenues manuellement, d'autres via le panel. Mail - Microsoft 365 pour 2 domaines et Google Workspace pour le reste. Pour 6 domaines, des sous-domaines clients et la délégation NS vers des systèmes externes sont utilisés. Il existe des temps d'arrêt périodiques dus à des erreurs de zone et à des durées de vie incohérentes. L'objectif est de déplacer le DNS faisant autorité vers Cloudflare, d'activer DNSSEC, de ramener l'authentification du courrier à une norme unique et de configurer la surveillance des modifications.

Environnement technique et restrictions : l'accès aux bureaux d'enregistrement sous les comptes clients, l'accès aux exportations DNS BIND actuelles et aux panneaux M365/GWS seront fournis. Vous ne pouvez pas modifier les adresses IP des services Web et des fournisseurs de messagerie. La livraison du courrier ne doit pas être interrompue ; il est essentiel de préserver tous les sélecteurs MX, TXT (SPF), DKIM et les enregistrements de validation existants. Fenêtre de travail - en semaine de 20h00 à 01h00 UTC+3. Pour 4 domaines, vous ne pouvez pas activer le proxy via Cloudflare pour A/AAAA, uniquement DNS. Il est nécessaire de prendre en compte les caractéristiques du .ru dans les enregistrements DNSSEC et DS auprès du registraire.

Tâches par étapes :
1) Inventaire et audit des zones actuelles - collectez les enregistrements réels de BIND/panel, identifiez les écarts, évaluez les durées de vie actuelles, recherchez les enregistrements obsolètes, comprenez les chaînes de délégation de sous-domaines et les zones à horizon partagé (le cas échéant).
2) Conception d'un schéma DNS cible dans Cloudflare - paramètres de modèle, règles de dénomination, politique TTL, où le proxy est autorisé, où strictement DNS uniquement, préparation d'une liste de zones et de propriétaires.
3) Partie courrier - normaliser le SPF sans dépasser 10 recherches DNS, configurer/vérifier DKIM pour chaque domaine (pour M365 et GWS), générer du DMARC avec un resserrement progressif de la politique et des rapports (rua/ruf), prendre en compte les sous-domaines qui envoient du courrier.
4) Activer DNSSEC - activez dans Cloudflare, préparez correctement DS pour chaque registraire, publiez DS et vérifiez la chaîne de confiance.
5) Migration sans temps d'arrêt - pré-réduire la durée de vie, transférer les enregistrements de manière synchrone, changer de NS chez les bureaux d'enregistrement, contrôler la distribution, plan de secours en cas de problèmes.
6) Surveillance et contrôle des modifications : configurez une surveillance de base des enregistrements DNS et de messagerie (par exemple, via DNSControl/Git, l'API Cloudflare et des vérifications périodiques), activez les notifications sur les modifications de zone, préparez de courtes instructions pour une maintenance ultérieure.

Résultat spécifique : les 18 domaines sont servis par Cloudflare en tant que DNS faisant autorité, DNSSEC est activé et valide, le courrier est livré sans dégradation, SPF/DKIM/DMARC sont configurés et vérifiés, les délégations de sous-domaines sont préservées, le contrôle des changements de zone via le référentiel et la vérification automatique sont mis en œuvre.

Critères d'acceptation mesurables :
- Pour chaque domaine : correction NS chez le registrar et correspondance de l'ensemble des enregistrements critiques (A/AAAA/CNAME/MX/TXT/SRV/CAA) avec l'état initial, sauf nettoyages préalablement convenus.
- DNSSEC : la vérification via des validateurs indépendants montre le statut OK, la chaîne de confiance est en cours de construction (DS est publié), il n'y a pas de SERVFAIL pour les principaux résolveurs.
- Mail : pour chaque domaine, vérification réussie du SPF, DKIM, DMARC (pass) sur les lettres tests, les rapports DMARC commencent à arriver à l'adresse indiquée, le SPF ne dépasse pas les limites.
- Délégations : les sous-domaines avec NS externes continuent à se résoudre de la même manière qu'avant la migration, sans changer le NS cible.
- Temps d'indisponibilité DNS/mail - 0 minute selon les données de surveillance (seules les modifications TTL et la propagation NS sont autorisées sans perte de résolution).

Artefacts : fichier(s) de zone/configuration (par exemple, DNSControl/terraform pour Cloudflare ou exportation via API), tableau de mappage d'enregistrement avant/après, liste des DS par domaine, brèves instructions d'utilisation et liste de contrôle de restauration.