Modifications DNS par des agents IA : rendre les révisions plus sûres

Les modifications DNS effectuées par des agents de programmation IA doivent suivre une structure plus stricte que les modifications ordinaires de l'infrastructure. Un agent ne devrait jamais présenter « mettre à jour le DNS » comme une seule approbation. Il devrait présenter séparément une création, une modification ou une suppression, avec des éléments justificatifs différents, des questions de révision différentes et une gestion des erreurs adaptée à chaque cas.

Cette séparation peut sembler bureaucratique jusqu'au jour où un agent remplace un enregistrement de messagerie, ajoute un CNAME à côté de données incompatibles ou supprime le dernier enregistrement d'adresse pendant une migration. Les petites modifications textuelles du DNS paraissent anodines. Pourtant, leurs effets se propagent aux résolveurs, aux clients, aux zones déléguées, aux contrôles de certificats, à la distribution des e-mails et à la découverte des services. Un réviseur doit voir le verbe exact avant de pouvoir évaluer l'ampleur des conséquences.

Les verbes DNS portent des risques différents

La création d'un enregistrement DNS introduit une nouvelle assertion dans une zone. Le réviseur doit se demander à qui appartient le nom, si la cible est correcte, si les nouvelles données entrent en conflit avec les données existantes et si quelqu'un pourrait exploiter l'enregistrement pour valider le domaine ou détourner le trafic.

La modification d'un enregistrement change une assertion existante. Cette action doit afficher côte à côte l'ancienne et la nouvelle valeur. Remplacer une adresse par une autre peut déplacer le trafic de l'application. Modifier un enregistrement TXT peut changer l'authentification de l'expéditeur, la vérification de propriété ou une configuration consommée par un service externe. L'ancien état permet au réviseur de distinguer un remplacement délibéré d'une action fondée sur des informations obsolètes.

La suppression d'un enregistrement affirme que son absence est désormais correcte. C'est l'opération dont la plage d'échec est la plus large, car le résultat sûr dépend souvent d'éléments extérieurs au DNS. Le nouveau point de terminaison a peut-être besoin de temps pour recevoir du trafic. Une autre équipe utilise peut-être encore un enregistrement TXT de vérification. L'enregistrement fait peut-être partie d'un mécanisme de basculement que l'agent ne peut pas déduire d'un dépôt.

Traiter ces opérations comme une seule écriture générique provoque une cécité lors des approbations. Le réviseur constate que toutes les cartes portent le même intitulé, clique pour avancer et découvre trop tard qu'une carte a supprimé tout un RRset. Le contrôle doit rendre cette différence dangereuse impossible à manquer.

La terminologie DNS demande également de la précision. Un nom propriétaire DNS peut contenir un RRset, c'est-à-dire un ensemble d'enregistrements portant le même nom et le même type. De nombreuses API de fournisseurs exposent un objet « record » unique, mais leur comportement de mise à jour peut remplacer le RRset complet. Si un agent veut retirer l'une de deux valeurs A et que le fournisseur remplace l'ensemble, il peut supprimer les deux par accident. Examinez le modèle réel des objets du fournisseur avant de définir la portée d'une action.

Chaque demande doit déclarer un verbe irréversible

Une action DNS doit contenir un seul verbe : create, edit ou delete. N'acceptez pas, au niveau de l'approbation, une méthode vague appelée apply, sync ou upsert. Ces noms sont pratiques pour un programmeur et coûteux pour un opérateur.

La demande doit également préciser si elle concerne un objet d'enregistrement du fournisseur ou un RRset entier. Si l'API ne permet pas de modifier sans risque un membre individuel, l'action doit indiquer qu'elle remplacera tout le RRset et énumérer chaque valeur conservée. Le silence sur ce point transforme une modification apparemment mineure d'une adresse en panne.

Utilisez une structure de demande qui conserve l'intention et donne à l'exécuteur assez d'état pour détecter une dérive :

{
  "action": "edit",
  "zone": "example.net",
  "owner": "api.example.net.",
  "type": "A",
  "expected_rrset": {
    "ttl": 300,
    "values": ["198.51.100.24"]
  },
  "proposed_rrset": {
    "ttl": 300,
    "values": ["198.51.100.81"]
  },
  "reason": "Move the API endpoint after the service owner confirmed health checks",
  "verification": [
    "authoritative lookup returns 198.51.100.81",
    "HTTPS health check succeeds at the new endpoint"
  ]
}

Pour une action de création, expected_rrset doit indiquer que le RRset est absent, ou préciser un état existant autorisé lorsque le modèle du fournisseur l'exige. Pour une suppression, proposed_rrset doit indiquer explicitement l'absence. N'encodez pas l'absence sous la forme d'une chaîne vide et n'omettez pas le champ. Les charges utiles ambiguës produisent des journaux ambigus.

L'exécuteur doit lire l'état actuel de la zone immédiatement avant l'écriture. Il doit comparer cette observation à expected_rrset et s'arrêter en cas de différence. C'est une discipline de comparaison et d'échange, même si le fournisseur DNS ne propose pas de point de terminaison dédié à cette opération.

La RFC 2136, consacrée aux mises à jour dynamiques du système de noms de domaine, inscrit directement cette idée dans le protocole. Sa section sur les prérequis permet au client d'indiquer les RRsets qui doivent exister ou ne pas exister avant que le serveur accepte une mise à jour. La plupart des API DNS hébergées n'exposent pas les messages filaires RFC 2136, mais la leçon opérationnelle reste valable : une écriture fondée sur une lecture antérieure non vérifiée est dangereuse.

Un agent peut réessayer une lecture. Il ne doit pas réessayer une écriture échouée en remplaçant l'état attendu par ce qu'il vient d'observer. Une différence signifie qu'un autre acteur a modifié le DNS, que le plan de l'agent est obsolète ou que le fournisseur a normalisé les données d'une manière imprévue par le planificateur. Cette situation doit être transmise à un réviseur humain.

Une création nécessite des preuves de propriété et d'absence de conflit

Un nouvel enregistrement doit être associé à des éléments prouvant que le nom appartient au service prévu avant toute approbation. Un chemin de dépôt, une référence de ticket ou une demande en langage naturel peuvent suggérer cette propriété, mais aucun de ces éléments ne prouve qu'un nouveau nom public peut être utilisé librement.

L'agent doit examiner le nom propriétaire exact pour tous les types d'enregistrement avant de proposer une création. C'est particulièrement important pour les enregistrements CNAME. La RFC 1034 indique que lorsqu'un RR CNAME est présent sur un nœud, aucune autre donnée ne devrait y être présente. Un planificateur qui recherche uniquement un CNAME existant peut proposer un CNAME à un nom qui contient déjà des données d'adresse, de messagerie ou TXT. Le fournisseur peut refuser l'écriture ou, pire, remplacer les données selon une règle qui lui est propre.

La révision d'une création doit présenter clairement quatre éléments :

• Le nom propriétaire pleinement qualifié, la zone, le type d'enregistrement, la valeur et le TTL.
• Les enregistrements actuels portant le même nom propriétaire, y compris les types que l'agent ne modifiera pas.
• La personne qui a demandé le nom et le service qui le consommera.
• La vérification de la cible adaptée au type d'enregistrement.

Les vérifications dépendent des données. Pour un enregistrement A ou AAAA, l'agent peut confirmer que l'adresse appartient à l'inventaire de déploiement attendu, s'il en existe un. Pour un CNAME, il doit résoudre la cible et vérifier que le nom est complet. Pour un enregistrement MX, il doit confirmer le nom d'hôte et la priorité avec le responsable de la messagerie. Pour un TXT utilisé par un vérificateur externe, il doit conserver exactement la valeur fournie au lieu de « nettoyer » les espaces ou les guillemets en se fondant sur des suppositions.

Ne laissez pas un agent déduire qu'un sous-domaine nouvellement demandé est sans risque parce qu'il se trouve sous un domaine familier. login, auth, mta, vpn et admin ont des conséquences évidentes, mais des noms quelconques peuvent aussi compter. Un nom DNS public devient une interface dès que quelqu'un en dépend.

Une création diffère aussi d'un déploiement, car le retour arrière ne signifie pas forcément une suppression. Si un nouvel enregistrement prend en charge un processus de vérification, sa suppression une fois le processus terminé peut interrompre le renouvellement ou une validation ultérieure. La proposition doit préciser si l'enregistrement est temporaire, qui décidera de son expiration et si le demandeur accepte sa suppression ultérieure. Si personne ne peut répondre, n'inventez pas de date d'expiration.

Une modification doit nommer l'état qu'elle remplace

Une modification n'est sûre que si la proposition identifie précisément l'état qu'elle va remplacer. « Diriger l'application vers le nouvel hôte » exprime une intention, pas une action DNS exécutable.

Exigez l'ancien RRset dans chaque demande de modification, y compris les valeurs que l'agent prévoit de conserver. Prenons un RRset A avec deux adresses :

Current:  app.example.net. 60 IN A 198.51.100.10
          app.example.net. 60 IN A 198.51.100.11
Proposed: app.example.net. 60 IN A 198.51.100.11
          app.example.net. 60 IN A 198.51.100.12

Il s'agit d'une rotation contrôlée. Le réviseur voit qu'une adresse de service est conservée tandis qu'une autre est remplacée. Si le fournisseur remplace les RRsets comme une seule unité, envoyer uniquement 198.51.100.12 serait une suppression suivie d'une création déguisée en modification.

Les modifications de TTL doivent figurer sur la même carte de révision. Les équipes réduisent souvent le TTL avant une migration, puis l'augmentent après celle-ci. Les deux changements ont des conséquences. Un TTL plus bas augmente la fréquence des requêtes des résolveurs et peut exposer plus vite les erreurs de configuration. Un TTL plus élevé peut maintenir le trafic sur le mauvais point de terminaison plus longtemps après une mauvaise modification. Aucun de ces changements ne doit disparaître dans une mise à jour générique d'enregistrement.

Un agent doit aussi distinguer les modifications de données des différences de format. Les fournisseurs peuvent normaliser les noms propriétaires, ajouter un point final, découper les chaînes TXT ou réordonner les valeurs. Un planificateur qui compare le texte brut de l'API produira des cartes d'approbation inutiles ou de faux conflits. Normalisez la représentation avant la comparaison, mais préservez les données sémantiques dont le réviseur a besoin.

N'approuvez pas une modification simplement parce qu'un agent a trouvé une chaîne correspondante dans le contrôle de version. Le contrôle de version peut contenir un état souhaité qui n'est plus pertinent après une modification DNS d'urgence. L'état actuel faisant autorité reste la condition de l'écriture. Les dépôts expliquent l'intention ; le DNS indique ce que les clients peuvent recevoir.

Une suppression doit expliquer pourquoi l'absence est correcte

Une suppression doit expliquer pourquoi l'enregistrement peut disparaître maintenant, et pas seulement pourquoi l'agent le juge inutile. Les anciens enregistrements semblent souvent redondants jusqu'à ce que quelqu'un découvre qu'ils prennent en charge un ancien callback, un système de messagerie, un validateur de certificat ou un service délégué.

La méthode sûre sépare le déplacement du trafic du nettoyage. Ajoutez ou modifiez d'abord les nouvelles données. Vérifiez ensuite la réponse attendue du serveur faisant autorité et le service dépendant. Ce n'est qu'après l'acceptation du nouveau comportement par le responsable que l'agent doit demander la suppression des anciennes données. Gardez la demande de suppression distincte, même si le fournisseur pourrait la combiner avec la modification.

Une demande de suppression doit inclure les éléments suivants :

• Le RRset ou l'objet d'enregistrement exact à supprimer.
• Le service ou l'équipe qui a confirmé ne plus dépendre des données.
• L'action de remplacement, s'il y en a une, et le résultat de sa vérification.
• La vérification prévue après la suppression.
• Une indication précisant si la suppression modifie un RRset entier.

Les enregistrements à l'apex méritent une vigilance particulière. Le comportement de l'apex de zone varie selon les fournisseurs, notamment lorsqu'ils proposent des alias ou des enregistrements synthétiques qui imitent le comportement d'un CNAME. Un agent ne doit jamais transformer un CNAME souhaité en fonctionnalité d'apex propre au fournisseur sans l'intervention d'un réviseur qui comprend sa sémantique. Un mot DNS familier ne garantit pas un comportement DNS familier.

Le cache négatif complique la restauration après une suppression. La RFC 2308 décrit la manière dont les résolveurs peuvent mettre en cache des réponses négatives, notamment NXDOMAIN et les réponses indiquant l'absence de données. Si vous supprimez un enregistrement puis le restaurez, certains clients peuvent continuer à voir cette absence jusqu'à l'expiration de leur cache négatif. Cela ne signifie pas qu'une suppression est interdite. Cela signifie que le plan de retour arrière doit tenir compte de la période pendant laquelle le DNS faisant autorité est corrigé, mais où les utilisateurs reçoivent encore une erreur mise en cache.

Une action de suppression ne doit pas s'élargir silencieusement lorsque le fournisseur refuse de supprimer une valeur individuelle. L'exécuteur doit signaler que le fournisseur exige le remplacement d'un RRset entier et demander une nouvelle action explicite. Cette approbation supplémentaire coûte moins cher que d'expliquer pourquoi un enregistrement d'adresse supposé inutilisé a disparu.

Les cartes de révision ont besoin de plus qu'une comparaison de zone

Une comparaison brute fournit des données aux réviseurs, mais elle cache souvent la conséquence. Les cartes doivent commencer par une phrase courte qui nomme l'opération et le comportement attendu : « Supprimer l'enregistrement TXT de vérification obsolète pour verify.example.net ; le demandeur a confirmé que la vérification externe est terminée. » Affichez ensuite les enregistrements exacts.

La carte doit rendre visibles sans ouvrir une autre vue les champs suivants : verbe d'action, zone, nom propriétaire, type, ancien état, état proposé, TTL, demandeur, identité du processus de l'agent, raison et plan de vérification. Si l'écriture peut affecter un RRset entier, dites-le dès la première ligne.

Utilisez une formulation directe. « Remplacer les deux valeurs A » vaut mieux que « réconcilier l'ensemble d'enregistrements ». « Supprimer cet enregistrement MX » vaut mieux que « appliquer la configuration souhaitée ». Les réviseurs prennent des décisions plus rapidement lorsque le système emploie des verbes opérationnels plutôt que des abstractions.

Une carte utile donne aussi au réviseur une raison de refuser l'action. Pour une création CNAME, affichez les données en conflit au même nom propriétaire. Pour une modification, indiquez si l'état actuel diffère de l'état attendu. Pour une suppression, précisez lorsque l'agent ne dispose pas de la confirmation du responsable du service. L'interface d'approbation doit montrer l'incertitude au lieu de l'enfouir dans un journal d'exécution.

Ne transformez pas les réviseurs en moteur de règles manuel en leur fournissant une grande zone de texte destinée aux exceptions. Si l'agent demande une action qui ne respecte pas la structure normale, exigez qu'il prépare une nouvelle action avec les éléments manquants. Un réviseur qui doit reconstituer la sémantique DNS à partir d'une conversation finira par approuver une erreur.

Exemple de révision détaillé

Supposons qu'un agent doive déplacer api.example.net vers une adresse de remplacement. Une mauvaise carte indique : « Mettre à jour le DNS de l'API. » Elle ne permet pas au réviseur de voir que le fournisseur remplacera un RRset composé de deux membres.

Une modification révisable indique : « Remplacer 198.51.100.24 par 198.51.100.81 dans le RRset A de api.example.net ; conserver 198.51.100.25 ; garder le TTL à 300. » Elle affiche ensuite les RRsets complets, actuel et proposé, nomme le responsable du service et précise que l'agent interrogera le serveur de noms faisant autorité et exécutera le contrôle de santé approuvé après l'écriture.

Si le réviseur souhaite au contraire une bascule sans chevauchement, il doit refuser cette carte et demander explicitement cette intention. L'agent ne doit pas décider que le chevauchement est inutile parce que ses fichiers de déploiement contiennent une nouvelle adresse.

Les caches DNS font du calendrier un élément de l'approbation

Le DNS faisant autorité et le DNS récursif répondent à des questions opérationnelles différentes. Le serveur faisant autorité indique les données actuellement publiées dans la zone. Un résolveur récursif peut renvoyer une réponse antérieure jusqu'à l'expiration du TTL reçu. Un navigateur, un système d'exploitation, un environnement d'exécution, un répartiteur de charge ou un résolveur interne peut ajouter un autre cache.

L'approbation doit donc nommer le point de vérification souhaité. « Les serveurs faisant autorité renvoient la nouvelle réponse » vérifie l'écriture. « Un résolveur public renvoie la nouvelle réponse » vérifie une partie de la propagation. « L'application sert le trafic à la nouvelle destination » vérifie le résultat attendu par les utilisateurs. Ce sont des contrôles distincts.

Utilisez des commandes qui rendent visible la source de la réponse. Remplacez le nom et l'adresse par le serveur faisant autorité réel de la zone :

dig @ns1.example.net api.example.net A +noall +answer

; expected answer shape
api.example.net. 300 IN A 198.51.100.81

dig @1.1.1.1 api.example.net A +noall +answer

; resolver answer can retain an older value with a lower remaining TTL
api.example.net. 117 IN A 198.51.100.24

La première requête vérifie l'état publié auprès d'un serveur faisant autorité. La seconde vérifie ce qu'un résolveur récursif renvoie actuellement. Aucune des deux ne prouve que tous les clients ont basculé. Enregistrez les deux résultats dans le journal de l'action afin qu'une personne intervenant lors d'un incident puisse distinguer une écriture échouée chez le fournisseur d'un comportement attendu du cache.

Ne considérez pas un TTL comme un compte à rebours vers une cohérence mondiale. Un résolveur reçoit un TTL lorsqu'il met une réponse en cache, et différents résolveurs commencent donc leur compte à rebours à des moments différents. Certains clients peuvent aussi conserver des connexions ou mettre en cache la configuration de l'application indépendamment du DNS. Un plan de migration a besoin d'une vérification au niveau du service, pas de la promesse que quelques secondes se sont écoulées.

Les modifications de délégation DNS demandent encore plus de précautions. Modifier les enregistrements NS, glue, DS ou d'autres données liées à la délégation peut affecter la résolution au-delà de la zone enfant. Un agent doit classer ces opérations dans une catégorie distincte et exiger un réviseur responsable de la relation entre parent et enfant. Ne les intégrez pas à un processus ordinaire de modification d'hôte.

Les identifiants DNS étendus sont un mauvais raccourci

Donner à un agent un identifiant de fournisseur capable de modifier toutes les zones semble efficace, car l'agent peut terminer sa tâche sans attendre une modification de l'intégration. C'est pourtant une mauvaise limite. Une injection de prompt, une instruction erronée dans un dépôt ou un plan confus disposerait alors d'une autorité très supérieure au service que l'agent devait modifier.

Limitez chaque chemin d'exécution aux zones et aux opérations nécessaires. Séparez l'accès en lecture de l'accès en écriture lorsque le fournisseur le permet. Conservez une correspondance entre l'identité d'un dépôt ou d'un service et les zones qu'elle peut demander. Refusez toute demande qui nomme une zone absente de cette correspondance avant qu'elle n'atteigne les identifiants du fournisseur.

La limite doit contraindre les actions, et pas seulement masquer un jeton. Un agent qui peut demander à un intermédiaire d'envoyer des requêtes arbitraires à l'API du fournisseur dispose toujours d'un contrôle étendu si cet intermédiaire accepte des chemins, méthodes, en-têtes et corps de requête quelconques. La couche d'action doit contrôler la forme de l'appel DNS au fournisseur et refuser les champs qui ne figurent pas dans son schéma.

C'est là que les points de terminaison génériques upsert posent problème. Ils permettent à un agent de réunir création, modification et suppression dans un seul corps de requête, souvent avec des valeurs par défaut du fournisseur que le réviseur ne peut pas voir. Définissez des méthodes d'exécution distinctes et faites valider par chaque méthode les éléments requis par l'action. Une méthode de suppression doit refuser une charge utile contenant un état de remplacement. Une méthode de modification doit refuser l'absence de l'état attendu.

Gardez les identifiants DNS hors du processus de l'agent. Pour les équipes qui utilisent Sallyport, l'application peut effectuer l'appel HTTP tandis que les identifiants restent dans son coffre chiffré. L'agent reçoit ainsi le résultat plutôt que l'identifiant. Cela limite l'exposition des identifiants, mais ne détermine pas si l'action DNS proposée est pertinente ; ce sont le schéma de l'action et les éléments de l'approbation qui remplissent ce rôle.

Un plan obsolète peut supprimer le mauvais enregistrement actif

Un échec courant commence lorsqu'un agent lit le DNS au début d'une longue tâche de programmation. Il voit cdn.example.net avec une cible CNAME et prévoit de la remplacer après un déploiement. Pendant ce temps, un ingénieur d'astreinte modifie la cible afin de détourner le trafic lors d'un incident.

L'agent termine plus tard et envoie l'ancienne demande de remplacement. Si son appel au fournisseur utilise une mise à jour générique ou une séquence inconditionnelle de suppression puis de création, il écrase la modification de l'astreinte. La demande peut sembler correcte par rapport à l'état observé plusieurs heures auparavant. Elle est erronée par rapport à la zone active.

Une lecture récente avant l'écriture empêche précisément cette erreur. L'exécuteur lit le RRset, le compare à expected_rrset et refuse l'écriture lorsque la cible de l'astreinte diffère. Le refus doit conserver les deux valeurs dans le journal et indiquer au réviseur qu'un autre acteur a modifié l'enregistrement. Il ne doit pas tenter de fusion.

Fusionner des données DNS nécessite de connaître le service. Deux valeurs d'adresse peuvent représenter une capacité intentionnelle, un chevauchement temporaire, une répartition géographique ou une route d'urgence. Un agent ne peut pas déduire laquelle s'applique simplement parce qu'il ne reconnaît qu'une seule adresse dans un fichier de déploiement.

La même règle s'applique après une défaillance partielle. Si un fournisseur signale une expiration de délai, l'exécuteur doit lire l'état faisant autorité du fournisseur avant de réessayer. L'écriture peut avoir réussi alors que le client n'a jamais reçu la réponse. Des réessais aveugles créent des valeurs en double sur certaines API et un remplacement indésirable sur d'autres.

Les journaux doivent conserver ce que le réviseur a réellement approuvé

Un enregistrement d'audit DNS doit contenir davantage qu'un événement du fournisseur indiquant qu'un enregistrement a changé. Conservez l'action proposée, l'état observé avant l'exécution, la décision d'approbation, le processus qui l'a demandée, la réponse du fournisseur et les résultats des vérifications. Gardez suffisamment de données pour reconstituer la conformité de l'exécuteur à la demande approuvée.

Un journal infalsifiable offre une propriété utile : la personne qui enquête sur un incident peut vérifier si l'historique a changé après coup. C'est important lorsque les réponses DNS ont déjà disparu des caches et que les équipes commencent à se fier à leur mémoire ou à des captures d'écran. Les éléments de preuve doivent rester compréhensibles sans la conversation originale avec l'agent.

Séparez l'enregistrement de session de l'enregistrement d'appel. L'enregistrement de session indique quel processus d'agent a reçu l'autorité et quand celle-ci a pris fin. L'enregistrement d'appel indique quelle action DNS exacte il a demandée, si quelqu'un l'a approuvée et ce qui s'est passé. La révocation instantanée d'une session doit empêcher les appels ultérieurs, mais elle ne peut pas annuler une écriture DNS déjà acceptée par le fournisseur. La trace d'audit doit rendre cette limite explicite.

Utilisez les identifiants d'action dans la carte d'approbation et dans l'enregistrement d'exécution. Lorsqu'un opérateur voit un mauvais résultat, il doit pouvoir retrouver la suppression ou la modification approuvée sans parcourir un flux indistinct de sorties d'agent. L'identifiant doit relier la demande, la comparaison d'état, la réponse du fournisseur et les commandes de vérification.

La première modification concrète est simple : interdisez les écritures DNS génériques au niveau de l'approbation. Forcez chaque demande à prendre la forme d'une création, d'une modification ou d'une suppression, exigez le RRset attendu complet pour les modifications et les suppressions, et refusez toute dérive avant l'exécution. Cette seule contrainte rend le travail DNS proposé par un agent suffisamment lisible pour qu'une personne puisse repérer les erreurs importantes.