5. Ensembles de records de ressource

Chaque enregistrement de ressource DNS (Resource Record, RR) possède une étiquette, une classe, un type et des données. Il n'a pas de sens que deux enregistrements aient à la fois une étiquette, une classe, un type et des données identiques — les serveurs devraient supprimer de tels doublons s'ils en rencontrent. Il est toutefois possible, pour la plupart des types d'enregistrements, d'exister avec la même étiquette, la même classe et le même type, mais avec des données différentes. Un tel groupe d'enregistrements est par la présente défini comme un ensemble de records de ressource (Resource Record Set, RRSet).

5.1. Envoi de RR depuis un RRSet

Une requête portant sur une étiquette, une classe et un type spécifiques (ou non spécifiques) renverra toujours tous les enregistrements de l'ensemble de records de ressource associé — qu'il s'agisse d'un seul RR ou de plusieurs. La réponse doit être marquée comme « tronquée » si l'intégralité du RRSet ne tient pas dans la réponse.

5.2. TTL des RR dans un RRSet

Les enregistrements de ressource possèdent également une durée de vie (TTL). Il est possible que les RR d'un RRSet aient des TTL différents. Aucun usage de cette possibilité n'a été trouvé qui ne puisse être mieux réalisé d'une autre manière. Cela peut toutefois provoquer des réponses partielles (non marquées comme « tronquées ») de la part d'un serveur de cache, lorsque les TTL de certains RR du RRSet, mais pas de tous, ont expiré.

Par conséquent, l'utilisation de TTL différents au sein d'un RRSet est par la présente déconseillée ; les TTL de tous les RR d'un RRSet doivent être identiques.

Si un client reçoit une réponse contenant des RR provenant d'un RRSet ayant des TTL différents, il devrait traiter cela comme une erreur. Si le RRSet concerné provient d'une source non autoritaire pour ces données, le client devrait simplement ignorer le RRSet et, si les valeurs étaient nécessaires, chercher à les acquérir auprès d'une source autoritaire. Les clients configurés pour envoyer toutes leurs requêtes à un ou plusieurs serveurs particuliers devraient considérer ces serveurs comme autoritaires à cette fin. Si une source autoritaire envoie un tel RRSet mal formé, le client devrait traiter les RR, à toutes fins, comme si tous les TTL du RRSet avaient été fixés à la valeur du TTL le plus bas du RRSet. En aucun cas un serveur ne peut envoyer un RRSet dont les TTL ne sont pas tous égaux.

5.3. Cas particuliers DNSSEC

Deux des types d'enregistrements ajoutés par la sécurité DNS (DNS Security, DNSSEC) [RFC2065] exigent une attention particulière lorsqu'on envisage la formation des ensembles de records de ressource. Il s'agit des enregistrements SIG et NXT. Il convient de noter que la sécurité DNS est encore très récente et que l'expérience acquise à son sujet est, à ce jour, limitée. Les lecteurs doivent s'attendre à ce que les informations relatives à DNSSEC contenues dans ce document deviennent obsolètes à mesure que la spécification de la sécurité DNS mûrit.

5.3.1. Enregistrements SIG et RRSet

Un enregistrement SIG fournit des données de signature (de validation) pour un autre RRSet du DNS. Lorsqu'une zone a été signée, chaque RRSet de la zone s'est vu associer un enregistrement SIG. Le type de données du RRSet est inclus dans les données du RR SIG, afin d'indiquer à quel RRSet particulier cet enregistrement SIG est associé. Si les règles ci-dessus étaient appliquées, chaque fois qu'un enregistrement SIG serait inclus dans une réponse pour valider celle-ci, les enregistrements SIG de tous les autres RRSet associés au nœud approprié devraient également être inclus. Dans certains cas, cela pourrait représenter un très grand nombre d'enregistrements, ce que n'arrange pas leur taille plutôt importante en tant que RR.

Ainsi, il est explicitement permis à la section d'autorité (authority section) de ne contenir que les SIG RR dont le champ « type covered » est égal au champ type d'une réponse renvoyée. Toutefois, lorsque des enregistrements SIG sont renvoyés dans la section de réponse (answer section), en réponse à une requête portant sur des enregistrements SIG, ou à une requête portant sur tous les enregistrements associés à un nom (type=ANY), l'intégralité du RRSet SIG doit être incluse, comme pour tout autre type de RR.

Les serveurs qui reçoivent des réponses contenant des enregistrements SIG dans la section d'autorité, ou (probablement à tort) à titre de données supplémentaires, doivent comprendre que l'intégralité du RRSet n'a presque certainement pas été incluse. Ils ne doivent donc pas mettre cet enregistrement SIG en cache d'une manière qui permettrait de le renvoyer si une requête portant sur des enregistrements SIG était reçue par ce serveur. La RFC2065 exige en réalité que les requêtes SIG soient dirigées uniquement vers des serveurs autoritaires afin d'éviter les problèmes qui pourraient en résulter, et tant qu'il existera des serveurs ne comprenant pas les propriétés particulières des enregistrements SIG, cela restera nécessaire. Cependant, une conception soignée du traitement des enregistrements SIG dans les nouvelles implémentations devrait permettre d'assouplir cette restriction à l'avenir, afin que les résolveurs n'aient pas besoin de traiter les requêtes d'enregistrements SIG de manière particulière.

Il a parfois été affirmé qu'une demande reçue pour un enregistrement SIG devrait être transmise à un serveur autoritaire, plutôt que d'être satisfaite à partir des données du cache. Cela n'est pas nécessaire — un serveur qui sait que SIG constitue un cas particulier pour un tel traitement ferait mieux de mettre correctement en cache les enregistrements SIG, en tenant compte de leurs caractéristiques. Le serveur peut alors déterminer quand il est sûr de répondre depuis le cache, et quand la réponse n'est pas disponible et que la requête doit être transmise.

5.3.2. RR NXT

Les Next Resource Records (NXT) sont encore plus particuliers. Il n'y aura jamais qu'un seul enregistrement NXT dans une zone pour une étiquette donnée, de sorte que, superficiellement, le problème des RRSet est trivial. Toutefois, au niveau d'une coupure de zone, la zone parente et la zone enfant (superzone et subzone dans la terminologie de la RFC2065) auront toutes deux des enregistrements NXT pour le même nom. Ces deux enregistrements NXT ne forment pas un RRSet, même lorsque les deux zones sont hébergées sur le même serveur. Les RRSet NXT ne contiennent toujours qu'un seul RR. Lorsque les deux enregistrements NXT sont visibles, il existe deux RRSet. Cependant, les serveurs ne sont pas tenus de traiter cela comme un cas particulier lorsqu'ils reçoivent des enregistrements NXT dans une réponse. Ils peuvent choisir de remarquer l'existence de deux RRSet NXT différents et de les traiter comme ils traiteraient deux RRSet différents de tout autre type. C'est-à-dire mettre l'un en cache et ignorer l'autre. Les serveurs conscients de la sécurité devront toutefois traiter correctement l'enregistrement NXT de la réponse reçue.

5.4. Réception des RRSet

Les serveurs ne doivent jamais fusionner des RR provenant d'une réponse avec des RR de leur cache pour former un RRSet. Si une réponse contient des données qui formeraient un RRSet avec des données du cache d'un serveur, le serveur doit, selon le cas, soit ignorer les RR de la réponse, soit écarter l'intégralité du RRSet actuellement en cache. Par conséquent, la question de TTL variant entre le cache et une réponse ne pose pas de problème : l'un des deux sera ignoré. Autrement dit, l'un des ensembles de données est toujours incorrect si les données d'une réponse diffèrent des données du cache. Le défi, pour le serveur, est de déterminer lequel des ensembles de données est correct, si tant est que l'un le soit, et de le conserver tout en ignorant l'autre. Notez que si un serveur reçoit une réponse contenant un RRSet identique à celui de son cache, à la seule exception possible de la valeur du TTL, il peut, facultativement, mettre à jour le TTL de son cache avec le TTL de la réponse reçue. Il devrait le faire si la réponse reçue devait être considérée comme plus autoritaire (comme discuté dans la section suivante) que la réponse précédemment mise en cache.

5.4.1. Classement des données

Lorsqu'il envisage d'accepter un RRSet dans une réponse, ou de conserver à la place un RRSet déjà présent dans son cache, un serveur devrait considérer la fiabilité relative probable des différentes données. Une réponse autoritaire issue d'une réponse devrait remplacer les données mises en cache qui avaient été obtenues à partir d'informations supplémentaires dans une réponse antérieure. Toutefois, les informations supplémentaires d'une réponse seront ignorées si le cache contient des données issues d'une réponse autoritaire ou d'un fichier de zone.

L'exactitude des données disponibles est présumée d'après leur source. La fiabilité doit être, de la plus élevée à la plus faible :

• Données provenant d'un fichier de zone primaire, autres que les données de colle (glue),
• Données provenant d'un transfert de zone, autres que la colle (glue),
• Les données autoritaires incluses dans la section de réponse d'une réponse autoritaire.
• Données provenant de la section d'autorité d'une réponse autoritaire,
• La colle (glue) provenant d'une zone primaire, ou la colle provenant d'un transfert de zone,
• Données provenant de la section de réponse d'une réponse non autoritaire, et données non autoritaires provenant de la section de réponse de réponses autoritaires,
• Informations supplémentaires d'une réponse autoritaire, données provenant de la section d'autorité d'une réponse non autoritaire, informations supplémentaires de réponses non autoritaires.

Notez que la section de réponse d'une réponse autoritaire ne contient normalement que des données autoritaires. Toutefois, lorsque le nom recherché est un alias (voir section 10.1.1), seul l'enregistrement décrivant cet alias est nécessairement autoritaire. Les clients devraient supposer que d'autres enregistrements peuvent provenir du cache du serveur. Lorsque des réponses autoritaires sont requises, le client devrait interroger de nouveau, en utilisant le nom canonique associé à l'alias.

Les RR non authentifiés reçus et mis en cache à partir du groupe le moins fiable de ces catégories, c'est-à-dire les données provenant de la section supplémentaire et les données provenant de la section d'autorité d'une réponse non autoritaire, ne devraient pas être mis en cache de manière à pouvoir un jour être renvoyés comme réponses à une requête reçue. Ils peuvent être renvoyés à titre d'informations supplémentaires lorsque cela est approprié. Ignorer cela permettrait d'augmenter sans motif ni excuse la fiabilité de données relativement peu fiables.

Lorsque la sécurité DNS [RFC2065] est utilisée, et qu'une réponse authentifiée a été reçue et vérifiée, les données ainsi authentifiées doivent être considérées comme plus fiables que des données non authentifiées du même type. Notez que, dans tout ce document, « autoritaire » désigne une réponse dont le bit AA est positionné. DNSSEC utilise des chaînes de confiance d'enregistrements SIG et KEY pour déterminer l'authenticité des données ; le bit AA y est presque sans importance. Toutefois, les serveurs conscients de DNSSEC doivent malgré tout positionner correctement le bit AA dans les réponses afin de fonctionner correctement avec les serveurs qui ne sont pas conscients de la sécurité (la quasi-totalité actuellement).

Notez que, la colle exceptée, il est impossible que les données de deux fichiers de zone primaires correctement configurés, de deux zones secondaires correctement configurées (données issues de transferts de zone), ou les données de zones primaires et secondaires correctement configurées, entrent un jour en conflit. Lorsque la colle d'un même nom existe dans plusieurs zones et diffère en valeur, le serveur de noms devrait sélectionner les données d'un fichier de zone primaire de préférence à celles d'une zone secondaire, mais peut sinon choisir n'importe quel ensemble unique de ces données. Choisir celles qui semblent provenir d'une source plus proche de la source de données autoritaire peut avoir du sens lorsque cela peut être déterminé. Choisir les données primaires plutôt que secondaires permet de découvrir plus facilement la source de données de colle incorrectes, lorsqu'un problème avec de telles données existe. Lorsqu'un serveur peut détecter, à partir de deux fichiers de zone, que l'un ou plusieurs sont incorrectement configurés de manière à créer des conflits, il devrait refuser de charger les zones jugées erronées et émettre des diagnostics appropriés.

La « colle » (glue) mentionnée ci-dessus comprend tout enregistrement d'un fichier de zone qui ne fait pas proprement partie de cette zone, y compris les enregistrements de serveur de noms des sous-zones déléguées (enregistrements NS), les enregistrements d'adresse qui accompagnent ces enregistrements NS (A, AAAA, etc.), et toute autre donnée parasite susceptible d'apparaître.

5.5. Envoi des RRSet (rappel)

Un ensemble de records de ressource ne devrait être inclus qu'une seule fois dans une réponse DNS. Il peut apparaître, selon les besoins, dans n'importe laquelle des sections de réponse, d'autorité ou d'informations supplémentaires. Il ne devrait toutefois pas être répété dans la même section, ni dans aucune autre, sauf lorsque cela est explicitement exigé par une spécification. Par exemple, une réponse AXFR exige que l'enregistrement SOA (toujours un RRSet ne contenant qu'un seul RR) soit à la fois le premier et le dernier enregistrement de la réponse. Lorsque des doublons sont ainsi exigés, le TTL transmis dans chaque cas doit être identique.