DNS

axel@ift3225
Introduction (RFC 1035)
Structure du DNS
 Structure du 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 à l)
• 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 .ca qui délègue à l'université la gestion de umontreal.

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

• Exemple 1 : le domaine racine englobe tous les noms existants
• Exemple 2 : le domaine umontreal.ca englobe tous les noms terminant par umontreal.ca tel que
iro.umontreal.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.
fi
 Les délégations
Une autorité pour un domaine peut déléguer la gestion d'un ou plusieurs sous-domaines à une autre
autorité:
• Exemple 1 : .ca délègue la gestion de la zone videotron.ca à umontreal.
• Exemple 2 : umontreal délègue la gestion de ido.umontral.ca au département d’informatique.
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
umontreal.ca.
 Les différents types de requête
Il existe deux types de requêtes DNS:
• Les requêtes récursives
• Les requêtes itératives
Ici le client effectue une 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.
Les différents types de requête
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.
 La requête itérative
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 www.iro.umontreal.ca
dig @8.8.4.4 -t ANY www.fraise.com
 La requête itérative
Pour résoudre le nom www.iro.umontreal.ca

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

Ensuite, interroger un des serveurs racines pour obtenir l'adresse IP de

www.iro.umontreal.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 umontreal.ca…

Continuer 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 chiers 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).

fi
 La redondance
Les DNS cache ne contiennent aucune information qui pourrait être perdue. Il suf t 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 modi cations). Les autres seront des serveurs DNS autoritaires secondaires : aucune modi cation
ne peut être effectuée sur ces serveurs mais ils répliquent les modi cation mises en place sur les primaires. Lors
de la perte d'un primaire, il est aisé de transformer un secondaire en primaire.
fi
fi
fi
fi
 La redondance
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 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é nir un serveur comme assurant un service donné

fi
 Les serveur Bind

Bind est le serveur DNS en logiciel libre développé par ISC.

Il s’agit du serveur le plus répandu.

Par défaut, il agit comme serveur DNS récursif grâce à la ligne

suivante dans son chier de con guration named.conf

recursion yes
fi
fi
 Création d’une zone
La création d’une zone se fait en deux étapes :
• Déclaration de la zone
• Dé nition du contenu de la zone

Nom de la zone
zone "domaine1.com" {
Serveur primaire
type master;
Déclaration de la zone
le "/var/named/domaine1.com";
allow-transfer { 192.168.230.224; }; (adresse IP du 2ème serveur)
};
Fichier contenant les
Adresse du serveur informations de la zone
secondaire
fi
fi
 Création d’une zone
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 modi er son contenu pour avoir :

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

@ IN SOA @ root.domaine1.com. (
2 ; Serial Serial : identi e le numéro de version de la zone. Doit être incrémenté à chaque modi cation.
1D ; Refresh 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.
1H ; Retry
Expire : si le primaire tombe, durée avant que les secondaires cessent de répondre.
1W ; Expire
Minimum : TTL par défaut
3H ) ; minimum
;

@ IN NS ns1.domaine1.com.
@ IN NS ns2.domaine1.com.
ns1 IN A 192.168.230.254 ; vous devez inscrire l'adresse des serveurs ci-dessus
ns2 IN A 192.168.230.224

www IN A 182.45.32.67
fi
fi
fi
 Les zones inverses
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 suf t à 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.
fi
 Les zones inverses
Déclaration de la zone Contenu de la zone
$TTL 604800
@ IN SOA localhost. root.localhost. (
zone "230.168.192.in-addr.arpa" IN { 3 ; Serial
type master; 1D ; Refresh
le "192.168.23"; 1H ; Retry
masters { 192.168.230.224; }; 1W ; Expire
}; 3H ) ; Minimum

Interrogation d’un enregistrement inverse : @ IN NS ns1.domaine2.com.

dig @serveur -x 192.168.230.224 @ IN NS ns2.domaine2.com.

224 IN PTR ns2.domaine2.com.

Enregistrements inverses
254 IN PTR ns1.domaine2.com.
fi
 Problème de sécurité
DNS n’est pas sécurisé.

De faux serveurs peuvent renvoyer de fausses adresses (DNS spoo ng).

L’utilisateur ira consulter un site malveillant.

Corrigé avec DNSSEC : RFC 9364

fi
 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 ef cace 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).

fi
 Introduction à DNSSEC
Vous pourrez alors interroger le serveur DNS autoritaire de .com et véri er 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éri er que ce sont bien
eux qui répondent.

Il se bâtit ainsi une chaine de con ance.

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

fi
fi
fi
 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/