EDNS
Cet article est une ébauche concernant Internet.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Extension mechanisms for DNS (EDNS) est une extension du protocole Domain Name System qui permet d'augmenter la taille de certains paramètres. La première série d'extensions a été publiée en 1999 par l'Internet Engineering Task Force (IETF) dans la RFC 2671[1] sous le nom EDNS0[2], puis mis à jour en RFC 6891.
Sommaire
1 Motivation
2 Fonctionnement
3 Exemple
4 Applications
5 Problèmes
6 Notes et références
Motivation |
Le système DNS a été développé dans les années 1980 et a été amélioré depuis lors, tout en conservant la compatibilité avec les versions antérieures du protocole.[réf. nécessaire]
Les limitations de taille de certains champs, code de retour et types de label du protocole original ont commencé à poser des problèmes pour le développement de nouvelles fonctionnalités. Les messages DNS étaient limités à 512 octets en UDP[3] et le recours à TCP mandaté par la norme pour des messages plus volumineux aboutit à une plus grande surcharge. En 1998, Paul Vixie propose d'étendre le DNS avec de nouveaux codes et de permettre des tailles de paquets plus élevées en UDP, tout en restant compatible avec les implémentations existantes[4].
Fonctionnement |
Puisqu'aucun nouveau code ne peut être ajouté dans l'en-tête DNS, l'identification d'une requête étendue est réalisée grâce à un pseudo resource-record (RR), OPT. Ce RR n'est utilisé que dans la transmission et est absent des zones. Les clients EDNS incluent ce RR pour indiquer qu'ils prennent en charge cette extension. Si le serveur ne prend pas en charge cette extension, ce RR sera ignoré, ce qui procure la rétrocompatibilité.
Le pseudo-record OPT fournit 16 codes additionnels et étend l'espace disponible pour la réponse. La taille maximale du paquet UDP et la version EDNS (toujours 0 actuellement) sont contenues dans le RR OPT. Un champ de données de taille variable permet des extensions ultérieures.
Le protocole original prévoyait deux types de labels en fonction des deux premiers bits du paquet DNS : 00 (label standard) et 11 (label comprimé). EDNS définit le label 01 (label étendu). Les six bits suivants sont utilisables pour définir d'autres labels étendus.
En cas de non-réponse à une requête utilisant EDNS, une nouvelle tentative de résolution est faite sans EDNS par le client (c'est à dire en mode dégragé, en mode « fallback »). Si la taille de la réponse dépasse les 512 octets, une réponse tronquée est envoyée par le serveur avec un drapeau « TC » (Truncated) dans l'en-tête DNS, annonçant que cette réponse est incomplète. Le client aura alors recours à une nouvelle résolution en utilisant TCP.
Exemple |
Voici un exemple de pseudo-record OPT, tel qu'il est affiché par la commande dig :
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
Applications |
La prise en charge d'EDNS est essentielle pour les extensions de sécurité DNSSEC[5]. Elle est également souhaitable pour IPv6, la taille des réponses pouvant excéder 512 octets quand des RR AAAA sont présents.
La taille de la liste des serveurs racine du DNS dépasse les 512 octets à la suite de l'ajout des adresses IPv6 puis des signatures DNSSEC[6].
Problèmes |
Certains pare-feux anciens ou mal configurés bloquent les paquets UDP DNS qui dépassent 512 octets. En l'absence de réponse à une requête EDNS, le serveur la réédite sans l'extension, ceci cause des délais anormaux dans la résolution des noms.
Par ailleurs, pour les réponses les plus grosses (notamment utilisant DNSSEC)[7], des lenteurs similaires liées à de nouvelles tentatives de résolution peuvent être observées[8] dans les contextes suivants[9]:
- la taille des paquets peut dépasser la MTU habituelle sur Internet (1500 octets) et entrainer la création de fragments IP, lesquels peuvent être bloqués par certains pare-feux ou routeurs mal configurés
- la taille des paquets peut dépasser la MTU certains liens sur des réseaux d'accès (par exemple 1492 pour un client en PPPoE), ce qui est censé être géré par l'usage du Path MTU Discovery (PMTUd), mais qui en pratique peut entrainer des paquets perdus
Notes et références |
(en) Request for Comments no 2671.
RFC 2671, Extension Mechanisms for DNS (EDNS0), Paul Vixie, The Internet Society (août 1999)
(en) P.V. Mockapetris, « Domain names - implementation and specification », sur tools.ietf.org (consulté le 16 mars 2018)
(en) Paul Vixie <paul@vix.com>, « Extensions to DNS (EDNS) », sur tools.ietf.org (consulté le 15 mars 2018)
(en) Larson, Matt et Massey, Dan, « Protocol Modifications for the DNS Security Extensions », sur tools.ietf.org (consulté le 16 mars 2018)
dig @a.root-servers.net . ns +edns=0indique 671 octets en février 2011. (L'interrogation des serveurs racine sans edns0 retournant une réponse volontairement inférieure à 512 o)
(en-US) « Dealing with IPv6 fragmentation in the DNS | APNIC Blog », APNIC Blog, 22 août 2017(lire en ligne)
« Refinements to EDNS fallback behavior can cause different outcomes in Recursive Servers | Internet Systems Consortium Knowledge Base », sur deepthought.isc.org (consulté le 15 mars 2018)
(en) Geoff Huston, Joao Damas, « DNS over IPv6 - A Study in Fragmentation » [PDF], sur APNIC, septembre 2017(consulté le 15 mars 2018)
Portail de l’informatique
