EDNS

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.

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

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égradé, 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.

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

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

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 (1 500 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