Résumé

  • Dans DNS, le bit Authoritative Answer se rapporte au nom demandé ou au premier nom propriétaire de la section Answer ; une cible d’alias, les données d’Authority, la glue et les RRsets d’Additional peuvent avoir une autre provenance.
  • Un reçu défendable conserve, RRset par RRset, propriétaire, type, section, coupure de zone, source de cache et état DNSSEC, ainsi que les requêtes suivantes, au lieu d’étendre un bit d’en-tête à tout le paquet.

Un résolveur demande l’adresse de boutique.example. Le serveur consulté fait autorité pour ce nom et renvoie un CNAME. Dans la même section Answer, une adresse de la cible provient de son cache ; dans Additional, une autre adresse aide à poursuivre la résolution. AA vaut 1.

Un entrepôt de données ne garde pourtant qu’une ligne : trois RRsets, « autoritatif : vrai ». Lorsque l’adresse de la cible contredit plus tard une réponse directe de sa propre zone, l’historique est muet. Le paquet était cohérent ; c’est la réduction de trois provenances à un seul adjectif qui ne l’était pas.

Cet exemple est construit pour tester le modèle de preuve. Il ne décrit ni attaque ni panne réelle.

Un bit répond à une question précise

Dans le RFC 1035, Paul Mockapetris définit AA comme un bit valable dans les réponses. Il indique que le serveur répondant fait autorité pour le nom de domaine de la section Question. Le texte prévoit aussitôt le cas où Answer contient plusieurs propriétaires à cause d’alias : AA correspond au nom qui coïncide avec le nom demandé, ou au premier propriétaire de la réponse.

La portée est donc étroite sans être faible. AA ne constitue pas un tableau de bits apposé à chaque RRset. Il situe l’autorité du serveur au début du chemin de réponse. Déduire que tous les noms et toutes les sections partagent cette autorité ajoute une affirmation que le fil DNS ne transporte pas.

Le RFC 1034 permet de voir comment les origines se mélangent. Lorsqu’un nœud autoritatif contient un CNAME, le serveur copie cet RR dans Answer, remplace QNAME par le nom canonique puis reprend le traitement. À une délégation, il place les NS dans Authority et les adresses disponibles dans Additional, qu’elles viennent de glue, de données autoritatives ou du cache. À la fin, il peut encore ajouter des RR locaux jugés utiles.

Une réponse unique n’est donc pas forcément une preuve unique. Sa compacité est une fonction du protocole, pas une autorisation à effacer son itinéraire.

Les sections organisent, elles ne certifient pas

Le RFC 1035 distingue Answer, qui répond à la question, Authority, qui oriente vers une autorité, et Additional, qui fournit des informations connexes sans être strictement la réponse. Conserver cette section dans les journaux est indispensable. Mais elle ne suffit pas à elle seule.

Lors d’une délégation, une adresse de serveur enfant peut être fournie comme glue par la zone parente. Elle résout un problème circulaire de joignabilité et peut être nécessaire au prochain saut. Elle n’est pas pour autant une déclaration de la zone enfant, ni la preuve que le parent fait autorité sous la coupure de zone.

Le RFC 2181 classe expressément les sources. Les données d’un fichier de zone ou d’un transfert, hors glue, précèdent les données autoritatives d’Answer ; viennent ensuite Authority, glue, réponses non autoritatives et Additional. Une réponse autoritative fraîche peut remplacer en cache un RRset auparavant appris comme information additionnelle. L’inverse ne doit pas se produire sans raison.

Cette hiérarchie empêche le cache de blanchir la provenance. Si l’on oublie qu’une adresse a été reçue en Additional, sa restitution ultérieure dans Answer lui donne visuellement un grade qu’elle n’a jamais acquis. Le TTL a pu diminuer ; l’autorité, elle, n’a pas augmenté avec le temps passé en mémoire.

L’alias révèle le changement de juridiction

Le cas de l’alias est encore plus net. Le RFC 2181 précise que, dans une réponse autoritative à propos d’un alias, seul le RR décrivant cet alias est nécessairement autoritatif. Les autres enregistrements peuvent venir du cache. Si le client exige une source autoritative pour le nom canonique, il doit l’interroger à nouveau.

Le RFC 6604 reformule la règle pour les chaînes CNAME et DNAME : chaque réponse de la chaîne peut avoir un statut d’autorité différent. AA continue de dépendre du premier propriétaire dans Answer.

Ainsi, un serveur autoritatif pour boutique.example peut légitimement signaler que ce nom est un alias de service.fournisseur.test. Une adresse en cache pour la cible peut accélérer la réponse. Elle ne devient pas une adresse autoritative de la zone du fournisseur. Le saut suivant est une nouvelle requête, avec un autre serveur, un autre périmètre et un autre reçu.

Le journal devrait donc modéliser une chaîne : nom d’entrée, RR CNAME ou DNAME, zone qui l’a servi, réponse source, nom suivant, requête suivante. La réduire à l’adresse finale sert peut-être un cache applicatif ; elle ne permet plus d’attribuer chaque assertion.

Autorité et authenticité ne sont pas synonymes

AA ne signe rien. Le RFC 6604 dit explicitement que ce bit d’en-tête n’est pas protégé par DNSSEC. TSIG ou SIG(0) peuvent sécuriser une transaction avec un serveur, tandis que la validation DNSSEC des RRsets suit sa propre chaîne de preuves.

Le RFC 4035 impose au résolveur de déterminer un état par RRset : Secure lorsqu’une chaîne remonte à une ancre de confiance, Insecure lorsque l’absence de chaîne est établie, Bogus lorsque la preuve attendue échoue, Indeterminate lorsque les éléments manquent. Aucun de ces états n’est produit par AA.

Le bit AD répond à une autre condition : un serveur conscient de DNSSEC ne doit le poser que s’il considère authentiques les RRsets concernés d’Answer et d’Authority. Même alors, un client doit savoir s’il fait confiance au résolveur récursif et au canal qui le relie à lui. Un AD reçu reste une assertion amont tant que la validation locale et la confiance de transport ne sont pas documentées. Additional n’est pas couvert par le raccourci annoncé.

Un même message peut donc porter des vérités compatibles : AA correct pour le premier propriétaire, CNAME Secure, cible Insecure, glue en Additional et canal non authentifié. Le badge vert unique ne simplifie pas ces faits ; il les détruit.

Ce que le nom de Mockapetris établit

La biographie de l’Internet Hall of Fame crédite Paul Mockapetris de l’invention de DNS en 1983 à l’Information Sciences Institute de l’USC. Les RFC 1034 et 1035 attestent son rôle d’auteur. Le portrait public historique de cette page fonde également l’identité de l’illustration éditoriale.

Ces sources ne font pas de lui l’opérateur actuel d’un serveur, le propriétaire d’une zone ou l’autorité d’un déploiement moderne. Les clarifications ultérieures sont des travaux collectifs de normalisation. Leur intérêt est de rendre observable la retenue déjà présente dans le dessin initial : distribuer l’autorité oblige à conserver les frontières entre les étapes d’une réponse.

Un reçu par RRset

Le reçu commence avant la réponse. Il garde QNAME, QTYPE, QCLASS, le choix de récursion, les bits DO et CD, l’identifiant de transaction et l’heure d’envoi. À l’arrivée, il préserve les octets du message, le point de terminaison, le transport, l’heure et l’éventuelle authentification de transaction.

Il découpe ensuite le paquet en RRsets. Pour chacun : propriétaire, type, classe, section, TTL observé, coupure de zone, bailiwick, origine locale ou cache lorsqu’elle est connue, instant de mise en cache et expiration. Si le client ignore la source interne du serveur, cette lacune reste une lacune ; AA ne doit pas la remplir artificiellement.

L’ancre AA devient un champ distinct : QNAME initial, premier propriétaire d’Answer, serveur répondant et zone d’autorité. Chaque alias et chaque délégation crée une relation vers une nouvelle requête. La glue du parent et la réponse autoritative de l’enfant restent liées mais non fusionnées.

Enfin, la validation DNSSEC s’attache à chaque RRset avec signatures, chaîne DS/DNSKEY, ancre, instant et résultat. Le bit AD reçu demeure séparé. Lorsque l’application utilise une adresse, le reçu indique le RRset et la génération de cache effectivement consommés.

On peut alors écrire une conclusion exacte : ce serveur a posé AA pour ce premier nom ; ce RRset venait de cette section ; cette validation lui a donné cet état ; cette autre requête a établi l’autorité du nom suivant ; l’application a utilisé ce résultat. Le bit conserve sa valeur précisément parce qu’il ne parle plus au nom de tout le paquet.

Sources