alliance-boreale/docs/opération/05_Operation_DNS_Federee.md
Dan Allaire ba80be462c
Some checks are pending
CI / yaml-lint (push) Waiting to run
CI / ssot-export (push) Waiting to run
CI / tests (push) Waiting to run
CI / docs (push) Waiting to run
révision, corrections, bonifications, etc...
2025-10-24 16:31:48 -04:00

7.1 KiB
Raw Blame History

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 LAlliance Boréale opèrent et fédèrent leur infrastructure DNS.
Il sagit dune 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 « LEsprit Boréal » §2.2 Résilience, sobriété, coopération

Conformité Label : Domaines 1 (Infrastructure), 2 (Sécurité), 3 (Interopérabilité).


1. Vue densemble

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

Sapplique à tous les membres actifs.
Les membres en probation peuvent en implémenter une version partielle (DNSSEC optionnel durant onboarding).

1.3 Schéma darchitecture


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), 40334035 (DNSSEC), 5936 (AXFR), 8945 (TSIG).
Aucune extension propriétaire nest 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.<slug>.alliance-boreale.ca ns1.czp…
Secondaire ns2.<slug>.… ns2.czp…
Secondaire fédéré (recommandé) ns1.<pair>.… ns1.nul…

3.3 Relations entre membres

Topologie en triangle (chaque membre héberge le secondaire dun 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 lobjet dun 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 dun 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