Différences

Ci-dessous, les différences entre deux révisions de la page.

--- doc:dns [2014/03/31 15:11] – créée julien.lepiller
+++ doc:dns [2020/07/19 09:54] (Version actuelle) – typo fix chiahetcho
@@ Ligne 1: / Ligne 1: @@
-Le DNS (''Domain Name System'') est le nom du protocole permettant la traduction entre nom de domaine et addresse IP.
+====== DNS ======
-===== Comprendre le DNS =====
+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.
-==== Pourquoi le DNS ? ====
-La section est vide.
+===== Pourquoi le DNS ? =====
+==== Nom de domaine vs 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).
+==== DNS vs hosts.txt ====
+À 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 ([[http://tools.ietf.org/html/rfc608|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.
+===== Comment ça marche ? =====
+==== Protocole ====
+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 [[http://tools.ietf.org/html/rfc5966|RFC 5966 (en)]] détaille l'utilisation de TCP pour les résolutions DNS.
+[[http://tools.ietf.org/html/rfc6891|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.
 ==== Fichier de zone ====
-Le fichier de zone décrit une zone du DNS. Ce fichier a une syntaxe définie par la RFC et ne dépend pas du serveur utilisé.
+Sur le serveur, un fichier de zone décrit une zone du domaine. Ce fichier a une syntaxe définie par la [[http://tools.ietf.org/html/rfc1035|RFC 1035]] (section 5) et la [[http://tools.ietf.org/html/rfc1034|RFC 1034]] (section 3.6.1) et ne dépend pas du serveur utilisé.
 Voici un exemple de fichier de zone :
@@ Ligne 38: / Ligne 60: @@
 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é.
-=== Enregistrements traditionnels ===
+=== Enregistrements classiques ===
   * A : renseigne une adresse IPv4.
@@ Ligne 48: / Ligne 70: @@
   * TXT : peut contenir n’importe quel texte, entre guillemets doubles.
-=== Enregistrements DNSSEC ===
+=== Sécurité ===
-DNSSEC ajoute plusieurs types d’enregistrement :
+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 [[https://tools.ietf.org/html/rfc3833|RFC3833 (en)]]). [[DNSSEC]] a été créé pour palier la plupart de ces failles.
-  * DS : Delegation Signer. Équivalent de NS pour déléguer la signature d’une zone.
+=== Note sur le serial ===
+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<sup>e</sup> modification du 5 mars 2014((Attention, dans ce cas, n’utilisez pas 201403061, mais 2014030601 !)).
 ==== Résolution ====
@@ Ligne 121: / Ligne 144: @@
 </code>
-On peut aussi lui demander de vérifier les zones en utilisant [[#DNSSEC|DNSSEC]]. Si la zone est validée, le flag ''ad'' est ajouté à la réponse : <code>
+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 : <code>
 $ dig +dnssec isc.org
 ; <<>> DiG 9.9.2-P2 <<>> +dnssec isc.org
@@ Ligne 141: / Ligne 164: @@
 === Fonctionnement ===
-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''.
+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.
+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) :
+Par exemple, il est possible d’avoir la configuration suivante dans le niveau supérieur (//com.// par exemple) :
 <code>
 example		IN	NS	ns.example.com
@@ Ligne 162: / Ligne 185: @@
 === Résolution inverse ===
-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.''.
+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 :
 <code>
@@ Ligne 172: / Ligne 195: @@
 </code>
-===== DNSSEC =====
+''dig'' fourni une syntaxe plus simple :
+<code>
-La section est vide.
+$ dig -x 65.155.228.160
+…
+;; ANSWER SECTION:
+.155.228.160.in-addr.arpa. 86400 IN	PTR	quigon.rez-gif.supelec.fr.
+…
+</code>
 ===== Configuration de bind =====
@@ Ligne 205: / Ligne 233: @@
 ''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.
+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.
+=== fichiers à créer ===
+Il faut créer les fichiers de zone selon le [[#Fichier-de-zone | 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.
 ==== Serveur récursif ====
@@ Ligne 225: / Ligne 257: @@
 Il est recommander d’interdire la récursion depuis l’exterieur car il pourrait sinon être utilisé dans des attaques DDoS((par amplification DNS)).
+===== Unbound comme résolveur récursif =====
+[[https://unbound.net/|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 comme serveur faisant autorité =====
+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>
 ===== Liens externes =====
-  * [[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions | DNSSEC sur Wikipédia (en)]]
   * [[https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS | Liste des types d’enregistrements DNS sur Wikipédia]]
-  * [[https://www.isc.org/downloads/bind/ | site officiel de Bind]]
+  * [[https://www.isc.org/downloads/bind/ | Site officiel de Bind]]
+  * [[https://wiki.auto-hebergement.fr/services/nom_de_domaine|Documentation DNS & Bind sur auto-hebergement.fr]]