Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Journée DNS Flag Day 2020

Publié le
Journée DNS Flag Day 2020

Conformité EDNS et TCP des zones inversées AFRINIC et des serveurs de noms ccTLD africains

Auteurs: Yazid Akanho, Malick Alassane, Mike Houngbadji et Amreesh Phokeer

 

dnsflagxLe système de noms de domaine (DNS) est l'un des services les plus critiques pour le fonctionnement quotidien d'Internet. Il permet de résoudre les noms en adresses IP et vice versa grâce à un système hiérarchique de serveurs distribués. En prélude à la DNS Flag Day 2020, une étude a été menée pour évaluer le niveau de préparation EDNS et TCP des serveurs DNS faisant autorité (Name Server - NS) sur les zones inversées des adresses IP allouées par AFRINIC à ses membres et serveurs faisant autorité des domaines ccTLD africains. Une telle étude permet d'évaluer le niveau de conformité DNS en Afrique avec les bonnes pratiques liées à l'EDNS, mais aussi de mettre en évidence divers aspects connexes des bonnes pratiques et des normes DNS tels que la localisation, la répartition géographique, la résilience, et IPv6 l'accessibilité ou l'accessibilité de ces serveurs faisant autorité.

À propos de DNS Flag Day

Le  DNS Flag Day est une initiative née de la volonté commune des fournisseurs et opérateurs DNS de rendre le DNS plus fiable, résilient et évolutif. Le premier DNS Flag Day a eu lieu le 1er février 2019 et était dédié à l'étude du niveau de configuration de l'extension EDNS sur des serveurs DNS faisant autorité dans le monde entier.

Pour 2020, le DNS Flag Day prévoit de vérifier deux éléments: d'une part, la taille du buffer EDNS (qui ne doit pas dépasser 1232 octets pour éviter la fragmentation des réponses DNS en UDP), et d'autre part, la possibilité de communiquer en mode TCP entre le client et le serveur DNS.

À propos d'EDNS

EDNS, abréviation de Extension Mechanisms for DNS, est défini dans la RFC 6891, comme une extension du protocole DNS, pour l'échange d'informations entre clients (résolveurs) et serveurs. Bien qu'EDNS ait diverses fonctions, son objectif principal était à l'origine de permettre la prise en charge de DNSSEC, qui fournit une sécurité cryptographique pour l'infrastructure DNS. 

EDNS a été conçu pour être rétrocompatible, ce qui signifie qu'il ne devrait pas affecter les performances des serveurs plus anciens ne prenant pas en charge EDNS. Dans la pratique, cependant, de nombreux serveurs se sont révélés incompatibles avec EDNS, ce qui a obligé les développeurs de résolveurs à ajouter toutes sortes de solutions de contournement à leur code pour permettre aux clients et aux serveurs de continuer à échanger le trafic DNS sans interruption. Un serveur compatible EDNS est donc un serveur qui prend en charge l'extension EDNS ou est capable de l'ignorer selon la spécification.

Vérification de la compatibilité EDNS globale

Afin d'évaluer la compatibilité EDNS globale d'un serveur faisant autorité, ce dernier doit être soumis à plusieurs tests décrit en détail ici. L'Internet System Consortium (ISC) a également développé et publié une série de Outils de test de conformité DNS permettant, entre autres, aux registres et bureaux d'enregistrement de vérifier la conformité du protocole DNS s'exécutant sur les serveurs auxquels ils délèguent des zones. 

 

 TesteCommand
DNS simple creuser + norec + noedns soa zone @server
EDNS ordinaire dig + norec + edns = 0 soa zone @ serveur
EDNS - Version inconnue creuser + norec + edns = 100 + noednsneg soa zone @server
EDNS - Option inconnue dig + norec + ednsopt = 100 zone soa @ serveur
EDNS - Drapeau inconnu dig + norec + ednsflags = 0x80 zone soa @ serveur
EDNS - DO = 1 (DNSSEC) creuser + norec + dnssec soa zone @server
EDNS - Réponse tronquée dig + norec + dnssec + bufsize = 512 + ignorer dnskezone @server
EDNS - Version inconnue avec option inconnue dig + norec + edns = 100 + noednsneg + ednsopt = 100 zone soa @ serveur

 

Résultats préliminaires

Conformité EDNS dans le DNS inversé AFRINIC

Au 15 juin 2020, il y avait 38,945 IPv4 zones inversées et 348 IPv6 zones inversées connues d'AFRINIC. Ces zones sont définies par les membres qui ont reçu des préfixes IP du registre. Un total de 3604 (uniques) serveurs de noms faisant autorité (NS) fournissent une résolution inverse pour la zone d'adressage IP globale (v4 et v6) administrée par AFRINIC: 3224 NS gèrent le IPv4 l'espace, tandis que 61 NS gèrent le IPv6 space et 319 NS fournissent une résolution inverse pour les blocs v4 et v6 du registre Internet régional.

Concernant la compatibilité EDNS globale des serveurs testés, seuls 1.78% sont rigoureusement compatibles sur tous les paramètres EDNS testés pour les NS des zones inversées AFRINIC, c'est-à-dire que tous les tests renvoient exactement les réponses attendues et que la taille du cache EDNS est comprise entre 512 et 1232 octets. En fait, aucune valeur fixe n'est retenue pour la configuration du tampon EDNS. La RFC6891 définit une taille maximale de 4096 octets. Cependant, pour éviter la fragmentation des réponses DNS, une valeur comprise entre 1220 et 1232 octets est recommandée; la raison principale étant que le MTU sur une liaison Ethernet est de 1500 octets. Les organisateurs du DNS Flag Day 2020 recommandent 1,232 octets.

Cependant, cela doit être relativisé car environ 75% des serveurs testés pour les zones inversées supportent EDNS0 avec un buffer compris entre 512 et 4096 octets, ce qui est déjà très encourageant. Nous avons constaté que sur 3604 NS, 872 (25.4%) ont renvoyé une erreur avec le statut: REFUSED.

taille du tampon edns

Figure 1. Distribution des tailles de tampon pour AFRINIC Reverse DNS

 

Conformité EDNS dans les ccTLD africains

Au 15 juin 2020, 54 ccTLD servis par 225 NS uniques sont comptés sur le continent africain. Un seul des NS du ccTLD .cm (benoue.camnet.cm.) N'avait pas d'enregistrement de type A ou AAAA. 81 NS étaient IPv4 seulement et 143 étaient à double empilement.

Nous n'avons pas pu récupérer les tailles de tampon EDNS pour 53.8% des NS dans les ccTLD africains, soit à cause d'un problème de réseau ou de timeout, ce qui était assez surprenant. Les résultats pour le reste de la distribution sont les suivants: 82 (36.4%) 4096, 16 (7.1%) 512, 5 (2.2%) 1680 et 1 (0.4%) 512 octets.

 

taille du tampon edns sur les serveurs de noms cctld

Figure 2. Distribution des tailles de tampon pour les ccTLD

 

En ce qui concerne la conformité TCP pour les ccTLD africains, il est assez difficile d'évaluer avec précision le nombre réel de serveurs de noms faisant autorité qui peuvent répondre aux requêtes DNS en utilisant TCP. Cependant, nous avons reçu des réponses de 43.55% de ces serveurs utilisant TCP.

Un autre élément important du DNS est que les serveurs de noms doivent être capables de traiter les requêtes DNS en mode TCP. La RFC1035 spécifie qu'un serveur de noms DNS doit être capable de gérer les requêtes DNS en utilisant TCP ou UDP sur le port 53. Cependant, le protocole UDP a toujours été principalement utilisé pour sa simplicité et sa rapidité.

Avec l'introduction de DNSSEC en particulier, la nécessité de communiquer via TCP est devenue nécessaire car les réponses DNS peuvent désormais être supérieures à 512 octets. Au total, nous avons constaté que 71.7% des serveurs de noms de zone inversés AFRINIC résolvent les demandes envoyées via TCP. Cependant, il est difficile de clarifier si c'est le serveur qui n'est pas configuré pour répondre aux requêtes TCP ou si un pare-feu situé entre le client et le serveur qui rejette ce type de trafic (malheureusement, plusieurs administrateurs réseau considèrent toujours que DNS ne doit travailler sur UDP).

Conclusion

Pour résumer, dans le groupe NS de la zone inverse, 25.4% des serveurs ne prennent pas en charge l'extension EDNS. Du côté des ccTLD, le pourcentage est double, autour de 54%. Dans les deux cas, il s'agit de serveurs fonctionnant avec une version logicielle obsolète ou parce que le paramètre EDNS est désactivé dans leur configuration, ce qui n'est pas recommandé. Au total, nous avons constaté que 71.7% des serveurs de noms de zone inversés AFRINIC résolvent les demandes envoyées via TCP contre 43.55% dans le cas des ccTLD. Cette étude a permis d'obtenir des résultats pertinents et d'avoir une meilleure visibilité sur le niveau de mise en œuvre de plusieurs recommandations et bonnes pratiques actuelles en Domain Name System sur le continent africain telles que EDNS et l'appui TCP entre autres.

Clause de non-responsabilité

Le rapport suivant a été produit à un moment précis dans le temps et vise à fournir un aperçu général de la conformité avec EDNS en Afrique. Les résultats dépendent de l'accessibilité du serveur DNS. Des problèmes de réseau au moment de l'expérience peuvent avoir introduit des faux positifs.

Remerciements

Cette étude a été sponsorisée par AFRINIC dans le cadre du Programme AFRINIC Research Collaboration (ARC).

Nous remercions Amreesh Phokeer, directeur de recherche chez AFRINIC, pour son soutien et ses conseils dans ce projet.

Print Friendly, PDF & Email
Dernière modification le -