Résumé

  • La RFC 7646 permet à l’opérateur d’un résolveur d’interrompre la validation DNSSEC sur une branche déterminée, après qu’un personnel qualifié a établi qu’il s’agit d’une mauvaise configuration et non d’une attaque.
  • Cette dérogation est locale, provisoire et limitée : les réponses concernées sont traitées comme si la zone n’était pas signée, ne reçoivent pas le bit AD et doivent revenir sous validation dès que la zone fonctionne de nouveau.

Analyse

DNSSEC donne au résolveur récursif une responsabilité qui dépasse la simple recherche d’une réponse. Un résolveur validant tente de relier les données signées à au moins une ancre de confiance qu’il connaît. Il classe ensuite le résultat comme sécurisé, non sécurisé, erroné ou indéterminé. Des données authentifiées peuvent être signalées par le bit AD. À l’inverse, des données jugées erronées conduisent normalement à un échec pour un client qui ne réalise pas lui-même la validation.

Cette discipline protège l’intégrité et l’origine des données DNS ; elle n’assure pas leur confidentialité. Elle crée aussi un point d’application concret. Lorsqu’une zone est correctement signée, le résolveur fournit une assurance utile. Lorsqu’une signature a expiré, qu’une délégation est incohérente ou qu’un autre défaut rompt la chaîne, le même résolveur refuse de transmettre une réponse exploitable. Le propriétaire de la zone reste responsable de la correction, mais l’indisponibilité apparaît chez les utilisateurs du résolveur.

La RFC 7646 encadre une réponse exceptionnelle à cette tension. Une ancre de confiance négative, ou NTA, demande au résolveur de cesser la validation DNSSEC à partir d’un nom choisi. Dans cette branche, il traite les réponses comme celles d’une zone non signée et ne positionne pas le bit AD. La zone d’origine n’est ni réparée ni modifiée. Le résolveur adopte une politique locale qui retire temporairement une assurance qu’il appliquerait ailleurs.

La portée administrative est déterminante. Une NTA ne publie pas une autre vérité dans le DNS et ne doit pas être propagée hors de l’organisation qui en a besoin. Deux résolveurs peuvent donc se comporter différemment devant la même rupture : l’un continue à renvoyer un échec, l’autre accepte des données non authentifiées dans la branche couverte par son exception. Ce contraste découle du contrôle local, pas d’un changement de la zone.

La RFC exclut l’automatisme. Avant d’activer une NTA, des techniciens formés doivent confirmer que l’échec résulte d’une mauvaise configuration plutôt que d’une attaque. Ils doivent également vérifier que le domaine n’est pas volontairement défaillant et devraient tenter raisonnablement de contacter son propriétaire. Une alarme de disponibilité ou un code d’erreur ne suffit donc pas à autoriser la mesure.

La cause reste une frontière de connaissance. Les sources décrivent le mécanisme et ses conditions, mais elles ne prouvent pas qu’un incident particulier est accidentel. Elles n’établissent pas non plus qu’un opérateur nommé utilise actuellement des NTA, ni à quelle fréquence, ni avec quel gain mesuré. Ces éléments demeurent inconnus tant que l’opérateur ne fournit pas ses propres observations. Affirmer qu’une NTA peut répondre à une mauvaise configuration confirmée est un fait normatif ; déclarer qu’elle convient à une panne précise est un jugement séparé.

Le nom couvert constitue le deuxième garde-fou. L’exception doit viser le domaine ou sous-domaine précis qui présente le défaut. Elle ne doit pas désactiver la validation pour un parent ou pour des branches sans rapport. Une portée trop haute dans l’arbre accepterait davantage de données sans authentification, alors que les preuves ne concernent qu’un périmètre plus réduit.

La durée forme le troisième garde-fou. La NTA doit comporter une échéance et expirer automatiquement. La RFC indique qu’elle ne devrait pas être conservée plus d’une semaine. Pendant sa validité, l’implémentation devrait retenter périodiquement la validation et supprimer l’exception dès qu’une validation réussit. Cette suppression devrait aussi vider les entrées de cache situées au niveau du nom concerné et en dessous, afin que les réponses acceptées pendant la dérogation ne survivent pas à son retrait.

L’arbitrage ne se réduit donc pas à une opposition générale entre sécurité et disponibilité. Les utilisateurs et les responsables du service peuvent retrouver l’accès à une branche défaillante. En contrepartie, ils perdent l’assurance DNSSEC fournie par le résolveur pour cette branche pendant la fenêtre d’exception. Les zones correctement exploitées ailleurs doivent rester validées. Il s’agit d’un échange circonscrit, dont l’effet réel ne peut être chiffré sans données sur le trafic, les dépendances et l’incident.

La transparence complète ce dispositif. La RFC 7646 recommande de publier les NTA présentes et passées, avec leurs heures d’activation et de retrait. Au moment de sa rédaction, aucun code de réponse DNS spécifique ne signalait directement l’usage d’une telle exception. L’absence du bit AD indique seulement qu’une assurance d’authentification n’est pas fournie ; elle n’explique pas à elle seule la politique appliquée.

Les erreurs DNS étendues, définies ultérieurement par la RFC 8914, offrent des indications comme « DNSSEC Indeterminate » ou « DNSSEC Bogus ». Elles améliorent le diagnostic, mais ne modifient pas le traitement du protocole. Elles ne sont pas authentifiées lorsque la transaction DNS qui les transporte ne l’est pas. Un code EDE peut donc orienter une enquête ; il ne constitue ni une preuve suffisante de mauvaise configuration ni une autorisation d’abandonner la validation.

Le scénario contraire comporte lui aussi un coût. Refuser une NTA maintient la politique de validation, mais peut prolonger l’indisponibilité de la branche signée défaillante. Désactiver DNSSEC plus largement, ou déplacer les utilisateurs vers un résolveur qui ne valide pas, peut rétablir davantage d’accès au prix d’une perte d’assurance bien plus étendue. La NTA étroite occupe une position intermédiaire : elle contient l’exception sans transférer au résolveur la responsabilité de réparer la zone.

Le registre de décision devient ainsi une partie du contrôle. La RFC ne fixe pas une chaîne d’approbation universelle, mais ses exigences permettent de déduire les éléments d’une trace défendable : identité de l’approbateur, preuves orientant vers une mauvaise configuration, nom exact couvert, activation, échéance, contact du propriétaire, essais de revalidation, retrait final et purge des caches. Il s’agit d’une discipline opérationnelle tirée du mécanisme, non d’une procédure organisationnelle prescrite mot pour mot par les RFC.

Aucune accusation contre un opérateur ou un domaine n’est nécessaire. Le risque provient du pouvoir même de l’outil : il rend un service accessible sans corriger sa zone signée. Ce pouvoir peut protéger la continuité, mais il peut aussi exposer les utilisateurs si le diagnostic est faux ou si l’exception temporaire se banalise. Une NTA défendable doit donc rester une exception d’authenticité nominative, documentée, limitée dans le temps, automatiquement révoquée et effectivement retirée.

Sources