03 - DNS

Introduction

DNS : Domain Name System

Le rôle de DNS est de convertir des noms de machine en adresse IP et inversement.

Les noms de machine doivent être sous la forme de FQDN (Fully Qualified Domain Name) : nom de machine et nom de domaine.

DNS est un système client/serveur.

  • Le serveur: sous Linux il s’agit de Bind dont le processus se nomme named.

  • Le client: existe sur tous les types de machine et se configure au moment de l’installation du réseau lors de l’ajout des adresses IP des serveurs DNS. Il se nomme le resolver.

  • DNS utilise le port 53 (UDP pour les requêtes, TCP pour les transferts de zone).

Structure du DNS

DNS

Le DNS a une structure pyramidale.

Au sommet de la pyramide : les serveurs racine (http://root-servers.org/).

  • 13 serveurs racine (nommés de a à m)

  • En fait ce sont des dizaines de serveurs répartis dans le monde accédés en anycast.

  • Il contiennent les liens entre les TLD et les adresses IP des serveurs DNS s’occupant des TLD.

Les TLD (Top Level Domain).

  • Des centaines (milliers?) de serveurs à travers le monde.

  • Ils contiennent les liens entre les domaines appartenant aux TLD et les adresses IP des serveurs DNS s’occupant de ces domaines.

Domaine vs Zone

La délégation: un domaine peut déléguer la gestion de ses sous-domaines à d’autres DNS.

C’est le cas par exemple de .qc.ca qui délègue au Collège la gestion de cmaisonneuve.

Un domaine représente tous les noms ayant le même suffixe.

  • Exemple 1 : le domaine racine englobe tous les noms existants

  • Exemple 2 : le domaine cmaisonneuve.qc.ca englobe tous les noms terminant par cmaisonneuve.qc.ca.

Une zone représente tout l’espace de noms géré par un serveur DNS autoritaire. Il s’agit donc de tout les domaines et sous-domaines moins les délégations.

Les délégations

Une autorité pour un domaine peut déléguer la gestion d’un ou plusieurs sous-domaine à une autre autorité:

  • Exemple 1 : .ca délègue la gestion de la zone videotron.ca à Vidéotron.

  • Exemple 2 : .qc.ca délègue la gestion de cmaisonneuve.qc.ca au collège de Maisonneuve.

Pour effectuer une délégation, l’autorité qui gère une zone doit placer dans son DNS le nom et l’adresse IP des serveurs DNS autoritaire de la zone déléguée. Ces enregistrements se nomment des “glue record”.

  • Exemple 1 : on trouve sur le DNS de .ca le nom et l’adresse IP des serveurs DNS autoritaires de videotron.ca

Les différents types de requêtes

Il existe deux types de requêtes DNS:

  • Les requêtes récursives

  • Les requêtes itératives

Ici le client effectue un requête récursive à son DNS cache (il est récursif car il s’occupe de toute la résolution).

Le DNS cache effectue lui une requête itérative pour trouver la réponse.

Dans une requête récursive, le serveur à qui la demande a été effectuée renvoie une réponse complète.

Dans une requête itérative, chaque DNS interrogé renvoie la meilleure réponse possible.

Vous voyez donc qu’il existe deux types de serveurs DNS :

  • Les serveurs capables d’accepter des requêtes récursives et d’effectuer des requêtes itératives : ce sont les DNS caches ou récursifs.

  • Les serveurs qui fournissent la meilleure réponse possible et ne font aucune autre opération : ce sont les DNS autoritaires.

Laboratoire 1 : Reproduction d’une requête récursive

La commande dig

La commande dig permet d’interroger des serveurs DNS.

Sa syntaxe est :

dig [@ip serveur DNS] [-t type de RR] [nom demandé]

La commande dig passée toute seule renvoie la liste de tous les serveurs racines.

Exemple:

dig @8.8.4.4 -t A intranet.cmaisonneuve.qc.ca
dig @8.8.4.4 -t ANY www.videotron.com

Principe du lab

Résoudre le nom intranet.cmaisonneuve.qc.ca

Vous obtenez la liste des serveurs racine grâce à la commande dig.

Ensuite, interrogez un des serveurs racines pour obtenir l’adresse IP de intranet.cmaisonneuve.qc.ca.

Ces serveurs vous donnent la liste des serveurs DNS autoritaires de la zone .ca. Choisissez en un et interrogez le.

Vous obtiendrez la liste des serveurs DNS autoritaires de .qc.ca…

Continuez jusqu’à obtenir l’adresse IP recherchée.

Les différents types de serveurs

Tel qu’abordé plus haut, il existe deux types de serveurs DNS:

  • Les serveurs DNS caches (ou récursifs) : ils stockent uniquement l’adresse des serveurs DNS racines. Toutes les autres adresses sont obtenues lors de requêtes itératives et stockées dans le cache. Toutes les adresses sont purgées à chaque redémarrage.

  • Les serveurs DNS autoritaires : ce sont eux qui stockent les enregistrements et qui répondent aux requêtes des DNS caches. Ils sont gérés par le propriétaire du domaine (de la zone pour être plus précis) pour lequel ils sont autoritaires. Les zones sont le plus souvent des fichiers texte contenant la liste des enregistrements. Un serveur DNS autoritaire peut l’être pour plusieurs zones.

Pour des questions de redondance, chaque type de serveur dans une organisation doit exister en plusieurs exemplaires (généralement deux).

La redondance

Les DNS cache ne contiennent aucune information qui pourrait être perdue. Il suffit de disposer de plusieurs de ces serveurs pour avoir de la redondance. Ils peuvent être placés derrière un équilibreur de charge.

Les DNS autoritaires contiennent eux des informations précieuses. Pour assurer la redondance, chaque zone aura donc plusieurs DNS autoritaires. Pour éviter des incohérences (les serveurs ayant des informations différentes), un serveur est désigné comme DNS autoritaire primaire (c’est sur lui que seront effectuées les ajouts et les modifications). Les autres seront des serveurs DNS autoritaires secondaires : aucune modification ne peut être effectuée sur ces serveurs mais ils répliquent les modification mises en place sur les primaires. Lors de la perte d’un primaire, il est aisé de transformer un secondaire en primaire.

La réplication d’une zone d’un serveur primaire vers un serveur secondaire se nomme un transfert de zone et peut impliquer de grande quantité de données.

Pour cette raison, cette partie de DNS fonctionne sur TCP.

Il est possible de simuler un transfert de zone à l’aide la commande dig:

dig @[serveur] -t AXFR [nom de la zone]

ATTENTION : pour des raisons de sécurité, tous les serveurs DNS n’acceptent pas de transférer leur zone. Des tentatives peuvent être considérées comme des gestes agressifs.

Bonnes pratiques

Les bonnes pratiques recommandent de séparer chacun des rôles.

Même dans une entreprise de taille moyenne il est recommandé d’avoir deux DNS caches qui ne seront accessibles que par le personnel de l’entreprise. Ces serveurs permettront aux personnes dans l’entreprise de résoudre les noms sur Internet.

Deux DNS autoritaires en DMZ permettront au monde entier de résoudre les noms de vos serveurs accessibles sur Internet comme www.

Deux serveur DNS autoritaires internes pour permettre de résoudre les noms des serveurs internes. Ils ne seront accessibles que par les personnes à l’intérieur de l’entreprise.

Il arrive que ces rôles soient installés sur les mêmes serveurs pour des questions d’économie. Un serveur DNS peut donc être à la fois cache, autoritaire primaire et autoritaire secondaire.

Les différents types d’enregistrements

Il existe de nombreux types d’enregistrement. Voici les plus courant.

A : adresse IP

AAAA : adresse IPv6

TXT : texte ou commentaire

PTR : DNS inverse, pour obtenir un nom

CNAME : Canonical Name (alias)

MX : nom du serveur de courriels d’un domaine

SRV : permet de définir un serveur comme assurant un service donné

Le serveur Bind

Bind est le serveur DNS le plus utilisé au monde.

Il est libre et gratuit.

Il est très performant et dispose de toutes les fonctionnalités possibles.

Comme le DHCP que nous avons vu, il est développé par ISC.

La documentation se trouve à: https://www.isc.org/downloads/bind/doc/

Laboratoire 2

Pour ces labs, vous aurez besoin de deux serveurs Centos.

L’installation est très simple (sur les deux serveurs) :

$ dnf install bind

Laboratoire 3

Est-ce que votre serveur Bind agit comme serveur DNS cache?

Comment pouvez-vous le tester?

Chercher sur Internet comment changer l’état du DNS cache (s’il est activé par défaut, comment le désactiver et s’il est désactivé par défaut, comment l’activer).

Le fichier à modifier est /etc/named.conf.

Une seule instruction très simple.

Modifiez son état et tester que votre manipulation a fonctionné.

À la fin de ce lab, le DNS cache doit être activé sur vos deux serveurs Bind.

Les fichiers de configuration de Bind se trouvent dans /etc/.

Le fichier de configuration principal de Bind se nomme named.conf.

C’est dans ce fichier que seront définis les noms des zones ainsi que l’emplacement des fichiers de zone et si le serveur est récursif ou non.

Pour créer une zone, deux actions sont nécessaires :

- Définition de la zone dans le fichier de configuration dans /etc

- Création du fichier de la zone dans /var/named, ce sont les enregistrements qui sont dans ce fichiers.

Définition d’une zone :

zone "domaine1.com" {
	type master;        		
	file "domaine.com";		
};

Contenu d’un fichier de zone:

$TTL 3H
@       IN SOA  @ admin.axelland.local. (
                                        2       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum

@	IN	NS	localhost.
@	IN	A	127.0.0.1
@	IN	AAAA	::1

Explication du fichier ci-dessus

$TTL : durée pendant laquelle un DNS cache peut mettre en cache les informations de cette zone

SOA (Start Of Authority) : cette section définit les options pour toute la zone:

Serial : identifie le numéro de version de la zone. Doit être incrémenté à chaque modification.

Refresh : intervalle de temps pour que le secondaire vienne mettre à jour les données sur le primaire.

Retry : intervalle de temps pour réessayer en cas d’échec.

Expire : si le primaire tombe, durée avant que les secondaires cessent de répondre.

Negative cache TTL : durée de vie dans le cache des réponses d’erreur (NXDOMAIN)

@ : correspond au nom de la zone dans laquelle se trouve le signe.

Les zones inverse

DNS peut aussi donner le nom correspondant à l’adresse IP.

Pour ceci on crée des zones inverses.

Une zone inverse pour les adresses IP du réseau 192.168.230.0/24 se nommera:

230.168.192.in-addr.arpa

Le nom suffit à indiquer au serveur qu’il s’agit d’une zone inverse pour le réseau 192.168.230.0/24.

Les enregistrements contenus dans la zone seront de la forme (pour trouver le nom correspondant à 192.168.230.32):

32	IN  PTR	nom.domaine.tld.

Laboratoire 4: configuration d’un serveur autoritaire

Nous allons configurer deux zones: domaine1.com et une zone reverse.

Le serveur 1 sera autoritaire et primaire pour la zone domaine1.com et secondaire pour la zone reverse.

Le serveur 2 sera autoritaire et primaire pour la zone reverse et secondaire pour la zone domaine1.com.

Assurez vous que dans named.conf, les lignes allow-query et listen-on sont à any.

Assurez vous aussi que votre firewall est arrêté.

Pour configurer une zone, deux étapes sont nécessaires:

  • Créer le fichier de zone contenant les informations de la zone (nom et adresses IP).

  • Déclarer la zone dans le fichier named.conf pour que le fichier de zone soit pris en compte.

Création d’une zone forward

Vous pouvez partir d’un modèle de zone pour créer la première zone, utilisez named.empty dans le répertoire /var/named et copiez le en lui donnant le nom de la zone voulue: domaine1.com.

Vous pouvez ensuite modifier son contenu pour avoir :

$TTL 3H
@       IN SOA  @ admin.axelland.local. (
                                        2       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum


@	IN	NS	ns1.domaine1.com.
@	IN	NS	ns2.domaine1.com.
ns1	IN	A	192.168.230.254		; vous devez inscrire l'adresse de votre serveur
ns2	IN	A	192.168.230.224
www	IN	A	182.45.32.67		; adresse IP de votre serveur www (ce que vous voulez)

Le fichier de zone est créé. Vous pouvez le tester à l’aide de la commande:

$ named-checkzone domaine1.com /var/named/domaine1.com

Le fichier domaine1.com doit avoir named comme groupe propriétaire.

Cette commande ne doit pas vous retourner d’erreurs.

Le fichier de zone a été créé mais il faut maintenant l’ajouter à la configuration Bind. Ceci peut se faire dans le fichier /etc/named/meszones.conf. Il faut alors ajouter l’instruction suivante en bas du fichier /etc/named.conf :

include "/etc/named/meszones.conf";

Éditez ce fichier et ajoutez la définition suivante:

zone "domaine1.com" {
	type master;        		
	file "domaine1.com";		
	allow-transfer { 192.168.230.224; };    (adresse IP du 2ème serveur)
  also-notify { 192.168.230.224; };
};

Redémarrez le service Bind:

$ systemctl restart named

Vérifiez la configuration:

$ named-checkconf /etc/named.conf

Vous ne devriez pas avoir d’erreur.

Interrogez votre serveur DNS pour le tester: demandez lui l’adresse de ns1.domaine1.com à l’aide de la commande dig.

Il s’agit de configurer maintenant le DNS autoritaire secondaire pour la même zone.

Configurez votre serveur pour que www.domaine1.com et domaine1.com renvoie la même adresse IP.

Allez sur le deuxième serveur et éditez le fichier /etc/named/meszones.conf (n’oubliez pas d’ajouter la configuration include à la fin de named.conf).

Ajoutez y les lignes suivantes:

zone "domaine1.com" {        		
	type slave;        		
	file "slaves/domaine1.com";		
	masters { 192.168.230.254; };  (adresse IP du 1er serveur)
};

Redémarrez le serveur Bind.

Comment pouvez-vous tester que le serveur est maintenant secondaire et fonctionnel?

Laboratoire 4bis : Création d’une zone reverse

Sur le serveur 2, créez le fichier /var/named/192.168.230 et mettez-y:

$TTL 3H
@       IN SOA  @ admin.axelland.local. (
                                        2       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum


@	IN	NS	ns1.domaine2.com.
@	IN	NS	ns2.domaine2.com.
224	IN	PTR	ns2.domaine2.com.
254	IN	PTR	ns1.domaine2.com.

Dans le fichier /etc/named/meszones.conf ajoutez la section suivante:

zone "230.168.192.in-addr.arpa" IN {        		
	type master;        		
	file "192.168.230";       		
	allow-transfer { 192.168.230.254; };
};

Vérifiez la zone et la configuration puis redémarrez le serveur Bind.

Testez à l’aide de la commande dig que vous pouvez faire une résolution inverse:

dig @localhost -x 192.168.230.224

Créez la zone secondaire sur le serveur 1:

zone "230.168.192.in-addr.arpa" IN {        		
	type slave;        		
	file "db.192.168.23";       		
	masters { 192.168.230.224; };
};

Redémarrez le serveur Bind et testez avec la commande dig.

À la fin de ce lab, vos deux serveurs seront à la fois cache, autoritaires, primaires et secondaires.

À votre avis, quelle est la manipulation à effectuer pour transformer un DNS secondaire en primaire si le primaire tombe.

Intégration de DNS et DHCP

Que se passe-t-il quand l’adresse IP des machines peut changer car leur adresse IP leur est attribué par DHCP?

Il faudra que le DHCP mette à jour le DNS avec le nom et l’adresse du client auquel il vient d’attribuer une adresse IP.

Ce protocole se nomme DDNS (Dynamic DNS).

À chaque fois que le serveur DHCP donne une adresse IP il met à jour le serveur DNS.

Laboratoire 5: DDNS

Sur le DHCP:

ddns-updates on;
ddns-update-style interim;

zone domaine1.com. {	
	primary 192.168.230.254;
}

subnet 192.168.230.0 netmask 255.255.255.0 {   	
	range 192.168.230.100 192.168.230.150;   	
	option routers 192.168.230.2;   	
	option domain-name-servers 192.168.230.254, 192.168.230.224;   	
	option domain-name "domaine1.com";   	
	ddns-domainname "domaine1.com.";   	
	ddns-rev-domainname "in-addr.arpa";
}

Sur le DNS autoritaire primaire :

zone "domaine1.com" {        		
	type master;        		
	file "domaine1.com";       		
	allow-transfer { 192.168.230.224; };        		# Adresse de votre DNS secondaire
	allow-update { 192.168.230.254; };              # Adresse de votre serveur DHCP
};

Introduction à DNSSEC

Le principal problème de DNS est la sécurité.

Comme DNS fonctionne sur UDP, n’importe qui peut répondre à vos requêtes DNS et vous rediriger vers un site malveillant.

Plusieurs solutions aident à résoudre ce problème mais la plus efficace est DNSSEC.

Fonctionnement

Le serveur racine signe à l’aide d’une clé tous ses enregistrements.

Si vous demandez à résoudre www.fraise.com, le serveur racine vous donnera les noms des serveurs DNS autoritaires de .com (signé par la clé du serveur racine) et vous donnera aussi la clé de .com (signée aussi avec la clé du serveur racine).

Vous pourrez alors interroger le serveur DNS autoritaire de .com et vérifier que les informations qu’il vous envoie ont bien été signées par la bonne personne vu que le serveur racine vous a envoyé la clé de .com.

.com vous enverra à son tour les noms des DNS autoritaires de fraise.com ainsi que la clé de fraise.com. Vous pourrez alors demander des informations à ces serveurs et vérifier que ce sont bien eux qui répondent.

Il se bâtit ainsi une chaine de confiance.

Pour que cette chaine existe, vous devez seulement disposer de la clé du serveur racine.

Lors de l’installation de Bind, ces clés se trouvent dans: /etc/named.root.key

Références

Documentation en Français https://wiki.debian.org/fr/Bind9

DNS for rocket scientists http://www.zytrax.com/books/dns/

Documentation Bind https://www.isc.org/downloads/bind/doc/