Groupe de travail Réseau

D. Lawrence, Nominum

Request for Comments : 3425

 

RFC mise à jour : 1035

novembre 2002

Catégorie : En cours de normalisation

Traduction Claude Brière de L'Isle

 

 

IQUERY devient obsolète

 

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

 

Notice de Copyright

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

 

Résumé

La méthode IQUERY, spécifiée dans la RFC 1035, qui effectue des recherches inverses dans le DNS, n'a jamais été mise en œuvre de façon généralisée et a habituellement été désactivée lorsqu'elle était mise en œuvre. Ceci reflète une perception générale de la communauté de l'Internet que le concept n'était pas mûr et que l'approche de remplacement largement utilisée d'utiliser les interrogations de pointeur (PTR) et les enregistrements de transposition inverse était préférable. Par conséquent, le présent document déconseille l'opération IQUERY, et la déclare entièrement obsolète. Le présent document met à jour la RFC 1035.

 

1.   Introduction

 

 

Comme spécifié dans la RFC 1035 (paragraphe 6.4), l'opération IQUERY pour les opérations du DNS est utilisée pour rechercher le ou les noms qui sont associés à une valeur donnée. La valeur recherchée est fournie dans la section réponse de l'interrogation et la réponse remplit la section question avec un ou plusieurs triplets de type, nom et classe.

 

Comme noté au paragraphe 6.4.3 de la [RFC1035], le traitement d'une interrogation inverse peut constituer une assez lourde charge pour un serveur. Un serveur aurait besoin d'effectuer soit une recherche exhaustive dans sa base de données soit entretenir une base de données séparée qui serait alimentée par les valeurs de la base de données principale. Ces deux approches pourraient constituer une lourde charge pour l'utilisation des ressources du système, particulièrement pour les serveurs qui font autorité pour des millions de noms.

 

Les paquets de réponse pour ces méga serveurs pourraient être exceptionnellement grands, et couvrir des tailles de plusieurs gigaoctets. Par exemple, l'utilisation de IQUERY pour trouver chaque domaine qui est délégué à un des serveurs de noms d'une gros FAI pourrait retourner des dizaines de milliers de triplets dans la section question. Cela pourrait facilement être utilisé pour lancer des attaques de déni de service.

 

Les opérateurs de serveurs qui acceptent IQUERY sous certaines forme (comme de très anciens serveur BIND 4) optent généralement pour sa désactivation. Ceci est largement dû aux bogues dans des codes insuffisamment travaillés, ou à des préoccupations sur l'exposition de grands blocs de noms dans leurs zones par des testeurs tels que les interrogations MX inverses.

 

IQUERY est aussi handicapé de façon inhérente par le fait qu'il est incapable de dire au demandeur où il doit aller pour obtenir les informations qu'il demande. La réponse est très spécifique du seul serveur interrogé. C'est parfois un outil de diagnostic pratique, mais apparemment pas assez pour que les opérateurs de serveurs aiment l'activer, ou demandent sa mise en œuvre là où il manque.

 

Aucun client connu n'utilise IQUERY pour fournir de service significatif. Le seul support de transposition inverse courant sur l'Internet, la transposition d'enregistrements d'adresse en noms, est fourni par l'utilisation d'enregistrement de pointeur (PTR) dans l'arborescence in-addr.arpa et a bien servi la communauté de l'Internet pendant de nombreuses années.

 

Sur la base de tous ces facteurs, le présent document recommande que l'opération IQUERY soit officiellement rendue obsolète pour les serveurs du DNS.

 

 

2.   Exigences

 

Le mot clé "DEVRAIT" dans le présent document est à interpréter comme décrit dans le BCP 14, RFC 2119, à savoir qu'il peut exister des raisons valables pour ignorer un élément particulier, mais les pleines implications doivent en être comprises et soigneusement évaluées avant de choisir un cours différent.

 

3.   Effets sur la RFC 1035

 

L'effet du présent document est de changer la définition du opcode 1 par rapport à celle définie à l'origine au paragraphe 4.1.1 de la RFC 1035, et de se substituer entièrement au paragraphe 6.4 (y compris ses sous-paragraphes) de la R 1035.

 

La définition du opcode 1 est changée ici en :

 

"1   une interrogation inverse (IQUERY) (obsolète)"

 

Le texte du paragraphe 6.4 de la RFC 1035 est maintenant considéré comme obsolète. Ce qui suit est une déclaration d'applicabilité concernant le opcode IQUERY :

 

Les interrogations inverses qui utilisent le opcode IQUERY étaient à l'origine décrites comme la capacité à rechercher les noms qui sont associés à une enregistrement de ressource (RR) particulier. Leur mise en œuvre était facultative et n'a jamais connue une large utilisation. IQUERY est donc maintenant obsolète, et les serveurs de noms DEVRAIENT retourner une erreur "Non mis en œuvre" quant une demande IQUERY est reçue.

 

4.   Considérations pour la sécurité

 

Dans la mesure où le présent document rend obsolète une opération qui était autrefois légale, on peut concevoir qui quelqu'un l'utilisait comme base d'une politique de sécurité. Cependant, comme le cours le plus logique à suivre pour une telle politique en face d'une absence de réponse positive de la part d'un serveur est de refuser l'autorisation/authentification, il est très improbable que le retrait de la prise en charge de IQUERY ouvre de nouveaux trous dans la sécurité.

 

Noter que si IQUERY n'est pas rendu obsolète, la sécurisation des réponses avec la sécurité du DNS (DNSSEC) devient extrêmement difficile sans signature numérique au vol.

 

5.   Considérations relatives à l'IANA

 

L'opcode IQUERY de 1 devrait être retiré de façon permanente, et n'être alloué à aucun opcode futur.

 

6.   Remerciements

 

Olafur Gudmundsson est l'instigateur de cette action. Matt Crawford, John Klensin, Erik Nordmark et Keith Moore ont contribué à améliorer la façon de formuler le traitement des fonctionnalités obsolètes décrites par une norme de l'Internet.

 

7.   Références

 

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

[RFC2026]   S. Bradner, "Le processus de normalisation de l'Internet -- révision 3", BCP 9, octobre 1996.

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

 

8.   Adresse de l'auteur

 

David C Lawrence

Nominum, Inc.

2385 Bay Rd

Redwood City CA 94063

USA

téléphone : +1.650.779.6042

mél : tale@nominum.com

 

9.   Déclaration complète de copyright

 

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

 

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

 

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

 

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.

 

Remerciement

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