Cadoles
/
formations
18
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
formations/cesi/hebergement_web/01-dns.md

13 KiB
Raw Blame History

% Introduction au DNS % Sylvain Eliade — S.C.O.P. Cadoles % Mai 2019

Introduction au DNS

  • Domain Name System
  • Service de base sur Internet
  • Permet d'obtenir l'adresse IP d'une machine à partir d'un nom intelligible (résolution de nom)
  • Exemple : www.cesi.fr -> 178.170.102.194
  • Sur le port 53, en UDP (+ TCP pour les réponses de plus de 512 octets) : plus rapide !

Un nom DNS

www.cesi.fr comporte trois parties :

  • fr est le TLD (Top Level Domain)
  • cesi est le nom de domaine
  • www est un sous-domaine

Le FQDN (Fully Qualified Domain Name) est le nom intégral, suivi d'un point final (= la racine), indiquant que le nom est complet : www.cesi.fr.

L'ensemble des enregistrements d'un nom de domaine s'appelle une zone.

Les TLD

Plusieurs types :

  • pour les pays (.fr, .be, .nz, etc.) = ccTLD (Country-Code)
  • génériques (gTLD) : .com, .info, et les nouveaux : .paris, .ovh et des centaines d'autres
  • infrastructure .arpa : ne sert que pour les reverse DNS (trouver un nom à partir d'une IP)

État des TLDs

Plus de 1500 TLD à ce jours. Expansion depuis l'ouverture à la vente des gTLD en 2012 (100.000$ pour déposer un dossier).

TLD réservés : .example, .invalid, .localhost, .test, .local (multicast), .onion (Tor).

Attention à ne pas utiliser des TLD perso en interne : exemple du .dev acheté par Google.

Résolution DNS

Le DNS est un système hiérarchique. On commence par la racine (root) et on descend les niveaux.

Ainsi pour résoudre le nom fr.wikipedia.org on va demander :

  • aux serveur racine : quel serveur est responsable du TLD org ?
  • au serveur responsable de org : qui est responsable du domaine wikipedia.org ?
  • au serveur responsable du domaine wikipedia.org : quelle est l'adresse IP de fr.wikipedia.org ?

On obtient enfin l'adresse IP du serveur associé à fr.wikipedia.org, ou si celui-ci n'existe pas, le serveur DNS renvoie NXDOMAIN (Non-eXistent domain).

Les outils d'inspection DNS

  • host renvoie des réponses courtes et simples. Pratique pour scripter.
  • dig est plus complet. Mieux pour diagnostiquer des problèmes DNS.
  • nslookup : simpliste, mais dispo sous Windows et Linux, déconseillé.

Pour leur utilisation : man dig et man host

% host eliade.net
eliade.net has address 91.121.181.110
eliade.net has IPv6 address 2001:41d0:1:f66e::1
eliade.net mail is handled by 10 mail.kd2.org.

% dig eliade.net
…
;; ANSWER SECTION:
eliade.net.		201	IN	A	91.121.181.110

;; Query time: 1 msec
;; SERVER: 192.168.5.253#53(192.168.5.253)
;; WHEN: Mon May 13 10:45:34 CEST 2019
;; MSG SIZE  rcvd: 55

Attention, par défaut les deux outils utilisent le résolveur configuré dans /etc/resolv.conf (ici 192.168.5.253). Bien utiliser leurs options si on veut faire des requêtes directement sur les serveurs racine, de TLD, ou autoritaires.

Exemple de résolution de domaine : fr.wikipedia.org

On peut reproduire le travail d'un résolveur avec l'outil dig.

On demande au serveur racine qui est responsable pour le TLD org :

% dig NS org +short
a0.org.afilias-nst.info.
c0.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
d0.org.afilias-nst.org.
a2.org.afilias-nst.info.

On sait que a0.org.afilias-nst.info est responsable de la zone .org, on va lui demander qui est responsable de la zone wikipedia.org

% dig wikipedia.org @a0.org.afilias-nst.info
…
wikipedia.org.		86400	IN	NS	ns0.wikimedia.org.
wikipedia.org.		86400	IN	NS	ns2.wikimedia.org.
wikipedia.org.		86400	IN	NS	ns1.wikimedia.org.
…

Reste plus qu'à demander au serveur responsable de wikipedia.org quelle est l'adresse de fr.wikipedia.org :

% dig fr.wikipedia.org @ns0.wikimedia.org
…
fr.wikipedia.org.	3600	IN	CNAME	dyna.wikimedia.org.
…

Ah c'est un CNAME donc un alias, vers dyna.wikimedia.org !

Donc il nous faut aller voir à quoi correspond dyna.wikimedia.org :

% dig dyna.wikimedia.org @ns0.wikimedia.org
…
dyna.wikimedia.org.	600	IN	A	91.198.174.192
…

Et voilà on a notre adresse IP !

(Ici on a pris un raccourci, normalement on aurait dû aller demander quel était le serveur responsable de wikimedia.org mais c'est le même que wikipedia.org).

Attention au cache !

Évidemment on ne va pas re-demander au serveur racine à chaque fois quels sont les serveurs responsables de chaque TLD, si on a déjà l'information, elle est mise en cache pour un certain temps, à plusieurs niveaux (application, OS, serveur DNS local, etc.).

Syntaxe d'enregistrement

dyna.wikimedia.org.	600	IN	A	91.198.174.192

Chaque enregistrement indique :

  • son nom (dynam.wikimedia.org)
  • son TTL (Time-To-Live) : limite de temps avant qu'un résolveur ne doive aller re-demander l'enregistrement au serveur autoritaire (600 secondes = 10 minutes)
  • IN pour INternet
  • le type de l'enregistrement (A)
  • la valeur (91.198.174.192)

Types d'enregistrements

  • SOA = Infos sur le domaine (Start of Authority)
  • A = Adresse IPv4
  • AAAA = Adresse IPv6
  • CNAME = Alias vers un autre nom
  • MX = Serveur de mail responsable de la zone
  • NS = Serveur DNS responsable de la zone
  • TXT = Commentaire

Attention : le CNAME ne peut pas être utilisé pour un nom de domaine, seulement pour un sous-domaine ! (car il doit être le seul enregistrement !)

Priorité d'enregistrements

Les enregistrements de type MX permettent de spécifier la priorité de chaque enregistrement :

% dig MX fastmail.fm +short
20 in2-smtp.messagingengine.com.
10 in1-smtp.messagingengine.com.

Ainsi ici les serveurs de mail vont essayer in1-smtp.messagingengine.com en premier, et s'il ne répond pas, ils essaieront in2-smtp.messagingengine.com.

La syntaxe du SOA

Le SOA est l'enregistrement le plus important avec NS. Il a une syntaxe spécifique : MNAME RNAME SERIAL REFRESH RETRY EXPIRE TTL

  • MNAME = adresse du serveur DNS primaire (Master)
  • RNAME = adresse email du Responsable (en remplaçant le @ par un point .)
  • SERIAL = numéro de dernière modification de la zone, doit être incrémenté à chaque modification de la zone (en général on utilise la date du jour + un nombre qui s'incrémente). C'est ce qui indique aux serveurs secondaires qu'ils doivent
  • REFRESH = nombre de secondes avant que les serveurs secondaires ne doivent aller re-vérifier si le serial a changé. En général c'est 86400 (24 heures).
  • RETRY = nombre de secondes avant que les secondaires ne relancent une requête si le primaire ne répond pas (générallement 7200 = 2 heures)
  • EXPIRE = nombre de secondes avant que les secondaires doivent arrêter de relayer la zone si le primaire ne répond pas (en général 1000 heures = 41,6 jours)
  • TTL = Time To Live = nombre de secondes avant qu'un résolveur doive ré-essayer si le serveur a répondu NXDOMAIN

Exemple pour octopuce.fr :

ubal.octopuce.fr. support.octopuce.fr.
	2019051305 21600 3600 604800 3600

Les différents types de serveurs DNS

  • Serveur racine : 13 serveurs (13 lettres) en Anycast (= 13 adresses IP, mais 600+ serveurs physiques répartis dans le monde), indique le serveur autoritaire d'un TLD
  • Serveur responsable de TLD : serveur qui indique le serveur autoritaire d'un nom de domaine
  • Serveur autoritaire de nom de domaine
  • Serveur récursif : en général celui de votre FAI, ou de votre réseau local, c'est lui qui va faire les requêtes vers les serveurs racine, de TLD et autoritaire et renvoyer directement la réponse finale au client

Le serveur autoritaire

C'est celui qu'on est susceptible de mettre en place en tant que sysadmin, il répond aux requêtes pour un ou plusieurs domaines particuliers.

  • C'est lui qui fait autorité sur un/des domaines (AUTHORITY)
  • Son autorité ne vaut rien si le serveur du TLD n'indique pas ce serveur comme étant responsable du domaine

Donc bien vérifier auprès du registrar (auquel vous avez payé le nom de domaine), que le domaine est bien configuré.

Serveur autoritaire primaire et secondaire

Il est possible de n'avoir qu'un seul serveur autoritaire pour un domaine, mais si celui-ci devient injoignable, tous vos noms de domaines sont aussi injoignables. En général on a donc un serveur primaire et un ou plusieurs serveurs secondaires.

Les serveurs secondaires enregistrent une copie de la zone depuis le serveur primaire. Pour faire cette copie ils envoient une requête AXFR au serveur primaire qui leur renvoie tous les enregistrements de la zone.

Les clients eux iront demander à n'importe quel serveur listé comme NS pour la zone, au hasard, qu'il soit primaire ou secondaire.

Notification des serveurs secondaires

Il existe deux manières pour un serveur secondaire de savoir s'il a besoin de mettre à jour une zone :

  • le serveur primaire notifie les serveurs secondaires (message NOTIFY)
  • les secondaires vont demander le SOA toutes les x secondes (spécifié dans le paramètre REFRESH du SOA), et regarder si le SERIAL du SOA a changé depuis la dernière fois

De nos jours on utilise plutôt le NOTIFY car ça permet d'avoir une répercussion immédiate des changements.

Le serveur récursif (résolveur)

C'est celui à qui on parle en général ! (enfin à qui son OS et ses applications parlent)

Il enregistre dans son cache les réponses qu'il a faites (en fonction )

Exemple pratique : mise en place d'un nom de domaine

  • Achat du domaine miammiammiam.com auprès d'un registrar (par exemple OVH)
  • Configuration du domaine chez le registrar pour pointer sur nos serveurs DNS : ns1.superboite.fr et ns2.superboite.fr
  • Installation d'un serveur DNS sur nos deux serveurs NS1 et NS2
  • Configuration de notre zone miammiammiam.com sur NS1 en master, et configuration de NS2 en secondaire
  • Vérification du fonctionnement : le SOA renvoyé par NS1 doit être le même que celui envoyé par NS2, et le serveur DNS de .fr doit bien indiquer nos deux serveurs DNS

Problèmes courants

  • Mauvais serveur DNS indiqué auprès du registrar
  • Problème de synchronisation entre le DNS primaire et un ou plusieurs DNS secondaires (le serial du SOA est-il identique ?)
  • Problème de cache dans le résolveur de l'entreprise

Le résolveur envoie ses requêtes au hasard sur le DNS primaire ou l'un des DNS secondaires ! Il n'envoie pas déjà sur le primaire et ensuite sur les secondaires, c'est pas comme ça que ça marche !

Serveurs DNS

  • Bind (le plus répandu)
  • PowerDNS (très puissant et versatile)

Les deux permettent de faire résolveur et/ou serveur autoritaire. Pour 90% des cas, Bind suffit amplement.

Il est conseillé de séparer les deux fonctions toutefois. Je conseille de mettre un serveur résolveur qui n'écoute qu'en local sur 127.0.0.1 (ou sur une IP du réseau interne), et le serveur autoritaire sur l'IP publique (accessible depuis Internet). Perso je met un bind en local, et un PowerDNS (avec MySQL) en public.

Le futur

DNS n'est pas très sécurisé… Plusieurs solutions sont disponibles :

  • DNSSEC : signature des zones, permet de valider que la réponse DNS n'a pas été modifiée par le résolveur en cours de route. N'empêche pas d'espionner les requêtes et réponses DNS.
  • DNS over TLS, DNS over HTTPS : chiffrement de la connexion entre le client et le résolveur
  • DNSCrypt : chiffrement et signature entre résolveur et client

DNSSEC peut être combiné avec DoT, DoH et DNSCrypt.

Comparaison DoH, DoT et DNSCrypt : https://dnscrypt.info/faq/

Aller plus loin

Exercice 1

Identifier le parcours DNS d'un résolveur récursif pour www.cesi.fr avec dig. (Copier/coller chaque étape)

Exercice 2

Identifier les adresses IP du serveur de mail le plus prioritaire pour gmail.com.

Exercice 3

J'ai créé un nouveau site web sur dns1.sylvain.eliade.net mais il ne marche pas.

Identifier la ou les erreurs commises et indiquer une solution.

Exercice 4

Identifier le reverse DNS de l'adresse IP correspondant au serveur de www.cesi.fr

Exercice 5 (facultatif)

Créer une zone Bind pour un domaine fictif avec un A et un AAAA sur le domaine lui-même, deux serveurs DNS, un SOA valide, deux serveurs de mail, et un CNAME de www qui redirige sur le domaine lui-même. Exemple :

$TTL 3600
@ IN SOA ns1.domain.tld. hostmaster.domain.tld. (
 2017090401 ; SERIAL (DATE+NUMBER)
 86400 ; REFRESH (SEC)
 3600 ; RETRY (SEC)
 3600000 ; EXPIRE (SEC)
 300 ) ; MINIMUM (SEC)

@ IN NS ns1.domain.tld.
@ IN NS ns2.domain.tld.

ns1 IN A 10.1.2.2
ns2 IN A 10.1.2.3

@ IN A 127.0.0.1
@ IN AAAA ::1

@ IN MX 10 mx1.domain.tld.
@ IN MX 20 mx2.domain.tld.

mx1 IN A 10.1.1.1
mx2 IN A 10.1.1.2

www IN CNAME domain.tld.

Les point-virgules indiquent les commentaires

Exercice 6 (facultatif)

Installer bind (apt install bind9). Par défaut il est configuré comme résolveur récursif local. L'utiliser pour faire des requêtes locales, par exemple : dig www.cesi.fr @localhost

Exercice 7 (facultatif)

Mettre en place la zone bind créée à l'exercice 6 dans l'installation du Bind local. Un tuto utile : https://www.adrienfuret.fr/2017/09/04/debian-dns-bind/

Tester le fonctionnement avec dig : dig domain.tld @localhost