Description pourquoi le DNS n’est pas en libre-service § 1

Le DNS n’est pas une option de panneau d’administration. C’est une dépendance fondamentale qui relie discrètement les utilisateurs, les services, l’authentification, l’e-mail et les chemins de reprise.

La gestion des opérations DNS implique une responsabilité claire, des changements délibérés et une intention documentée: pas d’édition libre-service, pas d’identifiants oubliés, pas de pannes accidentelles.

Le DNS est exploité dans le cadre de la responsabilité long terme d’infrastructure, avec attention aux modes de panne, aux chemins de reprise et à la mémoire collective.

Principes opérationnels § 2

01

Contrôle autoritatif

Une seule source DNS faisant autorité, documentée. Responsabilité claire sur les identifiants, le registrar et la configuration de zone. Pas de zones orphelines ni de fournisseur mystère.

02

Discipline du changement

Les changements DNS sont intentionnels, journalisés et réversibles. TTL, enregistrements et dépendances revus avant changement. Pas de « quick fix » qui devient permanent par accident.

03

Conscience de la panne

Le DNS est conçu avec la panne en tête: pannes fournisseur, délais de propagation, erreurs de configuration. Chemins de reprise documentés, pas improvisés sous pression.

Responsabilités typiques § 3

Gestion de zone

Configuration de zone autoritative, cycle de vie des enregistrements et suppression des entrées obsolètes.

Suivi du registrar

Documentation des comptes registrar, procédures de transfert et continuité de propriété.

DNSSEC

Déploiement DNSSEC et gestion du cycle de vie quand c’est opérationnellement approprié.

Suivi des changements

Visibilité historique des changements DNS. Modifications journalisées avec contexte (TTL, types d’enregistrement, dépendances). Mémoire opérationnelle préservée.

Validation de la bascule

La bascule DNS est évaluée en tenant compte des délais de cache et de la persistance des résolveurs. Pas traitée comme une bascule instantanée.

Intégrité de délégation

Vérification de la délégation au registre, alignement des nameservers, glue records, cohérence entre fournisseurs.

Conçu pour être ennuyeux § 4

Un bon DNS doit être invisible. Si les changements DNS sont excitants, c’est déjà qu’il y a un problème.

Les zones restent simples. Les enregistrements existent pour une raison. Les décisions historiques sont documentées. Le DNS est revu périodiquement pour corriger la dérive, les enregistrements morts et les anciennes hypothèses devenues fausses.

Fournisseurs et redondance § 5

Le DNS est généralement exploité via un fournisseur géré reconnu comme Cloudflare, quand c’est approprié. Le choix du fournisseur est contextuel. Le contrôle opérationnel reste défini et documenté.

Pour des clients avec des exigences plus élevées de disponibilité, un DNS autoritatif secondaire peut être déployé sur une infrastructure indépendante. Les configurations secondaires peuvent reposer sur des transferts de zone contrôlés (AXFR/IXFR) ou sur des configurations synchronisées entre fournisseurs, selon l’environnement.

Les configurations multi-fournisseurs sont documentées et testées, pas supposées fonctionner par défaut.

Pas en libre-service § 6

Les changements DNS ne sont pas du support ad hoc. Ils sont effectués délibérément pour les systèmes gérés, avec revue, contexte et planification.

Les clients ne sont pas censés gérer le DNS directement, ni se rappeler des formats d’enregistrement, des conséquences des TTL ou du comportement de propagation. Ça évite les pannes accidentelles et préserve la cohérence long terme.

Où s’applique le DNS géré § 7

Le DNS géré est fourni dans le cadre d’une exploitation opérationnelle continue. Il n’est pas proposé en produit autonome, ni conçu pour l’expérimentation libre-service.

Le DNS sert des systèmes que j’exploite et comprends explicitement. Les environnements inconnus ou non gérés sont exclus par défaut.

Outils § 8

Les opérations DNS impliquent de maintenir la cohérence sur des systèmes distribués où le comportement dépend du cache, de la délégation et de l’état des résolveurs. Les problèmes peuvent inclure une propagation incohérente, des enregistrements obsolètes, une délégation cassée ou des incohérences entre serveurs autoritatifs.

Les changements sont évalués sur leur impact sur le comportement des résolveurs, l’expiration des TTL et les chaînes de dépendances, pas sur le résultat visible immédiat. Les pannes liées à DNSSEC, dont signatures invalides ou DS manquants, sont traitées avec attention aux chemins de validation et à la sécurité des retours arrière.

La vérification est faite en interrogeant directement les serveurs autoritatifs et les résolveurs, en observant comment les enregistrements sont renvoyés aux différents points de la résolution.

Les outils incluent dig, drill, et l’interaction contrôlée avec des systèmes autoritatifs comme BIND, NSD, PowerDNS ou des fournisseurs gérés comme Cloudflare.

Les outils sont utilisés pour observer et vérifier le comportement DNS tel qu’il existe en pratique, pas tel qu’il est censé se comporter en théorie.

FAQ § 9

Les clients peuvent-ils éditer les enregistrements DNS?

En général non. Les changements sont traités délibérément pour prévenir les pannes et maintenir la documentation.

Le DNS est-il hautement disponible?

La disponibilité dépend de la configuration du fournisseur et des choix de conception documentés. La redondance est délibérée et alignée sur les exigences de résilience.

L’enregistrement de domaine est-il inclus?

Les relations registrar peuvent être gérées, documentées et transférées si nécessaire.

Le DNS est-il supervisé?

Oui. La résolution, la santé autoritative et le comportement de propagation dans les chemins résolveurs connus sont supervisés dans le cadre du suivi opérationnel.

En pratique, ça signifie § 10

Les modifications DNS sont tracées avec leur contexte: quoi, quand, pourquoi.
Les accès registrar et la configuration des zones sont documentés. Pas de fournisseur mystère.
Les TTL et les délais de propagation sont anticipés, pas découverts pendant les incidents.
Quand quelque chose casse, les chemins de reprise existent et ont été réfléchis à l’avance.

Pour aller plus loin § 11

Le DNS soutient la supervision, la réponse aux incidents, l’authentification, la livraison e-mail et la reprise. Les responsabilités et attentes sont définies par phase de mission, comme décrit dans le cycle d’une mission.

Discuter de votre infrastructure → Exploitation opérationnelle

Opérations DNS gérées pour infrastructure Linux