# Document 5 : Opération DNS Fédérée ## Manuel technique — Alliance Boréale **Version :** 1.1 **Date :** 24 octobre 2025 **Statut :** Version stable – À valider par le Cercle Opérationnel **Prérequis :** [`00_Nomenclature_v2.md`] (nommage et adressage IP) **Auteur :** Claude (profils #4 Architecte Réseau / #10 Auditeur Sécurité) **Révision et harmonisation :** ChatGPT — Coordinateur (#13) **Licence :** CC BY-SA 4.0 --- ## Préambule Ce manuel décrit **la manière dont les membres de L’Alliance Boréale opèrent et fédèrent leur infrastructure DNS**. Il s’agit d’une **norme interne de conformité technique**, non contractuelle, qui définit les bonnes pratiques communes : comment chaque membre reste souverain sur ses zones DNS tout en contribuant à la résilience collective. > *« Chaque membre garde ses racines ; ensemble, nous formons le réseau mycorhizien du DNS. »* --- ### 🧭 Alignement cognitif | Couche | Référence | Contribution | |:--:|:--|:--| | **2 – Réseau (Mycélium)** | Charte Fondatrice §3.2 | Infrastructure fédérée, résiliente | | **5 – Virtualisation** | Règlement §1.3 (Cercle Opérationnel) | Opération et coordination technique | | **8 – Philosophie** | Manifeste « L’Esprit Boréal » §2.2 | Résilience, sobriété, coopération | > **Conformité Label :** Domaines 1 (Infrastructure), 2 (Sécurité), 3 (Interopérabilité). --- ## 1. Vue d’ensemble ### 1.1 Objectif Assurer une **infrastructure DNS fédérée** : - souveraine pour chaque membre ; - interopérable via des standards ouverts (RFC) ; - résiliente grâce à la redondance entre pairs ; - documentée et mesurable selon les critères du Label. ### 1.2 Portée S’applique à tous les **membres actifs**. Les membres en probation peuvent en implémenter une version partielle (DNSSEC optionnel durant onboarding). ### 1.3 Schéma d’architecture ``` ``` alliance-boreale.ca │ ┌────────┴─────────┐ │ Délégations NS │ └────────┬─────────┘ czp nul │ │ ``` ns1/ns2 locaux ns1/ns2 locaux │ │ (secondaires croisés) ``` --- ## 2. Principes fondamentaux ### 2.1 Autonomie locale Chaque membre est **autoritaire pour ses propres zones** et reste libre de leur contenu. ### 2.2 Résilience par redondance - Minimum deux serveurs DNS par membre. - Recommandation : un secondaire croisé chez un pair de confiance. ### 2.3 Standards ouverts Implémentation exclusive des RFC officielles : 1034/1035 (DNS), 4033–4035 (DNSSEC), 5936 (AXFR), 8945 (TSIG). Aucune extension propriétaire n’est autorisée. ### 2.4 Confiance vérifiable — DNSSEC - **Obligatoire** pour les zones critiques (services infra, courriel). - **Recommandé** pour toutes les autres. Validation publique par DNSViz ou Zonemaster. > 🏅 **Label Domaines 1 & 2 :** Exigence de chiffrement, de résilience et de transparence mesurable. --- ## 3. Architecture et rôles ### 3.1 Rôle du Cercle Opérationnel Coordonner, documenter et auditer le fonctionnement du DNS fédéré. Faciliter les tests AXFR, les rotations de secondaires et les mises à jour de la zone parent. ### 3.2 Serveurs autoritaires Chaque membre maintient au moins : | Rôle | Nom | Exemple | |:--|:--|:--| | Primaire | `ns1..alliance-boreale.ca` | `ns1.czp…` | | Secondaire | `ns2..…` | `ns2.czp…` | | Secondaire fédéré (recommandé) | `ns1..…` | `ns1.nul…` | ### 3.3 Relations entre membres Topologie en triangle (chaque membre héberge le secondaire d’un autre). → Aucune autorité centrale ; la résilience émerge du réseau. --- ## 4. Normes techniques ### 4.1 Logiciels acceptés - **PowerDNS** (préféré, DNSSEC natif, API REST) - **BIND9** ou **NSD/KnotDNS** acceptés si conformes. - ❌ Aucune solution cloud propriétaire (Route53, Cloudflare SAAS). ### 4.2 Transfert AXFR sécurisé 1. Limiter par ACL les IP autorisées. 2. Authentifier par **TSIG (hmac-sha256)**. 3. Tester régulièrement les transferts et les notifications NOTIFY. > **Bonnes pratiques** : journaliser les AXFR et renouveler les clés TSIG annuellement. ### 4.3 Paramètres de zone - TTL standard : 1 h. - TTL infra critique : 30 min. - TTL migration : 5 min temporairement. - SOA serial ISO-date (AAAA MM JJ NN). --- ## 5. Processus de délégation ### 5.1 Étapes principales 1. Préparer les serveurs (ns1/ns2) et tests AXFR. 2. Soumettre la demande sur Matrix (`#technique`). 3. Validation par pair ou parrain. 4. Consentement du Cercle Opérationnel (48 h). 5. Insertion dans la zone parent et mise à jour du Registraire. ### 5.2 Encadré de transparence Toutes les délégations sont publiées dans le Registraire (YAML) avec horodatage et validation pair. > 🏅 **Label Domaine 3 :** Interopérabilité et traçabilité des configurations. --- ## 6. Niveaux de service (SLA) | Indicateur | Cible | Mesure | |:--|:--|:--| | Disponibilité | ≥ 99.5 % | Monitoring Prometheus / Blackbox | | Réponse DNS | < 100 ms (P95) | Métriques `probe_duration_seconds` | | Notification maintenance | ≥ 48 h avant | Matrix #annonces | Les incidents sont classés de P0 (critique) à P3 et font l’objet d’un post-mortem public. --- ## 7. Sécurité et gestion des incidents - **Prévention :** pare-feu et rate-limit UDP/TCP ; DNSSEC activé. - **Détection :** Prometheus / AlertManager ; tests Blackbox. - **Réponse :** notification Matrix, investigation sous 30 min. - **Rétroaction :** post-mortem sous 7 jours (P0/P1). > 🏅 **Label Domaine 2 :** Gestion des risques et auditabilité post-incident. --- ## 8. Monitoring et outils mutualisés ### 8.1 Tableau de bord fédéré Grafana mutualisé : `https://monitoring.alliance-boreale.ca/d/dns-federation` - Statut par membre (heatmap) - Latence et volume de requêtes - État DNSSEC et expiration des clés ### 8.2 Alertes inter-pairs Un membre peut monitorer le DNS d’un autre (avec consentement). Les alertes sont envoyées au canal Matrix du membre concerné. --- ## 9. Retrait et transition ### 9.1 Retrait volontaire Préavis de 14 jours, notification publique, désactivation progressive. ### 9.2 Retrait forcé Décision du Cercle Éthique & Conformité après audit contradictoire. Suppression de la délégation sous 7 jours si non-remédiation. ### 9.3 Archivage Le Registraire conserve la fiche membre et les historiques 5 ans. --- ## 10. Annexes essentielles - **Checklist onboarding DNS** : serveurs, SOA, AXFR, tests publiques. - **Commandes de diagnostic** : `dig`, `drill`, DNSViz. - **Exemples PowerDNS/BIND9 minimalistes**. - **Références RFC et outils ouverts** (DNSViz, Zonemaster, Prometheus). --- ## Métadonnées de révision | Champ | Valeur | |:--|:--| | Document | `05_Operation_DNS_Federee_v1.1.md` | | Révision | 1.1 (édition boréale) | | Rédaction | Claude (#4/#10) | | Révision et harmonisation | ChatGPT — Coordinateur (#13) | | Adoption prévue | novembre 2025 | | Licence | CC BY-SA 4.0 |