Alliance-Boreale/alliance-boreale

Fork 0

Dan Allaire e2d5175975

CI / yaml-lint (push) Waiting to run

Details

CI / ssot-export (push) Waiting to run

Details

CI / tests (push) Waiting to run

Details

CI / docs (push) Waiting to run

Details

restructuration de la documentation

2025-10-24 10:50:25 -04:00

34 KiB

Raw Blame 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

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 :

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

pdnsutil show-zone czp.alliance-boreale.ca | grep DS

Validation publique :

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 :

ACL strictes : Liste blanche des IPs autorisées
TSIG : Authentification cryptographique (recommandé)

Configuration AXFR avec ACL (PowerDNS)

Sur le MASTER (ns1.czp) :

-- 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) :

# /etc/powerdns/pdns.conf
slave=yes
superslave=no

Test AXFR :

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 :

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) :

-- 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) :

# /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 :

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) :

-- 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 :

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

✅ Serveurs DNS configurés (ns1, ns2)
✅ Zone membre créée localement
✅ AXFR fonctionnel entre ns1 et ns2
✅ IPs publiques stables et documentées
✅ (Optionnel) DNSSEC activé et DS records disponibles

Procédure :

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

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 :

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

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

Insertion dans zone parent

Membre du Cercle Opérationnel (rotation) effectue :

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

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) :

# 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

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 :

Matrix #annonces
Status page (status.czp.alliance-boreale.ca)
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 :

Détection
- Monitoring Prometheus (AlertManager)
- Rapport Matrix (#incidents)
- Signalement utilisateur
Notification
- Post Matrix #incidents immédiat
- Mention @dns-oncall si configuré
- Update status page
Investigation
- Logs DNS serveur : tail -f /var/log/pdns.log
- Métriques Grafana
- Tests externes : dig, nslookup
Résolution
- Corriger ou basculer sur secondaire
- Valider résolution publique
- Post Matrix résolution
Post-Mortem (si P0/P1, >1h downtime)
- Documenter cause racine
- Corrective actions
- Publier sur wiki (transparence)

Template Post-Mortem :

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

Firewall (iptables/nftables)

# 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

Rate Limiting PowerDNS

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

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

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

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 :

Auto-détection (Prometheus) : Post Matrix #incidents automatique
Membre concerné : Investigate (15-30 min)
Si bloqué : Demande support Matrix #support
Si P0 non résolu <1h : Escalade Cercle Opérationnel
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 :

Statut Membres (heatmap)
- Vert : DNS UP (100%)
- Jaune : Dégradé (secondaires OK, primaire down)
- Rouge : DOWN complet
Latence Résolution (par membre)
- Graphe timeseries P50/P95/P99
- Alerte visuelle si >200ms
Volume Requêtes (stacked area)
- Requêtes/sec par membre
- Détection pics anormaux
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) :

# 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é :

# 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

# 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) :

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

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

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

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)

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

Nettoyage Registraire

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

Décision Cercle Éthique & Conformité (vote consentement)
Notification membre concerné (7 jours pour remédiation)
Si non-remédiation : Retrait forcé (délégation supprimée sous 48h)
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 :

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é) :

dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR

Test DNSSEC :

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 :

drill -TD czp.alliance-boreale.ca @8.8.8.8

Test latence :

time dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +short

Vérification propagation globale :

# Tool: whatsmydns.net
# https://www.whatsmydns.net/#A/mail.czp.alliance-boreale.ca

Annexe C : Configuration PowerDNS Référence

Installation (Debian/Ubuntu) :

apt update
apt install pdns-server pdns-backend-pgsql postgresql

Configuration minimale (/etc/powerdns/pdns.conf) :

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 :

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 :

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 :

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 :

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 :

Outils de validation :

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.

34 KiB Raw Blame History

Document 5 : Opération DNS Fédérée

L'Alliance Boréale

Table des Matières

1. Introduction

1.1 Objectif de ce Document

1.2 Prérequis

1.3 Portée

1.4 Alignement avec les Valeurs

2. Principes de la Fédération DNS

2.1 Autonomie Locale

2.2 Résilience par la Redondance

2.3 Standards Ouverts

2.4 Confiance Vérifiable

3. Architecture DNS Distribuée

3.1 Vue d'Ensemble

3.2 Serveurs DNS Autoritaires

3.3 Relations Primaire/Secondaire

3.4 Stratégies de Délégation de Zones

4. Standards Techniques Obligatoires

4.1 Logiciel DNS Recommandé

4.2 DNSSEC Obligatoire

4.3 AXFR Sécurisé

Configuration AXFR avec ACL (PowerDNS)

Configuration AXFR avec TSIG (recommandé)

4.4 Notifications (NOTIFY)

4.5 TTL Raisonnables

5. Processus de Délégation de Zones

5.1 Demande de Délégation

5.2 Enregistrement au Registraire

5.3 Propagation et Tests

6. Niveaux de Service DNS

6.1 Disponibilité Cible

6.2 Temps de Réponse Acceptable

6.3 Maintenance Planifiée

6.4 Gestion des Incidents DNS

7. Sécurité et Gestion des Incidents

7.1 Protection contre DDoS

7.2 Détection d'Anomalies

7.3 Réponse à Incident

7.4 Post-Mortem Obligatoire

8. Monitoring et Outils Mutualisés

8.1 Tableau de Bord Partagé

8.2 Alerting Inter-Pairs

8.3 Tests Automatisés (DNS Probes)

9. Retrait et Transition

9.1 Procédure de Retrait Propre

9.2 Délais de Préavis

9.3 Archivage des Configurations

10. Annexes

Annexe A : Checklist Onboarding DNS

Annexe B : Commandes de Diagnostic

Annexe C : Configuration PowerDNS Référence

Annexe D : Glossaire

Annexe E : Références

MÉTADONNÉES

34 KiB

Raw Blame History