1. Introduction
Les résolveurs récursifs DNS doivent fournir des réponses à toutes les requêtes de leurs clients, même celles concernant des noms de domaine qui n'existent pas. Pour chaque nom demandé qui se trouve dans un domaine de premier niveau (TLD) qui n'est pas dans le cache du résolveur récursif, le résolveur doit envoyer une requête à un serveur racine pour obtenir les informations pour ce TLD ou pour découvrir que le TLD n'existe pas. La recherche montre que la grande majorité des requêtes allant vers la racine concernent des noms qui n'existent pas dans la zone racine.
De nombreuses requêtes des résolveurs récursifs vers les serveurs racines obtiennent des réponses qui sont des renvois vers d'autres serveurs. Des tiers malveillants pourraient être en mesure d'observer ce trafic sur le réseau entre le résolveur récursif et les serveurs racines.
Les principaux objectifs de cette conception sont de fournir des réponses plus fiables aux requêtes vers la zone racine lors d'attaques réseau affectant les serveurs racines et d'empêcher que les requêtes et les réponses ne soient visibles sur le réseau. Cette conception aura probablement peu d'effet sur l'obtention de réponses plus rapides au résolveur stub pour les bonnes requêtes sur les TLD, car le TTL pour la plupart des TLD est généralement de longue durée (de l'ordre d'un jour ou deux) et est donc généralement déjà dans le cache du résolveur récursif ; il en va de même pour les enregistrements NS racines.
La méthode décrite consiste à exécuter un serveur racine sur le même serveur que le résolveur récursif, en utilisant une adresse de bouclage ou en utilisant un mécanisme tel que des "vues" ou des "systèmes logiques" pour séparer les fonctions du résolveur récursif et du serveur racine.
1.1. Changements par rapport à la RFC 7706
La RFC 7706 exigeait explicitement qu'une instance de serveur racine soit exécutée sur l'interface de bouclage de l'hôte exécutant le résolveur de validation. Cependant, la RFC 7706 contenait également des exemples de configuration de logiciels courants n'utilisant pas l'interface de bouclage.
Ce document met à jour les exigences pour permettre à l'instance de serveur racine de s'exécuter sur l'interface de bouclage ou d'être une partie intégrée du logiciel de résolution.
1.2. Notation des exigences
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.