alliance-boreale/docs/opération/05_Operation_DNS_Federee.md

# 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.<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 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 |