Différences

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

--- doc:dns [2014/04/06 09:31] – bertrand.bonnefoy-claudet
+++ doc:dns [2020/07/19 07:54] (Version actuelle) – typo fix chiahetcho
@@ Ligne 1: / Ligne 1: @@
-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 addresse IP.
+====== 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 ? =====
@@ Ligne 13: / Ligne 15: @@
 ==== 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 (RFC 608). Cette solution ne passe pas à l'échelle aujourd'hui avec les milliards d'hôtes qui ont besoin de noms de domaine.
+À 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 1035 (section 5) et la RFC 1034 (section 3.6.1) 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 52: / 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 62: / 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 !)).
-=== 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 //slave// pour savoir si leur cache est toujours à jour. Si vous avez un serial inférieur à 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 ====
 === Utiliser dig ===
@@ Ligne 137: / 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 188: / Ligne 195: @@
 </code>
-===== DNSSEC =====
+''dig'' fourni une syntaxe plus simple :
-==== Fonctionnement ====
-DNSSEC (//DNS SECurity Extensions//) est une extension du protocole DNS qui lui rajoute la possibilité d’authentifier les réponses et de les valider à l’aide de la cryptographie. Attention, les requêtes sont toujours envoyées en clair, elles ne sont jamais chiffrées. Le principe est le même que la signature d’un courriel avec le protocole [[PGP]]. Le propriétaire d’une zone possède une paire de clef qui lui permet de signer ses enregistrements. Cela permet d’une part de certifier que l’enregistrement est légitime, mais aussi de certifier de manière dynamique l’absence d’un domaine.
-Le protocole utilise deux types de clefs :
-  * Une clef signataire de zone (ou ZSK pour //Zone Signing Key//) : généralement petite (1024 bit par défaut) car elle doit être utilisée de nombreuses fois pour signer chaque enregistrement. Il est aussi bon de la changer souvent, tous les quelques mois par exemple.
-  * Une clef signataire de clef (ou KSK pour //Key Signing Key//) : généralement grande car elle ne sert qu’à signer la ZSK.
-Un enregistrement DS permet de déléguer la confiance d’une zone. Il contient le hash de la KSK de la zone fille. En connaissant ce hash, il est possible de vérifier et faire confiance à la KSK de la zone fille. On peut alors se servir de cette KSK pour vérifier la ZSK et lui faire confiance. On peut alors valider les domaines de la zone fille.
-De cette manière, seule la clef de la racine est nécessaire à valider les différentes zones du DNS.
-==== Génération des clefs ====
-Pour générer une clef signataire de clef (//Key Signing Key// ou KSK), utilisez la commande suivante :
 <code>
-dnssec-keygen -f KSK -a RSASHA256 -b 2048 federez.net
+$ dig -x 65.155.228.160
+…
+;; ANSWER SECTION:
+.155.228.160.in-addr.arpa. 86400 IN	PTR	quigon.rez-gif.supelec.fr.
+…
 </code>
-Cela va créer deux fichiers du type Kfederez.net.+007+049632.key et Kfederez.net.+007+049632.private. Pour plus de simplicité par la suite, renommez-les en, par exemple, federez.ksk.key et federez.ksk.private
-Pour générer la clef signataire de zone (//Zone Signing Key// ou ZSK), utilisez la commade suivante :
-<code>
-dnssec-keygen -a RSASHA256 -b 2048 federez.net
-</code>
-De même, renommez les fichiers avec un nom plus explicite.
-==== Signature d’une zone ====
-ajoutez en fin de fichier de zone :
-<code>
-$include /etc/bind/federez.zsk.key
-$include /etc/bind/federez.ksk.key
-</code>
-Pour signer la zone //federez.net.//, utilisez la commande suivante :
-<code>
-dnssec-signzone -e20480101000000 -p -t -g -k federez.ksk.key -o federez.net federez.net.zone federez.zsk.key
-</code>
-où 20480101000000 est au format AAAAMMJJHHMMSS. C’est la date d’expiration des signatures. Cela va créer un nouveau fichier de zone, federez.net.zone.signed, utilisable à la place de federez.net.zone
-Enfin, pour déléguer une zone, pensez à déléguer les signatures avec un enregistrement DS, qui n’est pas généré par la commande précédente. Il suffit alors de configurer DNSSEC avec son registrar pour que les signatures deviennent valides.
-==== Automatisation ====
-Les outils disponibles dans le paquet ''opendnssec-tools'' (sous debian) permettent d’automatiser de nombreuses tâches liées au DNSSEC.
-Cette section est incomplète.
 ===== Configuration de bind =====
@@ Ligne 297: / Ligne 260: @@
 ===== 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.
+[[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>
@@ Ligne 310: / Ligne 273: @@
 ===== 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]]
-  * [[https://www.icann.org/en/news/in-focus/dnssec/deployment | liste des registrars supportant DNSSEC (en)]]