adlin/tutorial/ansible/nameserver.md

\newpage

Délégation de nom de domaine
============================

La deuxième solution proposée par Maatma est une délégation de nom de domaine.
Alors que jusque-là, c'était les serveurs DNS de Maatma qui répondaient aux
requêtes DNS, avec la délégation, ce sera à vous, dans votre VM, de répondre
aux requêtes venues tout droit d'Internet.

Voici les grandes étapes :

* choisir un serveur DNS autoritaire (BIND, NSD, Knot, PowerDNS, djbDNS, ...) ;
* éditer la zone de votre domaine ;
* configurer ce serveur pour qu'il réponde effectivement aux requêtes de votre zone ;
* tester avec `dig @votreIPv4locale ANY login-x.srs.example.tld` que votre serveur réagit bien correctement ;
* publier sur Maatma le nom de domaine où votre serveur de nom est joignable (généralement `ns.login-x.srs.example.tld`), il s'agit d'un enregistrement `NS` ;
* publier également sa *GLUE*, afin de résoudre le problème de poule et d'œuf (le domaine de votre serveur de noms étant dans la zone qu'il est censé servir, le bureau d'enregistrement enverra également l'IP correspondant au domaine) ;
* tester avec `dig @9.9.9.9 AAAA login-x.srs.example.tld` que votre serveur est bien joignable.

Un ouvrage de référence, qui répondra à l'intégralité de vos questions et manières d'utiliser votre serveur DNS se trouve à <http://www.zytrax.com/books/dns/>.


## Coller aux spécifications

Pourquoi une telle complexité apparente pour déléguer une zone DNS ?

Vous êtes sur le point d'obtenir le contrôle total d'un domaine :
`login-x.srs.example.tld.`. Cela signifie que vous allez pouvoir décider,
depuis votre propre serveur de noms (respectueux des
[standards](https://www.ietf.org/rfc/rfc1034.txt)), comment vous allez
répondre aux serveurs résolveurs des utilisateurs.

Le protocole DNS étant décentralisé, mais basé sur une arborescence
unique, il est nécessaire que les serveurs faisant autorité sur une
zone (`fr.`, `srs.example.tld.`, ...) fournissent toutes les informations
nécessaires pour que cette délégation fonctionne.

À cet instant, vous connaissez l'adresse IPv6 routable sur Internet de votre
serveur de noms (comme vous n'avez aujourd'hui qu'une seule machine, c'est
l'adresse de votre tunnel). Il va donc falloir indiquer à Internet que c'est
cette IP qu'il faut contacter, si l'on veut interroger le serveur faisant
autorité.

Concrètement, vous allez devoir vous attribuer un sous-domaine pour votre
serveur de noms, car c'est grâce à un enregistrement `NS` figurant dans la zone
parente (pour vous, la zone parente c'est `srs.example.tld`) que la délégation va se
faire.

Dans le cas basique, on va utiliser les serveurs de quelqu'un d'autre (d'un
hébergement spécialisé par exemple, ou celui de son bureau d'enregistrement
s'ils proposent ce service). Auquel cas, on fera figurer ce genre
d'informations :

<div lang="en-US">
```
42sh$ dig @e.ext.nic.fr. NS epita.fr.
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17590
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 3; ADDITIONAL: 0

;; QUESTION SECTION:
;; epita.fr.                    IN      NS

;; AUTHORITY SECTION:
epita.fr.               172800  IN      NS      tooty.ionis-it.com.
epita.fr.               172800  IN      NS      kazooie.ionis-it.com.
epita.fr.               172800  IN      NS      banjo.ionis-it.com.

;; Received 100 B
;; Time 2042-12-04 13:42:23 CET
;; From 2a00:d78:0:102:193:176:144:22@53(UDP) in 13.9 ms
```
</div>

La commande est envoyée spécifiquement aux serveurs de l'AFNIC, faisant
autorité pour la zone `fr.`. Les serveurs de l'AFNIC nous indiquent en retour,
que `epita.fr.` est déléguée à Ionis, et qu'elle dispose de 3 serveurs faisant
autorité.

Mais dans votre cas, vous hébergez vous-même votre propre serveur au sein de
votre zone, vous n'avez pas d'autre domaine à votre disposition. C'est
également le cas de Wikipédia :

<div lang="en-US">
```
42sh$ dig @d0.org.afilias-nst.org. NS wikipedia.org.
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 47396
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 3; ADDITIONAL: 3

;; QUESTION SECTION:
;; wikipedia.org.               IN      NS

;; AUTHORITY SECTION:
wikipedia.org.          86400   IN      NS      ns0.wikimedia.org.
wikipedia.org.          86400   IN      NS      ns2.wikimedia.org.
wikipedia.org.          86400   IN      NS      ns1.wikimedia.org.

[...]
```
</div>

On voit ici que pour résoudre les sous-domaines de `wikipedia.org.`, il faut
demander à `nsX.wikimedia.org.`. Mais comment obtenir alors, l'adresse de ces
serveurs de noms, puisque l'on ne sait pas où les contacter ...!

C'est là que les *GLUE records* entrent en jeu !

J'ai volontairement tronqué la sortie de la commande précédente, en entier, c'est :

<div lang="en-US">
```
42sh$ dig @d0.org.afilias-nst.org. NS wikipedia.org.
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 47396
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 3; ADDITIONAL: 3

;; QUESTION SECTION:
;; wikipedia.org.               IN      NS

;; AUTHORITY SECTION:
wikipedia.org.          86400   IN      NS      ns0.wikimedia.org.
wikipedia.org.          86400   IN      NS      ns2.wikimedia.org.
wikipedia.org.          86400   IN      NS      ns1.wikimedia.org.

;; ADDITIONAL SECTION:
ns0.wikimedia.org.      86400   IN      A       208.80.154.238
ns1.wikimedia.org.      86400   IN      A       208.80.153.231
ns2.wikimedia.org.      86400   IN      A       91.198.174.239

;; Received 143 B
;; Time 2042-12-04 13:42:23 CET
;; From 2001:500:f::1@53(UDP) in 15.2 ms
```
</div>

Afin d'éviter de tourner en rond sans jamais avoir réponse à notre question, en
même temps que de nous répondre sur qui sont les serveurs faisant autorité pour
la zone `wikipedia.org.`, les serveurs gérant la zone `org.` indiquent
également à quelle adresse ont peut les contacter.

Ce sont les administrateurs de la zone `wikipedia.org.` qui ont indiqué à
`org.` quels étaient leurs serveurs de noms. Et ils ont également donné des
*GLUE records*, pour permettre à la magie d'opérer.

À vous maintenant de créer votre zone, en envoyant sur Maatma, le nom de
domaine votre serveur de noms, ainsi que le *GLUE record* qui lui correspond.


## À propos de Maatma et du portail IPv4

Maatma met à votre disposition une plage d'IPv6 publique, directement
routable sur Internet. Mais aujourd'hui encore, de nombreuses
installations ne disposent pas de ce protocole de communication et ne
peuvent accéder aux machines connectées en IPv4 seulement.

Pour palier cela, Maatma met à votre disposition une IPv4 mutualisée
entre tous les SRS. Un service écoute sur la machine au bout de cette
IP, afin de distribuer le trafic entre vous, selon la demande du
client. Tous les protocoles ne permettent pas d'identifier le domaine
de destination, donc ce sont les protocoles HTTP et HTTPS qui sont
transmis sur vos IPv6.



## DNSSEC (bonus)

En bonus, vous devriez sécuriser les réponses envoyées par votre serveur DNS.

Pour ce faire, et toujours parce que l'on se trouve dans le cadre d'une
structure arborescente, les clefs publiques permettant de valider les
enregistrements d'un domaine en particulier, sont publiées dans la zone
parente. C'est pourquoi, vous disposez sur Maatma, d'une interface vous
permettant d'indiquer vos clefs publiques.

De nombreux articles sont disponibles sur Internet pour vous permettre de
configurer DNSSEC en fonction du serveur autoritaire que vous aurez choisi. À
vous de jouer !