5. Resource Record Sets (Ensembles de ressources)
Chaque enregistrement de ressource DNS (Resource Record, RR) possède une étiquette (label), une classe (class), un type (type) et des données (data). Il n'a aucun sens que deux enregistrements aient une étiquette, une classe, un type et des données identiques — les serveurs devraient supprimer ces doublons lorsqu'ils sont rencontrés. Cependant, pour la plupart des types d'enregistrements, il est possible qu'ils existent avec la même étiquette, classe et type, mais avec des données différentes. Un tel groupe d'enregistrements est défini ici comme un ensemble d'enregistrements de ressources (Resource Record Set, RRSet).
5.1. Sending RRs from an RRSet (Envoi de RR depuis un RRSet)
Une requête pour une étiquette, classe et type spécifiques (ou non spécifiques) retournera toujours tous les enregistrements de l'RRSet associé — qu'il s'agisse d'un ou plusieurs RR. La réponse doit être marquée comme « tronquée » (truncated) si l'ensemble complet du RRSet ne peut pas tenir dans la réponse.
5.2. TTLs of RRs in an RRSet (TTL des RR dans un RRSet)
Les enregistrements de ressources ont également un temps de vie (Time to Live, TTL). Il est possible que les RR d'un RRSet aient des TTL différents. Aucune utilisation n'a été trouvée pour cela qui ne puisse être mieux accomplie d'autres manières. Cela peut cependant causer des réponses partielles (non marquées « tronquées ») d'un serveur de cache, où les TTL de certains RR du RRSet ont expiré mais pas tous.
Par conséquent, l'utilisation de TTL différents dans un RRSet est désormais dépréciée, les TTL de tous les RR dans un RRSet doivent être identiques.
Si un client reçoit une réponse contenant des RR d'un RRSet avec 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 requises, chercher à les acquérir auprès d'une source autoritaire. Les clients configurés pour envoyer toutes les requêtes à un ou plusieurs serveurs particuliers devraient traiter ces serveurs comme autoritaires à cette fin. Si une source autoritaire envoie un tel RRSet mal formé, le client devrait traiter les RR pour tous les usages comme si tous les TTL du RRSet avaient été définis sur la valeur du TTL le plus bas du RRSet. En aucun cas un serveur ne peut envoyer un RRSet avec des TTL non identiques.
5.3. DNSSEC Special Cases (Cas spéciaux DNSSEC)
Deux des types d'enregistrement ajoutés par la sécurité DNS (DNSSEC) [RFC2065] nécessitent une attention particulière lors de la considération de la formation des ensembles d'enregistrements de ressources. Il s'agit des enregistrements SIG et NXT. Il convient de noter que la sécurité DNS est encore très nouvelle et qu'il y a, à ce jour, peu d'expérience avec elle. Les lecteurs devraient être préparés à ce que les informations relatives à DNSSEC contenues dans ce document deviennent obsolètes à mesure que la spécification de sécurité DNS mûrit.
5.3.1. SIG records and RRSets (Enregistrements SIG et RRSets)
Un enregistrement SIG fournit des données de signature (validation) pour un autre RRSet dans le DNS. Lorsqu'une zone a été signée, chaque RRSet de la zone aura un enregistrement SIG associé. Le type de données du RRSet est inclus dans les données du SIG RR pour 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 avec une réponse pour valider cette réponse, les enregistrements SIG pour tous les autres RRSets associés au nœud approprié devraient également être inclus. Dans certains cas, cela pourrait représenter un très grand nombre d'enregistrements, le fait qu'ils soient plutôt volumineux n'aide pas.
Ainsi, il est spécifiquement permis à la section d'autorité de contenir uniquement les SIG RR dont le champ « type couvert » (type covered) est égal au champ de type d'une réponse retournée. Cependant, lorsque des enregistrements SIG sont retournés dans la section de réponse, en réponse à une requête pour des enregistrements SIG, ou une requête pour tous les enregistrements associés à un nom (type=ANY), l'ensemble complet du SIG RRSet doit être inclus, 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 incorrectement) comme données supplémentaires, doivent comprendre que l'ensemble complet du RRSet n'a presque certainement pas été inclus. Ainsi, ils ne doivent pas mettre en cache cet enregistrement SIG d'une manière qui permettrait de le retourner si une requête pour des enregistrements SIG était reçue à ce serveur. RFC2065 exige en fait que les requêtes SIG soient dirigées uniquement vers des serveurs autoritaires pour éviter les problèmes qui pourraient être causés ici, et tant que des serveurs existent qui ne comprennent pas les propriétés spéciales des enregistrements SIG, cela restera nécessaire. Cependant, une conception soigneuse du traitement des enregistrements SIG dans les nouvelles implémentations devrait permettre d'assouplir cette restriction à l'avenir, de sorte que les résolveurs n'ont pas besoin de traiter les requêtes d'enregistrement SIG de manière spéciale.
5.3.2. NXT RRs (Enregistrements NXT)
Les enregistrements de ressource suivants (Next Resource Records, NXT) sont encore plus particuliers. Il n'y aura jamais qu'un seul enregistrement NXT dans une zone pour une étiquette particulière, donc superficiellement, le problème du RRSet est trivial. Cependant, à une coupure de zone, la zone parent et la zone enfant (superzone et subzone dans la terminologie RFC2065) auront 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 NXT RRSets contiennent toujours un seul RR. Là où les deux enregistrements NXT sont visibles, deux RRSets existent. Cependant, les serveurs ne sont pas tenus de traiter cela comme un cas spécial lors de la réception d'enregistrements NXT dans une réponse. Ils peuvent choisir de remarquer l'existence de deux RRSets NXT différents et de les traiter comme ils le feraient pour deux RRSets différents de tout autre type. C'est-à-dire, mettre en cache l'un et ignorer l'autre. Les serveurs sensibles à la sécurité devront traiter correctement l'enregistrement NXT dans la réponse reçue.
5.4. Receiving RRSets (Réception des RRSets)
Les serveurs ne doivent jamais fusionner les RR d'une réponse avec les RR de leur cache pour former un RRSet. Si une réponse contient des données qui formeraient un RRSet avec des données dans le cache d'un serveur, le serveur doit soit ignorer les RR dans la réponse, soit supprimer l'ensemble du RRSet actuellement dans le cache, selon le cas. Par conséquent, la question de la variation des TTL entre le cache et une réponse ne suscite pas d'inquiétude, l'un sera ignoré. C'est-à-dire, l'un des ensembles de données est toujours incorrect si les données d'une réponse diffèrent des données dans le cache. Le défi pour le serveur est de déterminer lequel des ensembles de données est correct, le cas échéant, et de conserver celui-ci tout en ignorant l'autre. Notez que si un serveur reçoit une réponse contenant un RRSet identique à celui de son cache, à l'exception possible de la valeur TTL, il peut, optionnellement, mettre à jour le TTL dans son cache avec le TTL de la réponse reçue. Il devrait le faire si la réponse reçue était 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. Ranking data (Classement des données)
Lors de l'examen de l'acceptation d'un RRSet dans une réponse, ou de la conservation d'un RRSet déjà dans son cache, un serveur devrait considérer la fiabilité relative probable des différentes données. Une réponse autoritaire 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. Cependant, les informations supplémentaires d'une réponse seront ignorées si le cache contient des données provenant d'une réponse autoritaire ou d'un fichier de zone.
La précision des données disponibles est supposée provenir de sa source. La fiabilité doit être, par ordre du plus au moins :
- Données d'un fichier de zone primaire, autres que les données de collage
- Données d'un transfert de zone, autres que le collage
- Données autoritaires incluses dans la section de réponse d'une réponse autoritaire
- Données de la section d'autorité d'une réponse autoritaire
- Collage d'une zone primaire, ou collage d'un transfert de zone
- Données de la section de réponse d'une réponse non autoritaire, et données non autoritaires de la section de réponse de réponses autoritaires
- Informations supplémentaires d'une réponse autoritaire
- Données 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. Cependant, 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 à nouveau, en utilisant le nom canonique associé à l'alias.
Les RR non authentifiés reçus et mis en cache du groupe le moins fiable, c'est-à-dire les données de la section de données supplémentaires et les données de la section d'autorité d'une réponse non autoritaire, ne devraient pas être mis en cache de manière à permettre leur retour en tant que réponses à une requête reçue. Ils peuvent être retournés en tant qu'informations supplémentaires le cas échéant. Ignorer cela permettrait d'augmenter la fiabilité de données relativement peu fiables sans cause ni excuse.
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 les données non authentifiées du même type. Notez que dans tout ce document, « autoritaire » (authoritative) signifie une réponse avec le bit AA défini. DNSSEC utilise des chaînes de confiance de SIG et KEY pour déterminer l'authenticité des données, le bit AA est presque sans rapport. Cependant, les serveurs conscients de DNSSEC doivent toujours définir correctement le bit AA dans les réponses pour permettre un fonctionnement correct avec les serveurs qui ne sont pas conscients de la sécurité (presque tous actuellement).
Notez que, le collage exclu, il est impossible que des données provenant de deux fichiers de zone primaire correctement configurés, de deux zones secondaires correctement configurées (données provenant de transferts de zone) ou de données provenant de zones primaires et secondaires correctement configurées entrent en conflit. Là où le collage pour le 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 à une zone secondaire, mais peut autrement choisir n'importe quel ensemble unique de telles données. Choisir ce qui semble provenir d'une source plus proche de la source de données autoritaires peut avoir du sens là où cela peut être déterminé. Choisir des données primaires plutôt que secondaires permet de découvrir plus facilement la source de données de collage incorrectes lorsqu'un problème avec ces données existe. Lorsqu'un serveur peut détecter à partir de deux fichiers de zone qu'un ou plusieurs sont incorrectement configurés, de manière à créer des conflits, il devrait refuser de charger les zones déterminées comme erronées et émettre des diagnostics appropriés.
Le « collage » (Glue) ci-dessus comprend tout enregistrement dans un fichier de zone qui ne fait pas correctement partie de cette zone, y compris les enregistrements de serveur de noms de sous-zones déléguées (enregistrements NS), les enregistrements d'adresse qui accompagnent ces enregistrements NS (A, AAAA, etc.), et toutes autres données égarées qui pourraient apparaître.
5.5. Sending RRSets (reprise) (Envoi des RRSets (reprise))
Un ensemble d'enregistrements de ressources ne devrait être inclus qu'une seule fois dans toute réponse DNS. Il peut apparaître dans l'une des sections Réponse, Autorité ou Informations supplémentaires, selon les besoins. Cependant, il ne devrait pas être répété dans la même section ou dans une autre, sauf lorsqu'explicitement requis par une spécification. Par exemple, une réponse AXFR exige que l'enregistrement SOA (toujours un RRSet contenant un seul RR) soit à la fois le premier et le dernier enregistrement de la réponse. Lorsque des doublons sont requis de cette manière, le TTL transmis dans chaque cas doit être le même.