Groupe de travail Réseau

O. Gudmundsson

Request for Comments : 3226

décembre 2001

RFC mises à jour : 2874, 2535

 

Catégorie : En cours de normalisation

Taduction Claude Brière de L'Isle

 

Exigences de taille de message de serveur/résolveur à capacité DNSSEC et IPv6 A6

 

Statut du présent Mémo La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour 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émo n’est soumise à aucune restriction.

 

Déclaration de Copyright

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

 

Résumé

Le présent document rend obligatoire la prise en charge de EDNS0 (mécanismes d'extension pour le DNS) dans les entités DNS qui revendiquent la prise en charge des extensions de sécurité du DNS ou les enregistrements A6. Cette exigence est rendue nécessaire parce que ces nouveaux dispositifs augmentent la taille des messages du DNS. Si EDNS0 n'est pas pris en charge, le repli sur TCP qui s'ensuivra aura un impact dommageable sur la latence et sur la charge des serveurs DNS. Le présent document met à jour les RFC 2535 et RFC 2874, en ajoutant de nouvelles exigences.

 

1.   Introduction

 

Il serait utile d'être familiarisé avec le DNS [RFC1034, RFC1035], les extensions de sécurité du DNS [RFC2535], EDNS0 [RFC2671] et A6 [RFC2874].

 

Le paragraphe 2.3.4 du STD 13, RFC 1035, exige que les messages du DNS sur UDP aient une charge utile de données de 512 octets ou moins. La plus grand partie des logiciels du DNS d'aujourd'hui n'acceptent pas de datagrammes UDP plus longs. Toute réponse qui exige plus de 512 octets résulte en une réponse partielle et parfois inutile avec le bit de troncature établi ; dans la plupart des cas, le demandeur va réessayer alors en utilisant TCP. De plus, la livraison par le serveur de réponses tronquées varie largement et le traitement de ces réponses par le résolveur varie aussi, ce qui conduit à des inefficacités supplémentaires dans le traitement de la troncature.

 

Par rapport à UDP, TCP est un protocole coûteux si on l'utilise pour une simple transaction comme DNS : une connexion TCP exige cinq paquets pour son établissement et s suppression, sans compter les paquets de données, ce qui exige au moins trois allers-retours en plus de celui de l'interrogation UDP d'origine. Le serveur DNS a aussi besoin de conserver un état de la connexion durant cette transaction. De nombreux serveurs DNS répondent à des milliers d'interrogations par seconde ; les obliger à utiliser TCP causerait des redondances et délais significatifs.

 

1.1   Exigences

 

Les mots clés "DOIT", "EXIGE", "DEVRAIT", "RECOMMANDE", et "PEUT" dans le présent document sont à interpréter comme décrit dans la RFC 2119.

 

2.   Motivations

2.1   Motivations relatives à DNSSEC

 

DNSSEC [RFC2535] sécurise le DNS en ajoutant une signature de clé publique sur chaque enregistrement de ressource (RR) établi. Ces signatures sont dans une gamme de tailles d'environ 80 octets à 800 octets, et la plupart d'entre elles sont dans la gamme de 80 à 200 octets. L'ajout de signatures sur chaque RR ou la plupart d'entre eux établis dans une réponse accroît de façon significative la taille des réponses du DNS à partir de zones sécurisées.

 

 

Pour des raisons de performances et pour réduire la charge sur les serveurs du DNS, il est important que les serveurs et résolveurs soucieux de sécurité obtiennent toutes les données dans la section Answer et Authority d'une interrogation sans troncature. L'envoi de Données supplémentaires dans la même interrogation est utile lorsque le serveur est d'autorité pour les données, et cela réduit le nombre d'allers-retours.

 

DNSSEC OK[OK] spécifie comment un client peut, en utilisant EDNS0, indiquer qu'il est intéressé à recevoir des enregistrements DNSSEC. Le bit OK n'élimine pas le besoin de grandes réponses pour les clients à capacité DNSSEC.

 

2.1.1   Authentification de message ou motivation TSIG

 

TSIG [RFC2845] permet une authentification légère des messages du DNS, mais augmente la taille des messages d'au moins 70 octets. DNSSEC spécifie une authentification de message coûteuse en calcul SIG(0) en utilisant une signature de clé publique standard. Comme une seule TSIG ou SIG(0) peut être attachée à chaque réponse DNS, l'accroissement de taille de l'authentification de message n'est pas significative, mais peut cependant conduire à une troncature.

 

2.2   Motivations dans IPv6

 

Les adresses IPv6 [RFC2874] sont de 128 bits et peuvent être représentées dans le DNS par plusieurs enregistrements A6, consistant chacun en un nom de domaine et un champ binaire. Le nom de domaine se réfère à un préfixe d'adresse qui peut exiger que des enregistrements de ressource A6 additionnels soient inclus dans la réponse. Les réponses où le nom demandé a plusieurs adresses A6 peuvent déborder d'une taille de paquet UDP de 512 octets.

 

2.3   Motivations de serveur racine et de serveur TLD

 

Le nombre actuel de serveurs racine est limité à 13 car c'est le nombre maximum de serveurs de noms et de leurs enregistrements d'adresse qui tient dans une réponse de 512 octets pour un enregistrement SOA. Si les serveurs racine commencent à annoncer des enregistrements A6 ou KEY, la réponse pour les enregistrements NS racine ne tiendront pas dans un seul message DNS de 512 octets, ce qui aura pour résultat un grand nombre de connexions d'interrogation TCP avec les serveurs racine. Même si tous les résolveurs client interrogent leur serveur de nom local pour avoir les informations, il y a des millions de ces serveurs. Chaque serveur de noms doit mettre à jour périodiquement ses informations sur les serveurs de haut niveau.

 

Pour des raisons de redondance, de latence et d'équilibrage de charge, de grands nombres de serveurs DNS sont nécessaires pour certaines zones. Comme la zone racine est utilisée par le réseau tout entier, il est important d'avoir des serveurs aussi nombreux que possible. Les grands TLD (et de nombreux SLD à haute visibilité) ont souvent suffisamment de serveurs pour que aussi bien les enregistrements A6 que KEY causent le débordement de la limite de 512 octets par la réponse de NS. Noter que ces zones avec de grands nombres de serveurs sont souvent exactement les zones qui sont critiques pour le fonctionnement du réseau et qui supportent déjà des charges extrêmement élevées.

 

2.4   DP ou TCP pour les messages du DNS

 

Étant donnés tous ces facteurs, il est essentiel que toute mise en œuvre qui prend en charge DNSSEC et ou A6 soit capable d'utiliser de plus gros messages DNS que 512 octets.

 

La restriction originale à 512 a été mise en place pour réduire la probabilité de fragmentation des réponses du DNS. Un message UDP fragmenté qui subit la perte d'un des fragments rend la réponse inutile et la question doit être répétée. Une connexion TCP exige un plus grand nombre d'allers-retours pour l'établissement, le transfert des données et sa suppression, mais seul les segments de données perdus sont retransmis.

 

Dans les premiers jours de l'Internet, un certain nombre de mises en œuvre IP ne traitaient pas bien la fragmentation, mais tous les systèmes d'exploitation modernes ont surmonté ce problème et donc l'envoi de messages fragmentés ne pose plus de problème de ce point de vue. La question ouverte aujourd'hui est l'effet des pertes sur un message fragmenté. Si la connexion a un ratio de pertes élevé, seul TCP permettra un transfert fiables des données du DNS. La plupart des liaisons ont des ratios de pertes faibles et donc l'envoi de paquets UDP fragmentés en un aller-retour est mieux que d'établir une connexion TCP pour transférer quelques milliers d'octets.

 

2.5   DNS0 et les gros messages UDP

 

EDNS0 [RFC2671] permet aux clients de déclarer la taille maximum de message UDP qu'ils veulent traiter. Et donc, si la réponse attendue est entre 512 octets et la taille maximum que le client peut accepter, la surcharge additionnelle d'une connexion TCP peut être évitée.

 

3.   Changements au protocole

 

Le présent document met à jour les RFC 2535 et RFC 2874, en ajoutant de nouvelles exigences.

 

Tous les serveurs et résolveurs conformes à la RFC 2535 DOIVENT prendre en charge EDNS0 et annoncer une taille de message d'au moins 1220 octets, mais DEVRAIENT annoncer une taille de message de 4000 octets. Cette valeur pourrait être trop basse pour obtenir des réponses complètes des serveurs de haut niveau et des successeurs du présent document pourront exiger une valeur plus élevée.

 

Tous les serveurs et résolveurs conformes à la RFC 2874 DOIVENT prendre en charge EDNS0 et annoncer une taille de message d'au moins 1024 octets, mais DEVRAIENT annoncer une taille de message de 2048. Les datagrammes IPv6 devraient être de 1024 octets, sauf si la MTU du chemin est connue. (Noter que ceci est inférieur à la MTU minimum d'IPv6 pour permettre des extensions d'en-têtes et/ou l'encapsulation sans excéder la MTU minimum.)

 

Toutes les entités conformes aux RFC 2535 et RFC 2874 DOIVENT être capables de traiter des paquets UDP IPv4 et IPv6 fragmentés.

 

Tous les hôtes qui prennent en charge à la fois la RFC 2535 et la RFC 2874 DOIVENT utiliser la plus grande valeur exigée dans les annonces EDNS0.

 

4.   Remerciements

 

Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis Michael Patton et Kazu Yamamoto ont été essentiels pour la motivation et la mise en forme de ce document.

 

5.   Considérations pour la sécurité

 

Il n'y a pas de considérations pour la sécurité autres que celles de la RFC 2671.

 

6.   Considérations relatives à l'IANA

 

Aucune

 

7.   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.

 

[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.)

 

[RFC2845]   P. Vixie, O. Gudmundsson, D. Eastlake et B. Wellington, "Authentification de transaction de clé secrète pour DNS (TSIG)", mai 20000 (MàJ parRFC3645) (P.S.)

 

[RFC2874]   M. Crawford, C. Huitema, "Extensions de DNS pour la prise en charge de l'agrégation et du renumérotage d'adresse IPv6", juillet 2000. (MàJ parRFC3152, RFC3226, RFC3363, RFC3364) (Expérimentale)

 

[RFC3225]   D. Conrad, "Indication de la prise en charge de DNSSEC par le résolveur", décembre 2001. (MàJ parRFC4033, RFC4034, RFC4035) (P.S.)

 

8.   Adresse de l'auteur

 

Olafur Gudmundsson

3826 Legation Street, NW

Washington, DC 20015

USA

mél : ogud@ogud.com

 

9.   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.