DNS et LLMNR

Les DNS et IPv6

Comme évoqué plus haut, nous allons étudier maintenant les conséquences d’IPv6 sur le paramétrage et l’utilisation des serveurs de noms (DNS).

C’est le document RFC3596 d’octobre 2003 qui présente les modifications apportées par IPv6.

La modification principale réside dans la création d’un nouvel enregistrement DNS permettant l’enregistrement d’une adresse IPv6 sous un nom : il s’agit de l’enregistrement de type AAAA. La valeur d’identification du type AAAA est 28 en décimale.

Voici des exemples de déclaration de serveurs dans le domaine exemples.org :

droopy-v6 10800 IN AAAA 2001:4b98:dc0:43:216:3eff:fe4b:87e0 
jerry-v6 10800 IN AAAA 2001:41d0:2:657d:0:25:2:2012 
jerry 10800 IN A 173.246.100.78 
jerry 10800 IN AAAA 2001:41d0:2:657d:0:25:2:2012
 

Nous pouvons remarquer qu’il est possible de déclarer un même nom mais sous deux types (A et AAAA) différents. Cela permet d’utiliser un seul nom et c’est le critère de recherche (A ou AAAA) qui fera la différence.

Nous pouvons évidemment choisir d’utiliser un nom pour l’adresse IPv6 et un nom pour l’adresse IPv4. Ainsi, le serveur jerry peut aussi être joignable en IPv6 sous le nom arbitraire jerry-v6.exemples.org.

Nous pouvons donc obtenir :

[root@jerry ~]# dig  jerry.exemples.org...

Mécanisme Happy EyeBalls (Windows 8, 10 et Server 2012)

Ce mécanisme décrit dans le RFC 6555 d’avril 2012 cherche à résoudre un problème qui intervient régulièrement en mode dual-stack (la carte Ethernet gère à la fois des adresses IPv4 et IPv6) et qui engendre des délais ou dysfonctionnements lors de connexions vers Internet.

Le problème survient quand :

Dans ce cas, comme le veut maintenant le protocole, c’est l’adresse IPv6 qui est choisie comme destination (par exemple dans le navigateur). Or, la connexion IPv6 ne pouvant aboutir, l’interrogation du site va au mieux être très lente et au pire impossible. Le résultat varie en effet selon les navigateurs et les OS (cf. dernier lien en fin de chapitre).

Ce mécanisme est donc un processus de décision qui intervient en plusieurs étapes :

Le protocole de résolution locale LLMNR (Link Local Multicast Name Resolution)

Ce protocole est défini dans le RFC 4795 de janvier 2007. Il permet comme le nom le laisse entendre une résolution de nom à l’échelle du lien local. Il fonctionne sur IPv4 et IPv6 avec des enregistrements très proches des enregistrements DNS mais c’est surtout sous IPv6 qu’on le voit à l’œuvre lorsque l’on fait des captures de paquets sur un lien.

Au départ LLMNR n’existait que sous Windows (depuis Vista) mais il existe aussi des implémentations sous Linux.

C’est le port 5355 qui est utilisé en UDP pour les requêtes en multicast (adresse 224.0.0.252 en IPv4 et ff02 ::1 :3 en IPv6).

Voici la structure globale du paquet :

L’en-tête ayant lui-même la structure suivante :

Les champs remarquables sont :

Si nous capturons les paquets émis sur le réseau lors d’un simple ping, par exemple, vers un nom d’hôte alors qu’aucun serveur DNS n’est configuré ou que l’enregistrement DNS est inexistant, nous pourrons...