formations/cesi/hebergement_web/01-dns.md

% 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.

![](./img/hierarchie_dns.svg)

---

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` :

```bash
% 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/](https://dnscrypt.info/faq/)

---

## Aller plus loin

* [Problèmes courants de mauvaise configuration DNS](https://www.howtoforge.com/troubleshooting-common-dns-misconfiguration-errors)

---

## 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/](https://www.adrienfuret.fr/2017/09/04/debian-dns-bind/)

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