Annexe C. Authentication Examples (Exemples d'authentification)
Les exemples de cette section montrent comment les messages de réponse de l'annexe B sont authentifiés.
C.1. Authenticating an Answer (Authentification d'une réponse)
La requête de l'annexe B.1 a renvoyé un RRset MX pour x.w.example.com. Le RRSIG correspondant indique que le RRset MX a été signé par une DNSKEY "example" avec l'algorithme 5 et l'étiquette de clé 38519. Le résolveur a besoin du RR DNSKEY correspondant pour authentifier cette réponse. La discussion ci-dessous décrit comment un résolveur pourrait obtenir ce RR DNSKEY.
Le RRSIG indique que le TTL original du RRset MX était de 3600, et, aux fins d'authentification, le TTL actuel est remplacé par 3600. La valeur du champ des étiquettes RRSIG de 3 indique que la réponse n'était pas le résultat d'une expansion de joker. Le RRset MX x.w.example.com est placé sous forme canonique et, en supposant que l'heure actuelle se situe entre les dates d'inception et d'expiration de la signature, la signature est authentifiée.
C.1.1. Authenticating the Example DNSKEY RR (Authentification du RR DNSKEY d'exemple)
Cet exemple montre le processus d'authentification logique qui part d'une DNSKEY racine configurée (ou d'un RR DS) et descend dans l'arbre pour authentifier le RR DNSKEY "example" souhaité. Notez que l'ordre logique est présenté pour plus de clarté. Une implémentation peut choisir de construire l'authentification au fur et à mesure que les référencements sont reçus ou de construire la chaîne d'authentification uniquement après que tous les RRsets aient été obtenus, ou dans toute autre combinaison qu'elle juge appropriée. L'exemple ici ne démontre que le processus logique et ne dicte aucune règle d'implémentation.
Nous supposons que le résolveur commence avec un RR DNSKEY configuré pour la zone racine (ou un RR DS configuré pour la zone racine). Le résolveur vérifie si ce RR DNSKEY configuré est présent dans le RRset DNSKEY racine (ou si le RR DS correspond à une DNSKEY dans le RRset DNSKEY racine), si ce RR DNSKEY a signé le RRset DNSKEY racine, et si la durée de vie de la signature est valide. Si toutes ces conditions sont remplies, toutes les clés du RRset DNSKEY sont considérées comme authentifiées. Le résolveur utilise ensuite un (ou plusieurs) des RR DNSKEY racine pour authentifier le RRset DS "example". Notez que le résolveur peut avoir à interroger la zone racine pour obtenir le RRset DNSKEY racine ou le RRset DS "example".
Une fois le RRset DS authentifié à l'aide de la DNSKEY racine, le résolveur vérifie le RRset DNSKEY "example" pour un RR DNSKEY "example" qui correspond à l'un des RR DS "example" authentifiés. Si une telle DNSKEY "example" correspondante est trouvée, le résolveur vérifie si ce RR DNSKEY a signé le RRset DNSKEY "example" et si la durée de vie de la signature est valide. Si ces conditions sont remplies, toutes les clés du RRset DNSKEY "example" sont considérées comme authentifiées.
Enfin, le résolveur vérifie qu'un RR DNSKEY dans le RRset DNSKEY "example" utilise l'algorithme 5 et a une étiquette de clé de 38519. Cette DNSKEY est utilisée pour authentifier le RRSIG inclus dans la réponse. Si plusieurs RR DNSKEY "example" correspondent à cet algorithme et à cette étiquette de clé, chaque RR DNSKEY est essayé, et la réponse est authentifiée si l'un des RR DNSKEY correspondants valide la signature comme décrit ci-dessus.
C.2. Name Error (Erreur de nom)
La requête de l'annexe B.2 a renvoyé des RR NSEC qui prouvent que les données demandées n'existent pas et qu'aucun joker ne s'applique. La réponse négative est authentifiée en vérifiant les deux RR NSEC. Les RR NSEC sont authentifiés de manière identique à celle du RRset MX discuté ci-dessus.
C.3. No Data Error (Erreur sans données)
La requête de l'annexe B.3 a renvoyé un RR NSEC qui prouve que le nom demandé existe, mais que le type de RR demandé n'existe pas. La réponse négative est authentifiée en vérifiant le RR NSEC. Le RR NSEC est authentifié de manière identique à celle du RRset MX discuté ci-dessus.
C.4. Referral to Signed Zone (Référence à une zone signée)
La requête de l'annexe B.4 a renvoyé une référence à la zone signée "a.example.". Le RR DS est authentifié de manière identique à celle du RRset MX discuté ci-dessus. Ce RR DS est utilisé pour authentifier le RRset DNSKEY "a.example".
Une fois le RRset DS "a.example" authentifié à l'aide de la DNSKEY "example", le résolveur vérifie le RRset DNSKEY "a.example" pour un RR DNSKEY "a.example" qui correspond au RR DS. Si une telle DNSKEY "a.example" correspondante est trouvée, le résolveur vérifie si ce RR DNSKEY a signé le RRset DNSKEY "a.example" et si la durée de vie de la signature est valide. Si ces conditions sont remplies, toutes les clés du RRset DNSKEY "a.example" sont considérées comme authentifiées.
C.5. Referral to Unsigned Zone (Référence à une zone non signée)
La requête de l'annexe B.5 a renvoyé une référence à la zone non signée "b.example.". Le RR NSEC prouve qu'aucun RR DS n'est associé à la délégation "b.example.". Le RR NSEC est authentifié de manière identique à celle du RRset MX discuté ci-dessus.
Le résolveur détermine que "b.example." est une zone non signée et que les réponses de "b.example." seront non sécurisées.
C.6. Wildcard Expansion (Expansion de joker)
La requête de l'annexe B.6 a entraîné une expansion de joker. L'examen du champ des étiquettes RRSIG montre que la réponse était le résultat d'une expansion de joker. Le nom de joker "*.w.example." est placé sous forme canonique et authentifié comme dans l'annexe C.1. Le résolveur doit également vérifier le RR NSEC pour prouver qu'aucune correspondance plus proche n'existe dans la zone qui aurait été utilisée à la place de la correspondance de joker.
C.7. Wildcard No Data Error (Erreur sans données pour joker)
La requête de l'annexe B.7 a été répondue en utilisant un joker, mais la réponse est une réponse "sans données". La valeur du champ des étiquettes RRSIG de 2 dans le RRSIG indique que le RR NSEC a été dérivé d'un joker et fournit le nom du joker. Le RR NSEC de joker "*.w.example." est authentifié comme dans l'annexe C.1. Le résolveur doit également vérifier le RR NSEC pour prouver qu'aucune correspondance plus proche n'existe dans la zone qui aurait été utilisée à la place de la correspondance de joker.
C.8. DS Child Zone No Data Error (Erreur sans données DS de zone enfant)
La requête de l'annexe B.8 a été envoyée à la zone enfant et a renvoyé un RR NSEC qui montre qu'aucun RR DS n'existe dans la zone enfant. Notez que le RR NSEC indique qu'il y a un RR SOA à l'apex de la zone enfant, ce qui permet au résolveur de déterminer que cette réponse provient de la zone enfant par opposition à la zone parent. Le RR NSEC est authentifié de manière identique à celle du RRset MX discuté ci-dessus.