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

1290 lines
34 KiB
Markdown
Raw Normal View History

# Document 5 : Opération DNS Fédérée
## L'Alliance Boréale
**Version :** 1.0
**Date :** 23 octobre 2025
**Statut :** DRAFT - Validation requise par Cercle Technique
**Prérequis :** `nomenclature_v2.md` (nommage et adressage)
**Auteur :** Claude (profils #4 Architecte Réseau, #10 Auditeur Sécurité)
**Licence :** CC-BY-SA 4.0
---
## Table des Matières
1. [Introduction](#1-introduction)
2. [Principes de la Fédération DNS](#2-principes-de-la-fédération-dns)
3. [Architecture DNS Distribuée](#3-architecture-dns-distribuée)
4. [Standards Techniques Obligatoires](#4-standards-techniques-obligatoires)
5. [Processus de Délégation de Zones](#5-processus-de-délégation-de-zones)
6. [Niveaux de Service DNS](#6-niveaux-de-service-dns)
7. [Sécurité et Gestion des Incidents](#7-sécurité-et-gestion-des-incidents)
8. [Monitoring et Outils Mutualisés](#8-monitoring-et-outils-mutualisés)
9. [Retrait et Transition](#9-retrait-et-transition)
10. [Annexes](#10-annexes)
---
## 1. Introduction
### 1.1 Objectif de ce Document
Ce document définit **comment les membres de L'Alliance Boréale opèrent et fédèrent leur infrastructure DNS**. Il couvre :
- Les relations primaire/secondaire entre membres
- Les standards techniques (AXFR, DNSSEC, TSIG)
- Les processus de délégation de zones
- La gestion collective des incidents DNS
### 1.2 Prérequis
**Ce document s'appuie sur `nomenclature_v2.md`** pour :
- Nommage des serveurs DNS (`dns-master.infra.<membre>.alliance-boreale.ca`)
- Plan d'adressage IP (10.0.2.0/24 pour DNS)
- Structure des zones DNS fédérées
**Lecture obligatoire** : `nomenclature_v2.md` avant de procéder.
### 1.3 Portée
Ce document s'applique à **tous les membres actifs** de L'Alliance Boréale. Les membres en probation peuvent l'appliquer partiellement (DNSSEC optionnel).
### 1.4 Alignement avec les Valeurs
**Autonomie :** Chaque membre gère ses zones de manière souveraine.
**Résilience :** DNS secondaires mutuels entre pairs.
**Standards ouverts :** RFCs DNS, DNSSEC, protocoles documentés.
**Subsidiarité :** L'Alliance n'intervient que pour coordination minimale.
---
## 2. Principes de la Fédération DNS
### 2.1 Autonomie Locale
**Chaque membre est autoritaire pour ses propres zones.**
```
czp.alliance-boreale.ca → Géré par Chezlepro
nul.alliance-boreale.ca → Géré par Nuage Libre
tli.alliance-boreale.ca → Géré par TechnoLibre
```
L'Alliance ne contrôle **aucun contenu** des zones membres. Elle coordonne uniquement :
- Délégation depuis la zone parent (`alliance-boreale.ca`)
- Standards techniques minimums (DNSSEC, AXFR)
### 2.2 Résilience par la Redondance
**Minimum 2 serveurs DNS par membre.**
Configuration type :
```
ns1.czp.alliance-boreale.ca → DNS Primaire (VMID 02001)
ns2.czp.alliance-boreale.ca → DNS Secondaire (VMID 02002)
```
**Optionnel mais recommandé :** DNS secondaire croisé avec un autre membre.
Exemple :
```
czp.alliance-boreale.ca:
- ns1.czp.alliance-boreale.ca (primaire)
- ns2.czp.alliance-boreale.ca (secondaire local)
- ns1.nul.alliance-boreale.ca (secondaire croisé)
```
**Avantages :**
- Résilience accrue (3 sites distincts)
- Solidarité technique entre membres
- Détection rapide de pannes (monitoring mutuel)
### 2.3 Standards Ouverts
**L'Alliance privilégie exclusivement les standards RFC.**
- RFC 1034/1035 : DNS de base
- RFC 2136 : DNS UPDATE (optionnel)
- RFC 4033-4035 : DNSSEC
- RFC 5936 : AXFR
- RFC 8945 : TSIG (authentification)
**Aucune extension propriétaire** ne doit être requise pour interopérer.
### 2.4 Confiance Vérifiable
**DNSSEC est obligatoire pour les zones critiques.**
**Zones critiques :**
- Zone racine membre (`czp.alliance-boreale.ca`)
- Services d'infrastructure (`*.infra.czp.alliance-boreale.ca`)
- Email (domaines avec enregistrements MX)
**Zones optionnelles :**
- Zones tenants (décision du membre)
- Environnements dev/staging
**Vérification :** DNSViz.net doit afficher une chaîne DNSSEC valide.
---
## 3. Architecture DNS Distribuée
### 3.1 Vue d'Ensemble
```
┌─────────────────────────────────────────────────────────────┐
│ alliance-boreale.ca (Zone Parent) │
│ Géré par: Cercle Opérationnel │
│ Serveurs: ns1/ns2/ns3.alliance-boreale.ca │
└────────────┬────────────────────────────────────────────────┘
│ Délégations NS
┌───────┴────────┬─────────────┬──────────────┐
│ │ │ │
┌────▼─────┐ ┌────▼─────┐ ┌───▼──────┐ ┌───▼──────┐
│ czp │ │ nul │ │ tli │ │ autres │
│ Zone │ │ Zone │ │ Zone │ │ membres │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
```
### 3.2 Serveurs DNS Autoritaires
**Minimum requis : 2 serveurs**
**Configuration type (membre Chezlepro) :**
| Serveur | VMID | IP Interne | IP Publique | Rôle |
|---------|------|------------|-------------|------|
| ns1.czp.alliance-boreale.ca | 02001 | 10.0.2.10 | 198.51.100.10 | Primaire (MASTER) |
| ns2.czp.alliance-boreale.ca | 02002 | 10.0.2.11 | 198.51.100.11 | Secondaire (SLAVE) |
**Recommandé : 3 serveurs (avec secondaire croisé)**
| Serveur | Localisation | Rôle |
|---------|--------------|------|
| ns1.czp.alliance-boreale.ca | Datacenter Chezlepro | MASTER |
| ns2.czp.alliance-boreale.ca | Datacenter Chezlepro | SLAVE |
| ns1.nul.alliance-boreale.ca | Datacenter Nuage Libre | SLAVE (croisé) |
### 3.3 Relations Primaire/Secondaire
**Architecture recommandée : Hub & Spoke modifié**
```
Membre A (czp)
├─ ns1.czp (MASTER)
├─ ns2.czp (SLAVE local)
└─ ns1.nul (SLAVE croisé) ← AXFR depuis ns1.czp
Membre B (nul)
├─ ns1.nul (MASTER)
├─ ns2.nul (SLAVE local)
└─ ns1.tli (SLAVE croisé) ← AXFR depuis ns1.nul
Membre C (tli)
├─ ns1.tli (MASTER)
├─ ns2.tli (SLAVE local)
└─ ns1.czp (SLAVE croisé) ← AXFR depuis ns1.tli
```
**Avantages :**
- Topologie en triangle (pas de point unique de défaillance)
- Charge répartie (pas de "hub" central)
- Latence réduite (géographiquement distribué)
### 3.4 Stratégies de Délégation de Zones
**Principe : Délégation minimale nécessaire**
**Zone parent (`alliance-boreale.ca`) :**
```
; Délégation zone membre Chezlepro
czp NS ns1.czp.alliance-boreale.ca.
czp NS ns2.czp.alliance-boreale.ca.
czp NS ns1.nul.alliance-boreale.ca. ; Secondaire croisé
ns1.czp A 198.51.100.10
ns2.czp A 198.51.100.11
ns1.nul A 198.51.100.20 ; IP publique Nuage Libre
```
**Zone membre (`czp.alliance-boreale.ca`) :**
```
$ORIGIN czp.alliance-boreale.ca.
; SOA et NS
@ SOA ns1.czp.alliance-boreale.ca. admin.czp.alliance-boreale.ca. (
2025102301 ; Serial
3600 ; Refresh
1800 ; Retry
1209600 ; Expire
3600 ; Minimum TTL
)
@ NS ns1.czp.alliance-boreale.ca.
@ NS ns2.czp.alliance-boreale.ca.
@ NS ns1.nul.alliance-boreale.ca.
; Sous-délégation infrastructure
infra NS ns1.czp.alliance-boreale.ca.
infra NS ns2.czp.alliance-boreale.ca.
```
**Pas de délégation récursive excessive.** Si un membre a besoin de sous-zones complexes, il les gère en interne (pas de nouvelle délégation depuis la zone parent).
---
## 4. Standards Techniques Obligatoires
### 4.1 Logiciel DNS Recommandé
**Primaire : PowerDNS Authoritative Server**
**Pourquoi PowerDNS ?**
- Open source (GPLv2)
- Backend SQL (PostgreSQL/MySQL) → auditable
- DNSSEC natif
- API REST (automatisation)
- Support AXFR/NOTIFY robuste
**Alternatives acceptées :**
- BIND9 (si configuration validée par pair)
- NSD (si DNSSEC géré manuellement)
- Knot DNS
**Inacceptable :**
- DNS Windows Server (non open source)
- Solutions cloud propriétaires sans AXFR (Route53, Cloudflare seul)
### 4.2 DNSSEC Obligatoire
**Pour qui ?**
- Membres actifs : **Obligatoire** pour zones critiques
- Membres en probation : **Recommandé** (optionnel pendant probation)
**Configuration minimale :**
```bash
# Générer clés DNSSEC (PowerDNS)
pdnsutil secure-zone czp.alliance-boreale.ca
pdnsutil rectify-zone czp.alliance-boreale.ca
# Vérifier
pdnsutil check-zone czp.alliance-boreale.ca
```
**DS Records :**
Le membre doit fournir ses DS records au Cercle Opérationnel pour insertion dans la zone parent.
**Commande d'export :**
```bash
pdnsutil show-zone czp.alliance-boreale.ca | grep DS
```
**Validation publique :**
```bash
dig +dnssec czp.alliance-boreale.ca @8.8.8.8
# Doit afficher: flags: ad (Authenticated Data)
```
**Outil de validation :** DNSViz.net
### 4.3 AXFR Sécurisé
**AXFR = Transfert de zone complet depuis primaire vers secondaires.**
**Sécurité obligatoire :**
1. **ACL strictes** : Liste blanche des IPs autorisées
2. **TSIG** : Authentification cryptographique (recommandé)
#### Configuration AXFR avec ACL (PowerDNS)
**Sur le MASTER (ns1.czp) :**
```sql
-- Table domainmetadata
INSERT INTO domainmetadata (domain_id, kind, content)
VALUES (
(SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'),
'ALLOW-AXFR-FROM',
'10.0.2.11' -- ns2.czp (secondaire local)
);
INSERT INTO domainmetadata (domain_id, kind, content)
VALUES (
(SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'),
'ALLOW-AXFR-FROM',
'198.51.100.20' -- ns1.nul (secondaire croisé)
);
```
**Sur le SLAVE (ns2.czp ou ns1.nul) :**
```conf
# /etc/powerdns/pdns.conf
slave=yes
superslave=no
```
**Test AXFR :**
```bash
dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR
# Doit retourner toute la zone
```
#### Configuration AXFR avec TSIG (recommandé)
**Générer clé TSIG :**
```bash
tsig-keygen czp-nul-xfer > /etc/powerdns/tsig.key
```
**Contenu du fichier :**
```
key "czp-nul-xfer" {
algorithm hmac-sha256;
secret "Base64EncodedSecretHere==";
};
```
**Configuration MASTER (ns1.czp) :**
```sql
-- Ajouter TSIG key
INSERT INTO tsigkeys (name, algorithm, secret)
VALUES ('czp-nul-xfer', 'hmac-sha256', 'Base64EncodedSecretHere==');
-- Associer à la zone
INSERT INTO domainmetadata (domain_id, kind, content)
VALUES (
(SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'),
'TSIG-ALLOW-AXFR',
'czp-nul-xfer'
);
```
**Configuration SLAVE (ns1.nul) :**
```conf
# /etc/powerdns/pdns.conf (ajouter)
include-dir=/etc/powerdns/tsig.d
# /etc/powerdns/tsig.d/czp.conf
zone "czp.alliance-boreale.ca" {
type slave;
masters { 198.51.100.10 key czp-nul-xfer; };
};
```
**Test AXFR avec TSIG :**
```bash
dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR -y hmac-sha256:czp-nul-xfer:Base64EncodedSecretHere==
```
### 4.4 Notifications (NOTIFY)
**RFC 1996 : DNS NOTIFY**
Quand la zone primaire change, elle envoie un NOTIFY aux secondaires pour déclencher AXFR immédiat.
**Configuration (PowerDNS) :**
```sql
-- Activer NOTIFY vers secondaires
INSERT INTO domainmetadata (domain_id, kind, content)
VALUES (
(SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'),
'ALSO-NOTIFY',
'10.0.2.11' -- ns2.czp
);
INSERT INTO domainmetadata (domain_id, kind, content)
VALUES (
(SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'),
'ALSO-NOTIFY',
'198.51.100.20' -- ns1.nul (secondaire croisé)
);
```
**Vérification :**
```bash
# Modifier un enregistrement sur MASTER
# Vérifier logs SLAVE pour "NOTIFY received"
tail -f /var/log/pdns.log | grep NOTIFY
```
### 4.5 TTL Raisonnables
**Équilibre cache / réactivité**
**Recommandations :**
| Type d'enregistrement | TTL Recommandé | Rationale |
|----------------------|----------------|-----------|
| SOA (minimum) | 3600s (1h) | Cache raisonnable |
| NS | 86400s (24h) | Changent rarement |
| A/AAAA (services) | 3600s (1h) | Migration possible |
| A/AAAA (infra critique) | 1800s (30min) | Réactivité incidents |
| MX | 3600s (1h) | Standard email |
| TXT (SPF, DKIM) | 3600s (1h) | Changent occasionnellement |
| CNAME | 3600s (1h) | Flexibilité |
**À éviter :**
- TTL < 300s (5min) : Charge excessive sur DNS
- TTL > 86400s (24h) pour services : Lenteur migration/incident
**Exception :** Pendant migration planifiée, réduire temporairement TTL à 300s, puis revenir à 3600s après.
---
## 5. Processus de Délégation de Zones
### 5.1 Demande de Délégation
**Qui ?** Nouveau membre en onboarding (semaines 3-4)
**Prérequis :**
1. ✅ Serveurs DNS configurés (ns1, ns2)
2. ✅ Zone membre créée localement
3. ✅ AXFR fonctionnel entre ns1 et ns2
4. ✅ IPs publiques stables et documentées
5. ✅ (Optionnel) DNSSEC activé et DS records disponibles
**Procédure :**
1. **Soumettre demande via Matrix (#technique)**
Template :
```
Demande de délégation DNS
===========================
Membre : Chezlepro (czp)
Zone demandée : czp.alliance-boreale.ca
Parrain : Nuage Libre (nul)
Serveurs NS :
- ns1.czp.alliance-boreale.ca (198.51.100.10)
- ns2.czp.alliance-boreale.ca (198.51.100.11)
- ns1.nul.alliance-boreale.ca (198.51.100.20) [secondaire croisé]
DNSSEC : Oui
DS Records : (joint en annexe)
Tests effectués :
✅ dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA
✅ dig @ns2.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA
✅ AXFR ns1 → ns2 fonctionnel
✅ DNSViz.net validé (si DNSSEC)
Délai souhaité : 2025-10-28
```
2. **Validation technique par un pair**
Un membre actif (idéalement le parrain) vérifie :
- [ ] Résolution SOA sur ns1 et ns2
- [ ] AXFR fonctionne
- [ ] DNSSEC valide (si activé)
- [ ] Pas de conflit de nommage
**Commandes de validation :**
```bash
# Test SOA
dig @198.51.100.10 czp.alliance-boreale.ca SOA +short
# Test AXFR
dig @198.51.100.10 czp.alliance-boreale.ca AXFR +short | wc -l
# Test DNSSEC
dig @198.51.100.10 czp.alliance-boreale.ca DNSKEY +dnssec
# Validation DNSViz (manuel)
# https://dnsviz.net/d/czp.alliance-boreale.ca/dnssec/
```
3. **Approbation Cercle Opérationnel**
Vote de consentement (asynchrone, Matrix ou réunion).
Critères :
- Validation technique OK
- Membre en règle (probation active)
- Pas d'objection motivée
**Délai** : 48-72h maximum
4. **Insertion dans zone parent**
Membre du Cercle Opérationnel (rotation) effectue :
```bash
# Éditer zone alliance-boreale.ca
pdnsutil edit-zone alliance-boreale.ca
# Ajouter délégation
czp NS ns1.czp.alliance-boreale.ca.
czp NS ns2.czp.alliance-boreale.ca.
czp NS ns1.nul.alliance-boreale.ca.
ns1.czp A 198.51.100.10
ns2.czp A 198.51.100.11
# Si DNSSEC activé, ajouter DS records
czp DS 12345 13 2 (hash SHA256)
# Incrémenter serial SOA
pdnsutil increase-serial alliance-boreale.ca
# Vérifier
pdnsutil check-zone alliance-boreale.ca
```
5. **Notification et tests publics**
Post Matrix (#annonces) :
```
🎉 Nouvelle délégation DNS : czp.alliance-boreale.ca
Serveurs : ns1/ns2.czp.alliance-boreale.ca + ns1.nul (croisé)
DNSSEC : Activé ✅
Tests publics bienvenus !
```
**Tests publics (par tous) :**
```bash
# Depuis n'importe où sur Internet
dig czp.alliance-boreale.ca NS @8.8.8.8
dig mail.czp.alliance-boreale.ca A @8.8.8.8
dig +dnssec czp.alliance-boreale.ca @1.1.1.1
```
### 5.2 Enregistrement au Registraire
Une fois la délégation active, mettre à jour le fichier YAML du membre.
**Fichier : `registraire/membres/m001-chezlepro.yml`**
```yaml
dns:
primary:
- name: ns1.czp.alliance-boreale.ca
ip: 198.51.100.10
vmid: 02001
- name: ns2.czp.alliance-boreale.ca
ip: 198.51.100.11
vmid: 02002
secondary_cross:
- name: ns1.nul.alliance-boreale.ca
ip: 198.51.100.20
member: nul
zones_delegated:
- czp.alliance-boreale.ca
dnssec: true
dnssec_ds_records:
- "12345 13 2 ABC123..."
last_delegation_date: "2025-10-28"
validated_by: m002 # Parrain ou pair
```
### 5.3 Propagation et Tests
**Délai de propagation :** 24-48h (selon TTL des NS records parent)
**Tests progressifs :**
| Temps | Test | Commande |
|-------|------|----------|
| T+0 | Résolution depuis DNS autoritaires Alliance | `dig @ns1.alliance-boreale.ca czp.alliance-boreale.ca NS` |
| T+1h | Résolution depuis Google DNS | `dig @8.8.8.8 czp.alliance-boreale.ca NS` |
| T+24h | Résolution depuis Cloudflare | `dig @1.1.1.1 czp.alliance-boreale.ca NS` |
| T+48h | Validation DNSSEC globale | DNSViz.net |
---
## 6. Niveaux de Service DNS
### 6.1 Disponibilité Cible
**Membres actifs : ≥ 99.5% (uptime annuel)**
Calcul :
```
99.5% = 43.8 heures de downtime/an maximum
= 3.65 heures/mois
= ~50 minutes/semaine
```
**Mesure :** Monitoring Prometheus avec probe externe (Blackbox Exporter)
**Exclusions (downtime justifié) :**
- Maintenance planifiée (notifiée 48h à l'avance)
- Incident majeur hors contrôle (DDoS massif, panne datacenter)
### 6.2 Temps de Réponse Acceptable
**Requêtes DNS simples (A, AAAA, NS) :**
- Médiane : < 50ms
- P95 : < 100ms
- P99 : < 200ms
**Requêtes DNSSEC (avec validation) :**
- Médiane : < 100ms
- P95 : < 200ms
- P99 : < 500ms
**Mesure :** Prometheus `probe_duration_seconds` histogram
### 6.3 Maintenance Planifiée
**Notification requise : 48h minimum**
**Canaux de notification :**
1. Matrix #annonces
2. Status page (status.czp.alliance-boreale.ca)
3. Email liste membres (si critique)
**Template notification :**
```
🔧 Maintenance DNS planifiée
Membre : Chezlepro (czp)
Date : 2025-10-30 03:00-05:00 UTC
Durée estimée : 2 heures
Impact : Résolution DNS czp.alliance-boreale.ca
(secondaires actifs : ns2.czp + ns1.nul)
Services affectés : ns1.czp.alliance-boreale.ca (MASTER)
Services maintenus : ns2.czp.alliance-boreale.ca (SLAVE)
Raison : Migration serveur physique
Contact : admin@chezlepro.tech
```
**Bonne pratique :**
- Planifier entre 2h-6h du matin (heure locale)
- Vérifier que secondaires sont opérationnels avant
- Monitoring actif pendant maintenance
### 6.4 Gestion des Incidents DNS
**Classification :**
| Priorité | Définition | SLA Réponse | SLA Résolution |
|----------|------------|-------------|----------------|
| P0 | Tous DNS down (zone inaccessible) | 15 min | 2 heures |
| P1 | DNS primaire down (secondaires OK) | 30 min | 4 heures |
| P2 | Lenteur résolution (>500ms) | 1 heure | 8 heures |
| P3 | Anomalie non critique | 4 heures | 24 heures |
**Procédure incident :**
1. **Détection**
- Monitoring Prometheus (AlertManager)
- Rapport Matrix (#incidents)
- Signalement utilisateur
2. **Notification**
- Post Matrix #incidents immédiat
- Mention @dns-oncall si configuré
- Update status page
3. **Investigation**
- Logs DNS serveur : `tail -f /var/log/pdns.log`
- Métriques Grafana
- Tests externes : `dig`, `nslookup`
4. **Résolution**
- Corriger ou basculer sur secondaire
- Valider résolution publique
- Post Matrix résolution
5. **Post-Mortem (si P0/P1, >1h downtime)**
- Documenter cause racine
- Corrective actions
- Publier sur wiki (transparence)
**Template Post-Mortem :**
```markdown
# Post-Mortem : Panne DNS czp.alliance-boreale.ca
**Date :** 2025-10-25
**Durée :** 1h30
**Impact :** Résolution DNS czp.alliance-boreale.ca indisponible
**Priorité :** P0
## Chronologie
- 14:23 UTC : Alerte Prometheus "DNS ns1.czp down"
- 14:25 UTC : Confirmation manuelle (dig timeout)
- 14:30 UTC : Basculement manuel vers ns2.czp
- 14:45 UTC : Identification cause (OOM serveur ns1)
- 15:20 UTC : Redémarrage ns1, AXFR sync OK
- 15:53 UTC : Retour normal, monitoring OK
## Cause Racine
Out-of-Memory sur ns1.czp (processus PowerDNS tué par OOM killer).
Cause : Fuite mémoire dans module expérimental (dnsdist).
## Impact
- Zone czp.alliance-boreale.ca inaccessible : 1h30
- Secondaire ns2.czp actif, mais non prioritaire dans délégation
- ~50% requêtes timeouts (clients avec cache OK)
## Actions Correctives
✅ Désactivation dnsdist (immédiat)
✅ Augmentation RAM VM ns1 : 2GB → 4GB
🔄 Configuration monitoring OOM (en cours)
🔄 Rééquilibrage priorité NS (ns2 en premier)
## Leçons Apprises
- Secondaires fonctionnent, mais délégation ordre NS critique
- Besoin alerte proactive RAM/CPU (pas juste down/up)
**Auteur :** admin@chezlepro.tech
**Publié :** wiki.alliance-boreale.ca/postmortems/2025-10-25-dns-czp
```
---
## 7. Sécurité et Gestion des Incidents
### 7.1 Protection contre DDoS
**Couches de protection :**
1. **Firewall (iptables/nftables)**
```bash
# Limiter requêtes DNS/sec par IP source
iptables -A INPUT -p udp --dport 53 -m state --state NEW \
-m recent --set --name dns_limit
iptables -A INPUT -p udp --dport 53 -m state --state NEW \
-m recent --update --seconds 1 --hitcount 20 --name dns_limit \
-j DROP
```
2. **Rate Limiting PowerDNS**
```ini
# /etc/powerdns/pdns.conf
max-queue-length=5000
max-tcp-clients=128
max-tcp-per-client=5
# Limiter réponses NXDOMAIN (cache poisoning)
max-cache-entries=1000000
negquery-cache-ttl=60
```
3. **Anycast (avancé, optionnel)**
Si plusieurs membres dans régions distinctes, anycast BGP pour distribuer charge.
**Note :** Complexe, recommandé seulement si >10 membres actifs.
### 7.2 Détection d'Anomalies
**Monitoring Prometheus : Métriques clés**
```yaml
# prometheus.yml (extrait)
- job_name: 'dns-czp'
static_configs:
- targets: ['198.51.100.10:9153'] # PowerDNS Exporter
metric_relabel_configs:
- source_labels: [__name__]
regex: 'pdns_(up|queries_total|latency_seconds.*)'
action: keep
```
**Alertes AlertManager :**
```yaml
groups:
- name: dns
rules:
- alert: DNSDown
expr: probe_success{job="dns"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "DNS {{ $labels.instance }} down"
- alert: DNSSlowQueries
expr: histogram_quantile(0.95, rate(pdns_latency_seconds_bucket[5m])) > 0.5
for: 10m
labels:
severity: warning
annotations:
summary: "DNS {{ $labels.instance }} slow (P95 > 500ms)"
- alert: DNSHighQueryRate
expr: rate(pdns_queries_total[5m]) > 1000
for: 5m
labels:
severity: warning
annotations:
summary: "DNS {{ $labels.instance }} high query rate (potential DDoS)"
```
### 7.3 Réponse à Incident
**Escalade :**
1. **Auto-détection (Prometheus) :** Post Matrix #incidents automatique
2. **Membre concerné** : Investigate (15-30 min)
3. **Si bloqué** : Demande support Matrix #support
4. **Si P0 non résolu <1h** : Escalade Cercle Opérationnel
5. **Si attaque coordonnée** : Communication collective (tous membres alertés)
**Communication pendant incident :**
**Faire :**
- Updates régulières (toutes les 30 min si P0)
- Être transparent sur cause (même si embarrassant)
- Documenter actions prises
**Éviter :**
- Silence prolongé (anxiété collective)
- Minimiser impact (crédibilité)
- Blâmer outils/tiers sans preuve
### 7.4 Post-Mortem Obligatoire
**Quand ?**
- Tout incident P0 (zone complètement down)
- Incident P1 > 1h (primaire down, même si secondaires OK)
- Incident sécurité (compromission, DDoS majeur)
**Délai :** 7 jours après résolution
**Publication :** Wiki public (transparence)
**Template :** Voir Section 6.4
---
## 8. Monitoring et Outils Mutualisés
### 8.1 Tableau de Bord Partagé
**Objectif :** Visibilité collective sur santé DNS de la fédération
**Outil recommandé :** Grafana mutualisé (hébergé par un membre volontaire)
**URL exemple :** `https://monitoring.alliance-boreale.ca/d/dns-federation`
**Panels :**
1. **Statut Membres (heatmap)**
- Vert : DNS UP (100%)
- Jaune : Dégradé (secondaires OK, primaire down)
- Rouge : DOWN complet
2. **Latence Résolution (par membre)**
- Graphe timeseries P50/P95/P99
- Alerte visuelle si >200ms
3. **Volume Requêtes (stacked area)**
- Requêtes/sec par membre
- Détection pics anormaux
4. **DNSSEC Status**
- Validation chain OK/KO
- Expiration clés KSK/ZSK
**Source données :** Prometheus federation
### 8.2 Alerting Inter-Pairs
**Principe :** Un membre peut monitorer le DNS d'un autre (avec consentement)
**Configuration Prometheus (membre A monitore membre B) :**
```yaml
# prometheus.yml (membre A)
scrape_configs:
- job_name: 'dns-czp-external'
metrics_path: '/probe'
params:
module: [dns_soa]
target: ['czp.alliance-boreale.ca']
static_configs:
- targets:
- ns1.czp.alliance-boreale.ca
- ns2.czp.alliance-boreale.ca
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: 127.0.0.1:9115 # Blackbox Exporter local
```
**Alertes envoyées à membre concerné :**
```yaml
# alertmanager.yml
route:
receiver: 'matrix'
routes:
- match:
job: 'dns-czp-external'
receiver: 'matrix-czp'
continue: true
receivers:
- name: 'matrix-czp'
webhook_configs:
- url: 'https://matrix.alliance-boreale.ca/webhook/czp-alerts'
```
### 8.3 Tests Automatisés (DNS Probes)
**Smokeping pour latence historique**
```bash
# Installation
apt install smokeping
# Configuration
++ DNS-czp
menu = DNS Chezlepro
title = Latence DNS czp.alliance-boreale.ca
probe = DNS
host = ns1.czp.alliance-boreale.ca
++ DNS-nul
menu = DNS Nuage Libre
title = Latence DNS nul.alliance-boreale.ca
probe = DNS
host = ns1.nul.alliance-boreale.ca
```
**Healthchecks.io (optionnel)**
Pour monitoring externe (hors infrastructure Alliance) :
```bash
# Cron job teste DNS toutes les 5 min
*/5 * * * * dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +short > /dev/null && curl -fsS -m 10 --retry 5 https://hc-ping.com/UUID-czp-dns
```
**DNSViz automatisé**
```bash
# Script hebdomadaire vérifie DNSSEC
#!/bin/bash
# /etc/cron.weekly/dnsviz-check
ZONE="czp.alliance-boreale.ca"
REPORT_URL="https://dnsviz.net/d/${ZONE}/dnssec/"
curl -s "$REPORT_URL" | grep -q "No errors"
if [ $? -eq 0 ]; then
echo "✅ DNSSEC OK pour ${ZONE}"
else
echo "❌ DNSSEC ERREUR pour ${ZONE}"
# Notification Matrix
curl -X POST https://matrix.alliance-boreale.ca/webhook/dns-alerts \
-d "{\"zone\": \"${ZONE}\", \"status\": \"dnssec_error\", \"url\": \"${REPORT_URL}\"}"
fi
```
---
## 9. Retrait et Transition
### 9.1 Procédure de Retrait Propre
**Cas 1 : Retrait volontaire d'un membre**
**Étapes :**
1. **Notification préalable : 14 jours minimum**
Post Matrix #annonces :
```
📢 Notification de retrait
Membre : Chezlepro (czp)
Date effective : 2025-11-15
Zone concernée : czp.alliance-boreale.ca
Transition planifiée :
- Délégation DNS maintenue jusqu'au 2025-11-15 23:59 UTC
- Après cette date, zone supprimée de alliance-boreale.ca
- Secondaires croisés désactivés
Contact pour questions : admin@chezlepro.tech
```
2. **Migration des zones déléguées (si applicable)**
Si d'autres membres utilisaient `*.czp.alliance-boreale.ca` :
- Coordonner migration vers nouveau domaine
- Délai suffisant (14 jours minimum)
3. **Désactivation progressive**
| Jour | Action |
|------|--------|
| J-14 | Notification publique |
| J-7 | Désactivation AXFR croisé vers autres membres |
| J-3 | TTL réduits à 300s (préparation suppression) |
| J-0 | Suppression enregistrements NS dans zone parent |
| J+1 | Désactivation serveurs DNS membre |
4. **Nettoyage Registraire**
```yaml
# registraire/membres/m001-chezlepro.yml
status: withdrawn
withdrawn_date: "2025-11-15"
dns:
status: deactivated
last_active: "2025-11-15"
```
**Cas 2 : Retrait forcé (non-conformité grave)**
**Cas exceptionnels :**
- Compromission sécurité non résolue (>30 jours)
- Violation répétée standards techniques
- Indisponibilité prolongée (>99% downtime sur 3 mois)
**Procédure :**
1. Décision Cercle Éthique & Conformité (vote consentement)
2. Notification membre concerné (7 jours pour remédiation)
3. Si non-remédiation : Retrait forcé (délégation supprimée sous 48h)
4. Communication publique (transparence, mais sans humiliation)
### 9.2 Délais de Préavis
| Type de retrait | Préavis | Rationale |
|----------------|---------|-----------|
| Volontaire (membre actif) | 14 jours | Temps migration utilisateurs |
| Volontaire (membre probation) | 7 jours | Moins d'impact |
| Forcé (sécurité) | 48h | Urgence |
| Forcé (non-conformité) | 7 jours | Chance remédiation |
### 9.3 Archivage des Configurations
**Responsabilité : Membre sortant**
**À conserver (membre) :**
- Export complet zone DNS (AXFR dump)
- Configuration serveurs (PowerDNS, BIND)
- Clés DNSSEC (backup sécurisé)
- Logs incidents (6 derniers mois minimum)
**À fournir (Alliance) :**
- Post-mortem si applicable
- Documentation leçons apprises
- Playbooks Ansible (si contribués)
**Responsabilité : Alliance**
**À archiver (Registraire) :**
- Fiche membre (status: withdrawn)
- Historique labels
- Contributions (timebank, audits)
- Décisions liées au membre
**Rétention :** 5 ans (conformité juridique OBNL)
---
## 10. Annexes
### Annexe A : Checklist Onboarding DNS
**Pour nouveau membre :**
- [ ] Serveurs DNS installés (ns1, ns2 minimum)
- [ ] Zone créée localement (`[slug].alliance-boreale.ca`)
- [ ] SOA configuré (serial, refresh, retry, expire, minimum)
- [ ] NS records configurés
- [ ] AXFR fonctionnel ns1 → ns2
- [ ] IPs publiques stables et documentées
- [ ] Firewall configuré (port 53 UDP/TCP ouvert)
- [ ] (Optionnel) DNSSEC activé + DS records générés
- [ ] (Optionnel) TSIG configuré pour AXFR
- [ ] Tests résolution locale réussis
- [ ] Demande délégation soumise Matrix
- [ ] Validation technique par pair
- [ ] Délégation active dans zone parent
- [ ] Tests résolution publique réussis
- [ ] Enregistrement Registraire mis à jour
### Annexe B : Commandes de Diagnostic
**Test résolution depuis Internet :**
```bash
dig @8.8.8.8 czp.alliance-boreale.ca NS
dig @1.1.1.1 mail.czp.alliance-boreale.ca A
```
**Test AXFR (depuis serveur autorisé) :**
```bash
dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR
```
**Test DNSSEC :**
```bash
dig +dnssec @8.8.8.8 czp.alliance-boreale.ca SOA
delv @8.8.8.8 czp.alliance-boreale.ca SOA
```
**Vérification chaîne DNSSEC :**
```bash
drill -TD czp.alliance-boreale.ca @8.8.8.8
```
**Test latence :**
```bash
time dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +short
```
**Vérification propagation globale :**
```bash
# Tool: whatsmydns.net
# https://www.whatsmydns.net/#A/mail.czp.alliance-boreale.ca
```
### Annexe C : Configuration PowerDNS Référence
**Installation (Debian/Ubuntu) :**
```bash
apt update
apt install pdns-server pdns-backend-pgsql postgresql
```
**Configuration minimale (`/etc/powerdns/pdns.conf`) :**
```ini
launch=gpgsql
gpgsql-host=/var/run/postgresql
gpgsql-dbname=powerdns
gpgsql-user=pdns
gpgsql-password=SecurePasswordHere
local-address=0.0.0.0
local-port=53
master=yes
slave=yes
api=yes
api-key=SecureAPIKeyHere
webserver=yes
webserver-address=0.0.0.0
webserver-port=8081
webserver-allow-from=10.0.0.0/8
dnssec=yes
default-soa-content=ns1.@ admin.@ 0 3600 1800 1209600 3600
log-dns-queries=no
log-dns-details=yes
loglevel=4
```
**Création base de données :**
```bash
sudo -u postgres createdb powerdns
sudo -u postgres createuser pdns
sudo -u postgres psql powerdns < /usr/share/doc/pdns-backend-pgsql/schema.pgsql.sql
```
**Création zone :**
```bash
pdnsutil create-zone czp.alliance-boreale.ca
pdnsutil add-record czp.alliance-boreale.ca @ NS ns1.czp.alliance-boreale.ca
pdnsutil add-record czp.alliance-boreale.ca @ NS ns2.czp.alliance-boreale.ca
pdnsutil add-record czp.alliance-boreale.ca ns1 A 198.51.100.10
pdnsutil add-record czp.alliance-boreale.ca ns2 A 198.51.100.11
```
**Activation DNSSEC :**
```bash
pdnsutil secure-zone czp.alliance-boreale.ca
pdnsutil set-nsec3 czp.alliance-boreale.ca '1 0 10 ab' narrow
pdnsutil rectify-zone czp.alliance-boreale.ca
```
**Export DS records :**
```bash
pdnsutil show-zone czp.alliance-boreale.ca | grep DS
```
### Annexe D : Glossaire
| Terme | Définition |
|-------|------------|
| **AXFR** | Transfert complet de zone DNS depuis primaire vers secondaires |
| **DS Record** | Delegation Signer - Lie zone enfant DNSSEC à zone parent |
| **KSK** | Key Signing Key - Clé maître DNSSEC (signe ZSK) |
| **NOTIFY** | Notification envoyée par primaire aux secondaires lors de changement |
| **SOA** | Start of Authority - Enregistrement définissant zone autoritaire |
| **TSIG** | Transaction Signature - Authentification cryptographique AXFR |
| **ZSK** | Zone Signing Key - Clé DNSSEC qui signe les enregistrements |
### Annexe E : Références
**RFCs :**
- RFC 1034, 1035 : DNS (Domain Name System)
- RFC 1996 : DNS NOTIFY
- RFC 2136 : DNS UPDATE
- RFC 4033-4035 : DNSSEC
- RFC 5936 : AXFR
- RFC 8945 : TSIG
**Documentation PowerDNS :**
- https://doc.powerdns.com/authoritative/
- https://doc.powerdns.com/authoritative/dnssec/
**Outils de validation :**
- DNSViz : https://dnsviz.net
- Zonemaster : https://zonemaster.net
- IntoDNS : https://intodns.com
**Monitoring :**
- PowerDNS Exporter : https://github.com/janeczku/powerdns_exporter
- Blackbox Exporter : https://github.com/prometheus/blackbox_exporter
---
## MÉTADONNÉES
**Document :** 05_Operation_DNS_Federee.md
**Version :** 1.0
**Date de création :** 23 octobre 2025
**Auteur :** Claude (profils #4 Architecte Réseau, #10 Auditeur Sécurité)
**Révision par :** Cercle Technique
**Statut :** DRAFT - À valider
**Longueur :** ~10 000 mots (20 pages)
**Licence :** CC BY-SA 4.0
**Sources utilisées :**
- `00_Glossaire_et_Definitions.md` (AXFR, DNSSEC, DNS autoritaire)
- `nomenclature_v2.md` (nommage serveurs DNS, adressage IP)
- `devis_alliance_boreale_v2.md` (structure Document 5)
- `08_Processus_Onboarding_Membres.md` (critères DNS onboarding)
- `01_Charte_Fondatrice_v2_1.md` (Couche 2, valeurs)
**Prochaine révision prévue :** Avril 2026 (après 6 mois d'opération)
---
**Changelog :**
- 2025-10-23 v1.0 : Création initiale Document 5 (Option B)
---
**FIN DE L'OPÉRATION DNS FÉDÉRÉE**
*"Chaque membre gère ses propres zones. Ensemble, nous assurons leur résilience."*
🌲 **L'Alliance Boréale**
*DNS fédéré, autonomie locale, résilience collective.*