Indication de la prise en charge de DNSSEC par un résolveur

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2001).

Résumé

Pour la mise en place opérationnelle des extensio,s de sécurité du système des noms de domaine (DNSSEC, Domain Name System Security Extensions) les serveurs à capacité DNSSEC ne devraient effectuer que des inclusions automatiques d'enregistrements de ressources (RR) DNSSEC quand il y a une indication explicite que le résolveur peut comprendre ces RR. Le présent document propose l'utilisation d'un bit dans l'en-tête EDNS0 pour fournir cette indication explicite et décrit les changements de protocole nécessaires pour mettre en œuvre cette notification.

1.   Introduction

DNSSEC [RFC2535] a été spécifié pour fournir l'intégrité et l'authentification des données aux résolveurs et applications à capacité de sécurité grâce à l'utilisation de signatures numériques cryptographiques. Cependant, avec le déploiement de DNSSEC, des clients sans capacité DNSSEC vont vraisemblablement interroger les serveurs à capacité DNSSEC. Dans de telles situations, le serveur à capacité DNSSEC (qui répond à une demande de données dans une zone signée) va répondre avec un enregistrement SIG, KEY, et/ou NXT. Pour les raisons décrites dans la section suivante, de telles réponses peuvent avoir des impacts opérationnels négatifs significatifs sur l'infrastructure du DNS.

Le présent document expose une méthode pour éviter ces impacts négatifs, à savoir que les serveurs à capacité DNSSEC ne devraient répondre qu'avec des RR SIG, KEY, et/ou NXT lorsque il y a une indication explicite de la part du résolveur qu'il peut comprendre ces RR.

Pour les besoins du présent document, les "RR de sécurité de DNSSEC" sont les RR du type SIG, KEY ou NXT.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT" et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

2.   Motifs

Initialement, lors du déploiement de DNSSEC, la vaste majorité des interrogations proviennent de résolveurs qui n'ont pas la capacité DNSSEC et donc ne comprennent pas ou ne prennent pas en charge les RR de sécurité DNSSEC. Lorsque une interrogation provenant d'un tel résolveur est reçue pour une zone DNSSEC signée, la spécification DNSSEC indique que le serveur de noms doit répondre avec les RR de sécurité DNSSEC appropriés. Comme les datagrammes UDP du DNS sont limités à 512 octets [RFC1035], les réponses incluant des RR de sécurité DNSSEC ont une forte probabilité de résulter en une réponse tronquée en retour et le résolveur réessaye l'interrogation en utilisant TCP.

Les interrogations du DNS en TCP résultent en une redondance significative due à l'établissement et à la suppression de la connexion. Du point de vue du fonctionnement, l'impact de ces interrogations TCP sera vraisemblablement assez dommageable en termes d'accroissement du trafic réseau (normalement cinq paquets pour une seule interrogation/réponse au lieu de deux), ce qui accroît la latence résultant des délais supplémentaires d'aller-retour, une incidence accrue des échecs dus à l'expiration des temporisations, et d'une augmentation significative de la charge sur les serveurs de noms.

De plus, dans le déploiement préliminaire et expérimental de DNSSEC, il a été rapporté que des résolveurs sans capacité DNSSEC étant incapables de traiter les réponses qui contiennent des RR de sécurité DNSSEC, il en résulte un échec du résolveur (dans le plus mauvais cas) ou que des réponses entières sont ignorées (dans le meilleur cas).

Étant données ces implications opérationnelles, la notification explicite au serveur de noms que le client est prêt à recevoir (sinon à comprendre) les RR de sécurité DNSSEC serait prudent.

La prise en charge de DNSSEC côté client est supposé être binaire – soit le client veut recevoir tous les RR de sécurité DNSSEC, soit il ne veut en accepter aucun. À ce titre, un seul bit est suffisant pour indiquer la prise en charge de DNSSEC du côté client. Comme l'utilisation effective de DNSSEC implique le besoin de EDNS0 [RFC2671], que les bits dans l'en-tête "classique" (l'en-tête DNS non amélioré par EDNS) sont rares, et qu'il peut y avoir des situations dans lesquelles des serveurs de mise en antémémoire ou de transmission non conformes copient des données de façon inappropriée à partir des en-têtes classiques lorsque des interrogations sont passées à des serveurs d'autorité, l'utilisation d'un bit pris dans l'en-tête EDNS0 est proposée.

Une autre approche serait d'utiliser l'existence d'un en-tête EDNS0 comme indication implicite de la prise en charge par le côté client de DNSSEC. Cette approche n'a pas été choisie car il peut y avoir des applications dans lesquelles EDNS0 est pris en charge mais l'utilisation de DNSSEC est inappropriée.

3.   Changements au protocole

Le mécanisme choisi pour la notification explicite de la capacité du client à accepter (sinon à comprendre) les RR de sécurité DNSSEC est d'utiliser le bit de plus fort poids du champ Z de l'en-tête OPT de EDNS0 dans l'interrogation. Ce bit est référencé comme bit "DNSSEC OK" (DO). Dans le contexte des méta-RR OPT EDNS0, le bit DO est le premier bit des troisième et quatrième octets de la portion "RCODE étendu et fanions" du méta-RR OPT EDNS0, structuré comme suit :

Régler le bit DO à un dans une interrogation indique au serveur que le résolveur est capable d'accepter les RR de sécurité DNSSEC. Le bit DO non établi (mis à zéro) indique que le résolveur n'est pas prêt à traiter les RR de sécurité DNSSEC et que ces RR NE DOIVENT PAS être retournés dans la réponse (sauf si les RR de sécurité DNSSEC sont explicitement demandés). Le bit DO de l'interrogation DOIT être copié dans la réponse.

Plus explicitement, les serveurs de noms à capacité DNSSEC NE DOIVENT PAS insérer les RR SIG, KEY, ou NXT pour authentifier une réponse comme spécifié dans la [RFC2535] sauf si le bit DO a été établi dans la demance. Les enregistrements de sécurité qui correspondent à une interrogation explicite SIG, KEY, NXT, ou ANY, ou font partie des données de zone pour une interrogation AXFR ou IXFR, sont inclus que le bit DO soit mis ou non.

Un serveur récurrent à capacité DNSSEC DOIt établir le bit DO sur les demandes récurrentes, sans considération de l'état du bit DO sur la demande initiale du résolveur. Si la demande initiale du résolveur n'a pas le bit DO établi, le serveur récurrent à capacité DNSSEC DOIT retirer les RR de sécurité DNSSEC avant de retourner les données au client, mais cependant, les données en antémémoire NE DOIVENT PAS être modifiées.

Dans le cas où un serveur retourne une réponse NOTIMP, FORMERR ou SERVFAIL à une interrogation qui a le bit DO mis, le résolveur NE DEVRAIT PAS attendre de RR de sécurité DNSSEC et DEVRAIT réessayer l'interrogation sans EDNS0 conformément au paragraphe 5.3 de la [RFC2671].

Considérations pour la sécurité

L'absence des données DNSSEC dans une réponse à une interrogation avec le bit DO mis NE DOIT PAS être prise comme signifiant qu'aucune information de sécurité n'est disponible pour cette zone car la réponse peut être falsifiée ou être une réponse non falsifiée à une interrogation altérée (où le bit DO a été supprimé).

Considérations relatives à l'IANA

EDNS0 [RFC2671] définit 16 bits d'extension de fanions dans l'enregistrement OPT, ces bits sont codés dans le champ TTL de l'enregistrement OPT (paragraphe 4.6 de la RFC2671).

Le présent document réserve un de ces bits comme bit d'acquiescement. Il est demandé que soit alloué le bit de gauche. Et donc l'utilisation du champ TTL de l'enregistrement OPT devrait ressembler à

Remerciements

Le présent document se fonde sur un projet élaboré par Bob Halley avec des apports de Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, Rob Austein, Steve Bellovin et Erik Nordmark.

Références

[RFC1034]   P. Mockapetris, P., "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.

[RFC1035]   P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987.

[RFC2119]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2535]   D. Eastlake, 3 rd, "Extensions de sécurité du système des noms de domaines", mars 1999. (Obsolète, voirRFC4033, RFC4034, RFC4035) (P.S.)

[RFC2671]   P. Vixie, "Mécanismes d'extension pour le DNS (EDNS0)", août 1999. (P.S.)

Adresse de l'auteur

David Conrad

Nominum Inc.

950 Charter Street

Redwood City, CA 94063

USA

téléphone : +1 650 381 6003

mél : david.conrad@nominum.com

Déclaration de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.