4. Comportement du serveur DNS
4.1. Serveurs autoritatifs
Lors de la réponse à une requête SVCB, les serveurs DNS autoritatifs DEVRAIENT (SHOULD) renvoyer les enregistrements A, AAAA et SVCB dans la section additionnelle (Additional section) pour tous les TargetNames qui se trouvent dans la zone. Si la zone est signée, le serveur DEVRAIT (SHOULD) également inclure les enregistrements DNSSEC authentifiant l'existence ou la non-existence de ces enregistrements dans la section additionnelle.
Voir la section 4.4 pour les exceptions.
4.2. Résolveurs récursifs
Que le résolveur récursif prenne en charge SVCB ou non, le processus normal de construction de réponse utilisé pour les types de RR inconnus [RFC3597] génère la section de réponse (Answer section) de la réponse. Les résolveurs récursifs qui prennent en charge SVCB DEVRAIENT (SHOULD) aider le client à exécuter la procédure de la section 3 avec une latence globale minimale en incorporant des informations utiles supplémentaires dans la section additionnelle de la réponse comme suit :
-
Incorporer les résultats de la résolution SVCB. Si la limite de longueur de chaîne locale du résolveur récursif (qui peut être différente de la limite du client) a été atteinte, terminer.
-
Si l'un des enregistrements SVCB résolus est en mode alias (AliasMode), choisissez-en un au hasard et résolvez les enregistrements SVCB, A et AAAA pour son TargetName.
-
Si des enregistrements SVCB sont résolus, aller à l'étape 1.
-
Sinon, incorporer les résultats de la résolution A et AAAA, et terminer.
-
-
Tous les enregistrements SVCB résolus sont en mode service (ServiceMode). Résoudre les requêtes A et AAAA pour chaque TargetName (ou pour le nom du propriétaire si TargetName est "."), incorporer tous les résultats et terminer.
Dans cette procédure, "résoudre" signifie la procédure de résolution récursive ordinaire du résolveur, comme s'il traitait une requête pour ce RRset. Cela inclut le suivi de tous les alias que le résolveur suivrait normalement (par exemple, CNAME, DNAME [DNAME]). Les erreurs ou anomalies dans l'obtention d'enregistrements supplémentaires PEUVENT (MAY) entraîner l'arrêt de ce processus, mais NE DOIVENT PAS (MUST NOT) elles-mêmes amener le résolveur à envoyer une réponse d'échec.
Voir la section 2.4.2 pour des mesures de protection supplémentaires que les résolveurs récursifs doivent mettre en œuvre pour atténuer les boucles.
Voir la section 5.2 pour les optimisations possibles de cette procédure.
4.2.1. DNS64
Les résolveurs DNS64 synthétisent les réponses aux requêtes AAAA pour les noms qui n'ont qu'un enregistrement A (section 5.1.7 de [RFC6147]). Les résolveurs DNS64 prenant en charge SVCB DEVRAIENT (SHOULD) appliquer la même logique de synthèse lors de la résolution des enregistrements AAAA pour le TargetName pour inclusion dans la section additionnelle (étape 2 de la section 4.2) et PEUVENT (MAY) omettre les enregistrements A de cette section.
Les résolveurs DNS64 NE DOIVENT PAS (MUST NOT) extrapoler la logique de synthèse AAAA aux indices IP dans les SvcParams (section 7.3). La modification des indices IP briserait la validation DNSSEC pour l'enregistrement SVCB et n'améliorerait pas les performances lorsque la recommandation ci-dessus est mise en œuvre.
4.3. Exigences générales
Les résolveurs récursifs DOIVENT (MUST) être capables de transmettre des enregistrements SVCB avec des SvcParamKeys non reconnus. Les résolveurs PEUVENT (MAY) y parvenir en traitant toute la portion SvcParams de l'enregistrement comme opaque, même si le contenu est invalide. Si un SvcParamKey reconnu est suivi d'une valeur invalide selon la spécification du SvcParam, un résolveur récursif PEUT (MAY) signaler une erreur telle que SERVFAIL au lieu de renvoyer l'enregistrement. Pour les types de valeurs complexes dont l'interprétation peut différer entre les implémentations ou dont des valeurs futures supplémentaires autorisées peuvent être ajoutées (par exemple, les URI ou "alpn"), les résolveurs DEVRAIENT (SHOULD) limiter la validation aux contraintes spécifiées.
Lors de la réponse à une requête qui inclut le bit DNSSEC OK [RFC3225], les serveurs DNS récursifs et autoritatifs compatibles DNSSEC DOIVENT (MUST) accompagner chaque RRset dans la section additionnelle avec les mêmes enregistrements liés à DNSSEC qu'ils enverraient en fournissant ce RRset comme réponse (par exemple, RRSIG, NSEC, NSEC3).
Selon la section 5.4.1 de [RFC2181], "Les RR non authentifiés reçus et mis en cache à partir de... la section de données additionnelles... ne devraient pas être mis en cache de manière à ce qu'ils soient renvoyés comme réponses à une requête reçue. Ils peuvent être renvoyés comme informations supplémentaires le cas échéant." Les résolveurs récursifs PEUVENT (MAY) donc mettre en cache les enregistrements de la section additionnelle pour les utiliser dans la population des réponses de la section additionnelle et PEUVENT (MAY) les mettre en cache pour une utilisation générale s'ils sont authentifiés par DNSSEC.
4.4. Sous-réseau client EDNS (ECS)
L'option de sous-réseau client EDNS (ECS) [RFC7871] permet aux résolveurs récursifs de demander des adresses IP adaptées à une plage d'IP client particulière. Les enregistrements SVCB peuvent contenir des adresses IP (dans les SvcParams ipv*hint) ou diriger les utilisateurs vers un TargetName spécifique au sous-réseau, de sorte que les résolveurs récursifs DEVRAIENT (SHOULD) inclure la même option ECS dans les requêtes SVCB que dans les requêtes A/AAAA.
Selon la section 7.3.1 de [RFC7871], "Tous les enregistrements de [la section additionnelle] NE DOIVENT PAS (MUST NOT) être liés à un réseau." En conséquence, lors du traitement d'une réponse dont le QTYPE est compatible SVCB, les résolveurs DEVRAIENT (SHOULD) traiter tous les enregistrements de la section additionnelle comme ayant SOURCE PREFIX-LENGTH défini à zéro et SCOPE PREFIX-LENGTH tel que spécifié dans l'option ECS. Les serveurs autoritatifs DOIVENT (MUST) omettre ces enregistrements s'ils ne sont pas adaptés à l'utilisation par les résolveurs stub qui définissent SOURCE PREFIX-LENGTH à zéro. Cela amènera le résolveur à effectuer une requête de suivi qui peut recevoir un ECS correctement adapté. (Cela est similaire à l'utilisation de CNAME avec l'option ECS comme discuté dans [RFC7871], section 7.2.1.)
Les serveurs autoritatifs qui omettent les enregistrements additionnels peuvent éviter la latence supplémentaire d'une requête de suivi en suivant les conseils de la section 10.2.