Tutoriel sur le DNS Unbound

Un serveur DNS de validation, récursif et de mise en cache

Unbound est un serveur DNS récursif, de validation et de mise en cache très sûr, principalement développé par NLnet Labs, VeriSign Inc, Nominet et Kirei.

Le logiciel est distribué gratuitement sous la licence BSD.

Les binaires sont écrits avec une grande attention à la sécurité, un code C serré et un état d’esprit de paranoïa aigüe.

Les caractéristiques d’Unbound

La conception d’Unbound est un ensemble de composants modulaires qui intègrent des caractéristiques telles que :

• la validation de la sécurité renforcée (DNSSEC)
• la version 6 du protocole Internet (IPv6)
• et une API de bibliothèque de résolution de clients comme partie intégrante de l’architecture

Compatibilité de Unbound

Écrit à l’origine pour un système d’exploitation de type Unix compatible Posix, Unbound fonctionne actuellement sous :

• FreeBSD
• OpenBSD
• NetBSD
• Linux
• Microsoft Windows

L’installation et la configuration d’Unbound

Les inconvénients de Bind par rapport à Unbound

BIND, également connu sous le nom de named, devient extrêmement gonflé de code, lent et trop compliqué. La complication conduit à des exploits de sécurité et plus de vingt des soixante-dix derniers bogues critiques de FreeBSD sont dus à BIND lui-même.

L’autre problème est que BIND est utilisé pour environ 70% des serveurs DNS mondiaux, ce qui conduit à un environnement de monoculture.

Lorsqu’une attaque ou un exploit se produit, il est avantageux pour l’attaquant de s’en prendre aux logiciels les plus utilisés.

En comparaison, Unbound est un serveur de noms DNS incroyablement rapide et sûr qui, en raison de sa petite taille, peut facilement faire l’objet d’un audit de sécurité du code.

Quelques définitions et quelques exemples.

Fonctions DNS communes

Avant d’examiner les exemples de configuration, nous devons comprendre les fonctions de base disponibles par un serveur DNS moderne. Vous pourrez ensuite décider du type de serveur DNS que vous souhaitez et passer directement aux configurations ci-dessous.

Notez que vous pouvez combiner plusieurs fonctions ensemble dans un seul serveur DNS.

• Par exemple, vous pouvez avoir un serveur DNS de mise en cache
• un serveur DNS de mise en cache récursif
• un serveur DNS de mise en cache récursif de validation
• un serveur DNS de mise en cache récursif de validation faisant autorité, etc.

Serveur DNS récursif

Les serveurs de noms en cache stockent les résultats des requêtes DNS pendant une période de temps déterminée dans la configuration (time-to-live) du nom de domaine en question.

Les serveurs de noms récursifs résolvent toute requête qu’ils reçoivent, même s’ils ne font pas autorité pour la question posée, en consultant le ou les serveurs qui font autorité pour la requête.

La mise en cache des serveurs de noms, comme on le verra dans la section suivante, améliore l’efficacité du DNS en réduisant le trafic DNS sur Internet et en diminuant la charge des serveurs de noms faisant autorité, en particulier les serveurs de noms racine.

Comme les serveurs DNS locaux peuvent répondre plus rapidement aux questions, ils augmentent également les performances des applications des utilisateurs finaux qui utilisent le DNS.

Un serveur DNS récursif parcourra, au nom du client, les chemins du DNS sur Internet pour récupérer la réponse.

Une simple requête telle que « Quelle est l’adresse IP de Desgeeksetdeslettres.com » à un serveur DNS qui prend en charge les requêtes récursives mais qui ne fait pas autorité pour calomel.org ressemblerait à ce qui suit :

• Le résolveur de votre client envoie une requête « Quelle est l’adresse IP de Desgeeksetdeslettres.com » à un serveur DNS configuré localement comme Unbound.
• Le serveur DNS Unbound recherche Desgeeksetdeslettres.com dans les tables locales (son cache) – non trouvé si nous n’avons jamais demandé ce nom d’hôte auparavant.
• Unbound DNS envoie une requête à l’un des serveurs racine dans son fichier root.hints.
• Le serveur racine répond en renvoyant aux serveurs du TLD « .com ».
• Unbound envoie une requête « Quelle est l’adresse IP Desgeeksetdeslettres.com » à l’un des serveurs du TLD .com.
• Le serveur TLD répond en renvoyant aux serveurs de noms faisant autorité pour Desgeeksetdeslettres.com à DynDNS.org.
• Unbound envoie la requête « Quelle est l’adresse IP de Desgeeksetdeslettres.com » à un serveur de noms faisant autorité pour Desgeeksetdeslettres.com.
• Le fichier de zone faisant autorité chez DynDNS définit un enregistrement « A » qui contient l’adresse IP de Desgeeksetdeslettres.com. DynDNS renvoie l’adresse IP de Desgeeksetdeslettres.com.
• Unbound reçoit l’adresse ip de Desgeeksetdeslettres.com et renvoie la réponse au résolveur du client. La transaction est terminée.

Comme vous pouvez le voir, une requête standard pour Desgeeksetdeslettres.com est assez longue et demande un peu de temps.

C’est pourquoi nous aimons garder une copie locale de la réponse sur notre serveur DNS local Unbound. Cette copie locale est appelée copie « en cache », ce qui nous amène à la section suivante.

Serveur DNS en cache

Les résultats du cache sont renvoyés en une ou deux millisecondes, tandis que les requêtes récursives peuvent prendre des centaines de millisecondes ou plus.

Serveur DNS de validation

Un serveur DNS de validation est simplement un résolveur qui vérifie que la réponse qu’il a reçue est aussi correcte qu’elle peut être sûre.

Cette vérification est généralement effectuée à l’aide de Secure DNS (DNSSEC) ou en utilisant des bits aléatoires codés 0x20 dans la requête pour déjouer les tentatives d’usurpation.

La validation peut également comprendre des contrôles de l’intégrité des données renvoyées ou s’assurer qu’un hôte distant n’essaie pas de renvoyer une adresse IP illégale pour un nom d’hôte externe (dnsspoof).

➜ En cas d’attaque d’empoisonnement du cache

Pour effectuer une attaque d’empoisonnement du cache par exemple, l’attaquant exploite une faille dans le logiciel DNS.

Si le serveur ne valide pas correctement les réponses DNS pour s’assurer qu’elles proviennent d’une source faisant autorité (par exemple en utilisant DNSSEC), le serveur finira par mettre en cache les entrées incorrectes localement et les servira à d’autres utilisateurs qui feront la même demande.

➜ La paranoïa en matière de sécurité DNS

La paranoïa en matière de sécurité DNS est également une raison pour laquelle vous devez vraiment avoir confiance dans tout serveur de cache de résolution que vous ne contrôlez pas.

Nous aimons avoir toujours un serveur DNS sous notre contrôle pour interroger les serveurs racine et remonter jusqu’au serveur faisant autorité du domaine.

De cette façon, nous sommes sûrs de la configuration, car nous sommes les administrateurs, et nous avons confiance dans les serveurs DNS qui mettent en cache les données grâce à la conception de sécurité que nous avons mise en place.

Si vous configurez votre résolveur DNS pour interroger le cache dns du FAI local, vous devez vraiment, vraiment faire confiance à son personnel et à la sécurité de sa configuration.

Du point de vue d’un attaquant, le cache DNS d’un FAI est la cible parfaite. L’attaquant n’a besoin d’empoisonner qu’un seul serveur DNS et toutes les requêtes de tous les utilisateurs de ce FAI vont aux machines compromises par l’attaquant.

Ce scénario s’est déjà produit une fois pour les serveurs de cache DNS d’AT&T et il se reproduira malheureusement.

Serveur DNS faisant autorité

Un serveur DNS faisant autorité est simplement le propriétaire principal du nom d’hôte.

Lorsqu’un domaine est enregistré auprès d’un bureau d’enregistrement de noms de domaine, l’administrateur de zone fournit une liste de serveurs de noms (généralement au moins deux, pour des raisons de redondance) qui font autorité pour la zone qui contient le domaine.

Le bureau d’enregistrement fournit les noms de ces serveurs au registre du domaine de premier niveau contenant la zone. Le registre du domaine configure à son tour les serveurs de noms faisant autorité pour ce domaine de premier niveau avec des délégations pour chaque serveur de la zone.

Si le nom de domaine complet d’un serveur de noms pour une zone apparaît, l’administrateur de la zone fournit les adresses IP de ce serveur de noms, qui sont installées dans la zone-mère sous forme d’enregistrements collés.Sinon, la délégation consiste en la liste des enregistrements NS pour cette zone.

Un serveur de noms indique que sa réponse fait autorité en définissant le bit Authoritative Answer (AA) dans la réponse à une requête sur un nom pour lequel il fait autorité.

Les serveurs de noms qui fournissent des réponses pour lesquelles ils ne font pas autorité (par exemple, les serveurs de noms pour les zones mères), n’activent pas le bit AA.

Unbound peut être configuré pour fournir des noms faisant autorité pour un réseau local. 

CONSEIL : Assurez-vous de jeter un coup d’œil à notre script simple de vérification DNS. Il vérifiera la résolution des noms de votre réseau local en amont et en aval. C’est un moyen très rapide de vous assurer que votre configuration DNS est correcte.

Installation du DNS Unbound

La première étape consiste à installer Unbound

Nous vous suggérons d’installer Unbound via votre gestionnaire de paquets pour une installation facile et des mises à jour régulières de la version.

La plupart des systèmes d’exploitation modernes ont des paquets pré-compilés (rpm, deb, tgz). Vous pouvez toujours installer Unbound à partir des sources si vous le souhaitez.

Quelle que soit la méthode d’installation choisie, vous devez obtenir la version la plus récente possible.

Quelques lignes de gestionnaire de paquets pour vous aider à l’installation de Unbound

## FreeBSD 12
 pkg install unbound     (for libevent enabled Unbound)
  -OR-
 /usr/sbin/local-unbound (base install)

## FreeBSD 11 and earlier
 portmaster dns/unbound
  -OR-
 pkg install unbound

## CentOS
 yum install unbound

## Ubuntu
 apt-get install unbound

## OpenBSD
 pkg_add -i unbound

Réflexions, idées et théories sur le DNS Unbound

Unbound est le parfait soldat de première ligne pour les requêtes DNS des clients LAN. Il est rapide, fiable, stable et très sûr.

BIND (named) ou NSD (Name Server Daemon) peuvent être conservés sur le réseau dorsal pour servir de DNS faisant autorité au cluster Unbound.

De cette façon, vous gardez vos données DNS primaires séparées et non encombrées sur le serveur BIND ou NSD pendant que les serveurs du Unbound cluster se chargent :

• de la résolution
• de la mise en cache
• de la validation des zones pour les clients

Confidentiel :

Utilisez un VPN pour cacher votre adresse IP et refuser qu'on vous piste.

Anonyme :

Ce VPN chiffre votre connexion internet et maquille votre localisation en ligne.

L’idée est d’avoir quelques serveurs DNS de validation, récursifs et de mise en cache de Unbound que les clients du réseau local peuvent interroger.

Utilisez ensuite BIND (named) comme serveur faisant autorité, qui ne peut résoudre que les noms internes du réseau local. Les clients du réseau local n’accéderont JAMAIS au serveur DNS BIND et BIND ne sortira jamais sur Internet.

• La seule tâche de BIND est de servir les noms internes au groupe de serveurs DNS non liés.
• Le cluster Unbound desservira tous les clients du réseau local.
• Si Unbound doit résoudre un ip privé, il demandera au serveur BIND des ip et mettra ensuite la réponse en cache.
• Si le client a besoin d’une adresse IP externe, par exemple de google.com ou cnn.com, Unbound interrogera récursivement les serveurs DNS racine d’Internet et mettra la réponse en cache.

Foire Aux Questions sur Unbound

Le temps de fonctionnement du système est-il critique pour le fonctionnement d’Unbound ?

Oui. Unbound est très paranoïaque au sujet de ses enregistrements DNS.

Si un enregistrement est périmé, ou pire encore, si l’enregistrement existe à une date ultérieure, Unbound ne résoudra pas ce domaine correctement.

Un problème courant est que vous devez redémarrer le système et que l’heure du BIOS est incorrecte. Unbound est alors lancé au démarrage et utilise l’heure système actuelle incorrecte.

Vous devez alors régler l’heure correcte manuellement. En attendant, soit tous vos enregistrements dns sont expirés parce que l’heure a été fixée dans le passé, soit les enregistrements sont illégaux puisque l’heure est fixée dans le futur.

Assurez-vous que l’heure système de votre machine est aussi correcte que possible en utilisant le NTPD d’un serveur de temps GPS. Démarrez ensuite Unbound lorsque l’heure est correcte.

Quel générateur de nombres aléatoires PRNG utilise Unbound ?

Unbound utilise un générateur de nombres aléatoires de puissance cryptographique.

Le générateur arc4random() d’OpenBSD est utilisé ou Yarrow sur FreeBSD.

Cela signifie que prédire les nombres aléatoires générés par Unbound équivaut à craquer un code de chiffrement. Le générateur de nombres aléatoires est ensemencé d’entropie.

L’entropie réelle du système /dev/random est utilisée pour amorcer le générateur de nombres aléatoires. Ainsi, les valeurs de départ du générateur de nombres aléatoires ne peuvent pas être facilement prédites.

L’installation du paquetage OpenBSD de Unbound utilise /dev/arandom à la place pour une entropie plus aléatoire et une création plus rapide de l’amorçage.

Qu’est-ce que la capitalisation aléatoire dns-0x20 ?

Lorsqu’Unbound envoie une requête à un serveur distant, il envoie la chaîne du nom d’hôte en caractères aléatoires supérieurs et inférieurs. Le serveur distant doit résoudre le nom d’hôte comme si tous les caractères étaient des minuscules.

Le serveur distant doit ensuite renvoyer la requête à Unbound en utilisant les mêmes caractères aléatoires supérieurs et inférieurs que ceux envoyés par Unbound.

Si les caractères du nom d’hôte dans la réponse sont au même format que la requête, alors le contrôle dns-0x20 est satisfait.

Les attaquants qui espèrent empoisonner un cache DNS Unbound doivent donc deviner l’encodage mixte de la requête et le moment de la réponse dns de retour en plus de tous les autres champs requis dans une attaque d’empoisonnement DNS.

dns-0x20 augmente considérablement la difficulté de l’attaque.

Comment puis-je facilement surveiller le trafic DNS en temps réel ?

Essayez un programme appelé « dnstop« .

Il est disponible par l’intermédiaire de la plupart des gestionnaires de paquets. Une fois installé, il suffit d’exécuter le binaire avec l’argument de l’interface que vous voulez surveiller le trafic DNS.

Par exemple, nous exécuterons « dnstop em0 » pour surveiller le trafic sur l’interface em0 externe basée sur Intel.

Il y a quelques pages d’options dans dnstop qui peuvent être accessibles en utilisant les touches numériques. La page de l’auteur contient quelques exemples de sorties d’écran DnsTop.

Le basculement dans /etc/resolv.conf est trop lent. Que puis-je faire ?

Le délai normal de basculement d’un serveur de noms à un autre dans le fichier /etc/resolv.conf est de 5 secondes.

Ce délai est un peu trop long. Vous pouvez utiliser la directive « options » pour fixer le délai d’attente à 3 dixièmes de seconde.

Cet exemple permet également :

• de « tourner » pour équilibrer la charge des requêtes de serveur de noms
• de régler les tentatives sur une seule pour essayer un serveur de noms une seule fois avant de passer à la suivante
• de fixer le seuil du nombre de points qui doivent apparaître dans un nom avant qu’une première requête absolue ne soit effectuée

domain domain.lan
search domain.lan domain.lan2 domain.lan3 domain.lan4
nameserver 192.168.0.1
nameserver 192.168.0.2
options ndots:1 timeout:0.3 attempts:1 rotate

Qu’est-ce que le DNS Cache Poisoning ?

L’empoisonnement d’un résolveur DNS désigne l’acte d’insérer des données fausses, souvent malveillantes, dans le cache du résolveur.

Cela peut entraîner la redirection des visiteurs d’un site web (par exemple leur site bancaire) qu’ils pensaient visiter vers un autre site web, par exemple un site de phishing.

Le DnsSpoof est également considéré comme un empoisonnement du cache.

➜ Différence entre l’empoisonnement de cache et le Dnsspoof

• La différence est que l’empoisonnement est l’acte d’insérer de mauvaises données de manière malveillante
• et que le dnsspoof est l’insertion de données que nous connaissons

Il s’agit d’une distinction très fine qui dépend de la personne qui interroge les données.

Unbound met en œuvre un certain nombre de méthodes pour ajouter des bits aléatoires afin de sécuriser les requêtes contre une déviation malveillante.

➜ Comment ajouter du caractère aléatoire ?

• Le moyen le plus important pour ajouter du caractère aléatoire est de faire varier les numéros de port à partir desquels la question est posée
• Un autre moyen est d’utiliser un hack qui randomise les bits inutilisés dans le nom de la requête

Unbound utilise 16 bits pour la randomisation du port. Unbound veille à ce qu’un port tiré au hasard soit utilisé pour une requête. Ainsi, chaque requête obtient un numéro de port fraîchement tiré au hasard.

➜ La DNSSEC

Une véritable protection, où vous n’êtes pas soumis aux caprices du hasard, est obtenue en utilisant le DNSSEC.

La DNSSEC utilise des signatures numériques pour protéger les données. Avec la DNSSEC, il n’y a aucun risque d’empoisonnement, indépendamment du nombre de bits aléatoires utilisés.

• Unbound met en œuvre la norme DNSSEC comme spécifié dans les RFC ( RFC4034, RFC4035 )
• Unbound peut agir en tant que validateur
• Il peut vérifier les signatures numériques jointes dans les réponses
• Bien entendu, le propriétaire du nom de domaine doit avoir inséré ces signatures numériques en premier lieu.

En l’absence de DNSSEC, unbound tente d’offrir une très bonne sécurité. Sans signature numérique, la randomisation et le filtrage sont actuellement les seules options.