Le DNS (Domain Name System) est le nom du protocole et de la base de données permettant la traduction entre nom de domaine et adresse IP.

Une correspondance entre noms de domaines et adresses IP a toujours été désirable, même avant que le DNS soit utilisé.

• Les adresses IP sont difficiles à mémoriser : 5.39.82.35 (IPv4) et 2001:41d0:8:9423::1 (IPv6) pour hexagon.federez.net.
• Elles dépendent de la topologie : Si le réseau change, les noms restent les mêmes et pointent vers les nouvelles adresses IP
• Elles sont limitées à un type de connectivité : Contrairement à une adresse IP, un nom peut pointer vers plusieurs types d'adresses (IPv4, IPv6, etc).

À l'époque, la correspondance entre adresses IP et nom était fournie par un fichier hosts.txt répliqué depuis un serveur central vers chaque hôte du réseau (RFC 608). Cette solution ne passe pas à l'échelle aujourd'hui avec les milliards d'hôtes qui ont besoin de noms de domaine.

Grâce au DNS, aucun serveur n'est obligé de connaître toutes les correspondances entre noms et adresses. On dit que le système est réparti. En revanche, il n'est pas décentralisé car il y a une hiérarchie entre les serveurs DNS dans laquelle quelques serveurs racine sont au sommet.

On a tendance à penser que le DNS envoie les données uniquement en UDP sur le port 53 mais en réalité le TCP peut également être utilisé. En effet, originellement, les requêtes DNS étaient limitées à 512 octets en UDP (plus rapide que le TCP, allégeant la charge des serveurs et offrant des réponses plus rapides), le TCP était utilisé pour les requêtes plus longues. la RFC 5966 (en) détaille l'utilisation de TCP pour les résolutions DNS.

EDNS(0) a été mis en place pour étendre les tailles maximales de paramètres pour les DNS, ainsi se séparant de la limite des 512 octets initialement mise en place.

Sur le serveur, un fichier de zone décrit une zone du domaine. Ce fichier a une syntaxe définie par la RFC 1035 (section 5) et la RFC 1034 (section 3.6.1) et ne dépend pas du serveur utilisé.

Voici un exemple de fichier de zone :

; Ceci est un commentaire
$TTL 86400 ;; Time To Live : le temps maximum de mise en cache par défaut
@		IN SOA	ns.example.com. hostmaster.example.com. (
							2014033145; serial
							70000; refresh
							3600; retry
							604800; expire
							86400; minimum ttl
							)
$ORIGIN example.com. ;; nom de domaine de base
;; À partir d’ici, chaque ligne est un enregistrement
		NS	ns ;; correspond à ns.example.com. 
		NS	ns2. ;; Attention : ce nom n’existe pas. Ce n’est pas ns2.example.com
		MX	10	mail.example.com. ;; le nom fini par un point : c’est un nom complet 
		MX	20	mail2.example.com ;; le nom ne fini pas par un point : c’est mail2.example.com.example.com
@				IN	A	1.2.3.4 ;; @ n’est pas obligatoire
mail				IN	A	1.2.3.5
mail2				IN	A	1.2.3.6
ns.example.com.			IN	A	1.2.2.2
ns2.example.com			IN	A	1.2.1.2

Un enregistrement est une ligne de ce fichier et a la syntaxe suivante :

domaine		(TTL)	IN	TYPE	VALUE

la définition du TTL n’est pas obligatoire. IN signifie Internet. Le DNS était prévu pour d’autres types de réseau, mais en pratique, seul IN est utilisé.

• A : renseigne une adresse IPv4.
• AAAA : renseigne une adresse IPv6 (une IPv6 est quatre fois plus longue qu’une IPv4, il y a donc quatre fois plus de A).
• CNAME : crée un alias vers un autre nom.
• MX : renseigne le seveur de courriel associé au nom de domaine.
• NS : renseigne un serveur de nom, utilisé pour la délégation de zone. La valeur est un nom de domaine qui doit obligatoirement être lié à un enregistrement de type A ou AAAA (pas un CNAME).
• PTR : utilisé pour la résolution inverse
• TXT : peut contenir n’importe quel texte, entre guillemets doubles.

Le système des DNS n'a pas pris en compte la sécurité lors de sa création. Une étude de ses failles a été faite dans les années 2000 (rapportée dans la RFC3833 (en)). DNSSEC a été créé pour palier la plupart de ces failles.

Le serial est un numéro qui identifie la version de votre fichier de zone. Il est important de toujours l’augmenter à chaque modification. En effet, c’est sur ce nombre que se base les serveurs caches et esclave pour savoir si leur cache est toujours à jour. Si vous avez un serial inférieur ou égal à celui enregistré dans l’autre serveur, celui-ci ne mettra pas à jour votre zone. Il n’est en revanche pas nécessaire que le serial soit incrémenté de 1 à chaque fois. Par exemple, vous pouvez vous baser sur la date du jour et ajouter un nombre qui identifie la modification du jour : 2014030563 serait la 63^e modification du 5 mars 2014¹⁾.

La commande dig permet de demander la résolution d’un nom en recevant les informations liées à la question et la réponse obtenue. Voici un exemple :

$ dig federez.net
; <<>> DiG 9.9.2-P2 <<>> federez.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56715
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;federez.net.			IN	A

;; ANSWER SECTION:
federez.net.		86400	IN	A	160.228.155.65

;; AUTHORITY SECTION:
federez.net.		86400	IN	NS	ns.kimsufi.com.
federez.net.		86400	IN	NS	ns1.federez.net.
federez.net.		86400	IN	NS	ns0.federez.net.
federez.net.		86400	IN	NS	ns2.afraid.org.

;; ADDITIONAL SECTION:
ns0.federez.net.	172800	IN	A	5.39.82.35
ns0.federez.net.	172800	IN	AAAA	2001:41d0:8:9423::1
ns1.federez.net.	172800	IN	A	160.228.155.65

;; Query time: 5 msec
;; SERVER: 10.152.1.1#53(10.152.1.1)
;; WHEN: Mon Mar 31 13:01:54 2014
;; MSG SIZE  rcvd: 208

Il est possible de donner plus d’options à dig. Par exemple, pour utiliser un serveur de nom particulier :

$ dig federez.net @160.228.155.65
…
;; Query time: 8 msec
;; SERVER: 160.228.155.65#53(160.228.155.65)
;; WHEN: Mon Mar 31 13:03:18 2014
;; MSG SIZE  rcvd: 208

Par défaut, dig résout les addresses IPv4 et IPv6 si disponibles pour la zone. Il est possible de lui demander d’autres types d’enregistrement :

$ dig MX federez.net
…
;; ANSWER SECTION:
federez.net.		86400	IN	MX	20 quigon.federez.net.
federez.net.		86400	IN	MX	10 hexagon.federez.net.
…
;; ADDITIONAL SECTION:
hexagon.federez.net.	86400	IN	A	5.39.82.35
hexagon.federez.net.	86400	IN	AAAA	2001:41d0:8:9423::1
quigon.federez.net.	86400	IN	A	160.228.155.65
ns.kimsufi.com.		86261	IN	A	213.186.33.199
ns.kimsufi.com.		86261	IN	AAAA	2001:41d0:3:1c7::1
ns0.federez.net.	172661	IN	A	5.39.82.35
ns0.federez.net.	172661	IN	AAAA	2001:41d0:8:9423::1
ns1.federez.net.	172661	IN	A	160.228.155.65
ns2.afraid.org.		161	IN	A	208.43.71.243
…

On peut aussi lui demander de vérifier les zones en utilisant DNSSEC. Si la zone est validée, le flag ad est ajouté à la réponse :

$ dig +dnssec isc.org
; <<>> DiG 9.9.2-P2 <<>> +dnssec isc.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48401
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org.			IN	A

;; ANSWER SECTION:
isc.org.		60	IN	A	149.20.64.69
isc.org.		60	IN	RRSIG	A 5 2 60 20140423233241 20140324233241 4521 isc.org. m8GbfAz8vKK8yydCebWWhCJokZotqdoN8faZldTk8HAmC1L+KeLCAfvm 2k8rlW/HjNlN+VCh1WvvOhIB1DQ9XlWugPINWQJ/00e09b+3NS058Ztb Z9rYGgNUl5cHJsWfpNVLs0icifMRGiwGKXdM79GvUsMuO08+Kt4rQ5HQ 9KQ=
…

Comment un serveur récursif fait-il pour résoudre federez.net ? Imaginons que son cache est vide. Pour fonctionner, un serveur récursif doit connaître au moins un nom : ., aussi appelé la racine.
A partir de là, le serveur demande à . « qui est federez.net. ? ». Le serveur répond qu’il ne sait pas, mais qu’il est capable de trouver net.. Ensuite, le serveur demande à net. « qui est federez.net. ? ». Le serveur répond alors l’IP du serveur de federez.

Pour passer d’un niveau à un autre, il faut que l’IP du niveau inférieur soit référencée par le niveau supérieur. C’est le rôle des enregistrements NS, qui indique le nom de domaine à qui est déléguée la zone. Ce serveur doit lui-même contenir cet enregistrement NS et peut définir de nouvelles zones. Il n’est pas obligatoire que le serveur de nom pointé par le niveau supérieur soit le serveur répondant au nom de domaine du domaine inférieur.

Par exemple, il est possible d’avoir la configuration suivante dans le niveau supérieur (com. par exemple) :

example		IN	NS	ns.example.com
ns.example	IN	A	1.2.3.4

et dans example.com :

		IN	NS	ns.example.com
		IN	NS	ns1.example.com
		IN	A	1.1.1.1
ns		IN	A	1.2.3.4
ns1		IN	A	2.3.4.5

Le DNS est aussi capable de traduire une adresse IP en un nom de domaine. Pour cela, une zone spéciale, in-addr.arpa. est disponible. L’adresse IP est écrite à l’envers et devient le sous-domaine de in-addr.arpa..
Par exemple, une IP de federez.net donne :

$ dig PTR 65.155.228.160.in-addr.arpa
…
;; ANSWER SECTION:
65.155.228.160.in-addr.arpa. 86400 IN	PTR	quigon.rez-gif.supelec.fr.
…

dig fourni une syntaxe plus simple :

$ dig -x 65.155.228.160
…
;; ANSWER SECTION:
65.155.228.160.in-addr.arpa. 86400 IN	PTR	quigon.rez-gif.supelec.fr.
…

Sous debian, bind se trouve dans le paquet bind9. Le nom du service est bind9. Attention, suivant le système d’exploitation, le nom du service peut être named.

Bind est capable d’être à la fois serveur récursif et faisant autorité.
Le fichier de configuration principal est /etc/bind/named.conf. Il inclue par défaut d’autres fichiers de configuration.

Le fichier principal du serveur faisant autorité est /etc/bind/named.conf.local

Ajouter des vues dans le fichier de configuration permet de définir des zones différentes en fonction de l’adresse IP faisant la demande. Cela peut être utile pour séparer les adresses données à l’intérieur et à l’extérieur du réseau. Une IP demandant la résolution d’une zone tombera dans la première vue qui lui correspond et ne pourra pas en voir d’autres.

view "interne" {
	match-clients {
		10.0.0.0/8;
		192.168.0.0/16;
		127.0.0.1;
	};
	
	zone "example.com" {
		type master;
		allow-transfer {"none";};
		file "/var/bind/example.com.zone"
	};
};

match-clients contient les adresses IP qui verront cette vue, les sections zone correspondent aux zones sur lesquels ce serveur fait autorité.

Le type peut être master ou slave. Un slave demandera à un master de lui transférer sa zone.
allow-transfer peut contenir “none”, “any” (fortement déconseillé) ou une liste d’adresse IP. Le mieux est d’y indiquer les serveurs de nom esclaves pour cette zone.

Il faut créer les fichiers de zone selon le modèle. Créer un fichier de zone dans in-addr.arpa pour vos IP est aussi une bonne idée. Dans ce fichier, les seuls enregistrements utiles sont de type PTR.

La configuration du serveur récursif se fait dans /etc/bind/named.conf.options

options {
	…
	forwarders {
		8.8.8.8
	}
	
	allow-recursion {10.0.0.0/8;};
};

Si activé, forwarders indique les IP de serveurs récursifs dont se servira notre serveur qui ne sera alors plus qu’un cache DNS.

Il est recommander d’interdire la récursion depuis l’exterieur car il pourrait sinon être utilisé dans des attaques DDoS²⁾.

Unbound est un résolveur récursif pour le DNS, capable de valider DNSSEC. Contrairement à Bind, il se concentre sur la résolution récursive et n'est pas capable de faire autorité pour un domaine.

<Exemple de configuration avec contrôle d'accès et validation DNSSEC>

NSD est le dual d'Unbound : il est uniquement capable de faire autorité pour un domaine, mais il le fait bien. On utilise souvent NSD et unbound en couple pour avoir les mêmes fonctionnalités que Bind.

Le format des zones DNS est le même que pour Bind.

<Exemple de configuration avec zones maîtres et zones esclaves>

• Liste des types d’enregistrements DNS sur Wikipédia
• Site officiel de Bind
• Documentation DNS & Bind sur auto-hebergement.fr