Serveur de noms

Principes généraux

Le DNS (Domain Name System), c’est ce qui vous permet de reconnaître les noms de machines sur Internet. Ce sont les panneaux indicateurs et les annuaires téléphoniques du net.

C’est aussi ce qui indique où doit être envoyé le courrier, ainsi que plein d’autres détails techniques barbants dont la plupart des gens n’ont pas idée mais qui contribuent à la robustesse du réseau.

Ce système repose d’abord sur l’idée de zone. On commence par la zone racine, représentée par un point à l’extrémité d’une adresse. Cette zone racine contient les adresses des serveurs de noms autoritaires des tld (fr., de., dk., ph., com., net., org. etc). Chaque TLD constitue lui-même une zone contenant les adresses des serveurs de noms autoritaires pour les niveaux suivants.

zone dns

(image issue et modifiée depuis wikipedia)

Ainsi, pour peu que l’on connaisse les adresses des serveurs de la zone racine (aussi appelés serveurs racines, ou serveurs root), on peut normalement connaître n’importe quelle adresse dans le système de noms Internet : il suffit de commencer à la racine et parcourir la chaîne, zone après zone.

Cette action de parcourir la zone s’appelle la résolution (de noms). Les serveurs qui effectuent cette recherche sont dits résolveurs. Les serveurs qui portent l’information relative à chaque zone sont dits autoritaires.

Lorsqu’un résolveur a récupéré l’adresse d’une machine, d’un site web ou autre, ce serveur va mettre l’adresse en cache, en mémoire, et ce pour la durée de validité des données, indiquée par le serveur autoritaire sous le nom de TTL ou Time To Live.

Cette durée de validité implique un délai de propagation, le temps que les différents résolveurs mettent à jour les informations de la zone considérée. Plus le TTL est élevé, plus les délais de propagation des informations d’une zone seront importants, mais plus le trafic réseau sera réduit. C’est donc un choix d’équilibre.

DNSSEC

Il y a quelques années, des gens très intelligents ont commencé à s’inquiéter : DNS étant critique, il était donc important qu’il soit sécurisé.

En fait, il est assez facile, lorsque vous surfez sur le web, de vous envoyer sur de fausses adresses. On a donc cherché à s’assurer que le DNS ne délivre que des adresses authentiques, autrement dit, dont on soit sûr qu’elles sont vraies.

Pour ce faire, chaque détenteur d’un nom de domaine écrit sa zone DNS, puis la signe à l’aide d’un algorithme cryptographique.

Les résolveurs sont alors chargés de vérifier que ces signatures sont bien valides.

Logique non ?

Concrètement, ça permet à chacun d’être sûr d’être sur le bon site web, pas sur celui d’un pirate. On peut aussi y publier des informations sûres : c’est le principe de DANE/TLSA qui consiste à publier les empreintes des certificats de chiffrements TLS (sites web, serveurs mail).

Ces notions sont revues et approfondies sur cet article de lord.re.

Les enregistrements DNS et comment les utiliser

Les enregistrements DNS sont (généralement) structurés ainsi (entre parenthèse le nom anglais officiel du champ) :

NOM(NAME)    CLASSE(CLASS)    TYPE    TTL    DONNÉE(RDATA)

Le nom correspond à ce que vous cherchez.

La classe désigne internet (IN). Au début d’internet, d’autres classes étaient utilisées. Aujourd’hui de nombreuses documentations omettent la classe du fait qu’il n’y en a qu’une seule en activité, et que la plupart des résolveurs fonctionnent bien sans. Néanmoins, il arrive que certains programmes ou processus de résolution DNS plantent si la classe n’est pas présente.

Le type désigne le type de donnée du champ.

Le TTL désigne le Time To Live soit le temps pour lequel la donnée est considérée comme valide.

Enfin la donnée correspond à l’information désignée par le nom de type TYPE.

Voyons ensemble les différents TYPE :

@, $ORIGIN, $TTL

$ORIGIN” fait normalement référence au nom complet de la zone. Par exemple, chezmoi.tld.

Dans le cas où le fichier de zone ne comporte pas de directive “$ORIGIN”, le serveur de nom va en produire une avec le nom de la zone.

@” sera remplacé par “$ORIGIN”.

Si vous souhaitez davantage d’informations à propos de cette directive, vous pouvez lire cette documentation.

$TTL” est la durée de validité par défaut des données. La valeur recommandée est de 1 jour (1D).

Chaque enregistrement DNS peut avoir son propre TTL (MX et NS sont normalement très stables, et peuvent donc par exemple avoir des TTL d’une semaine voir plus, ceci permet de réduire la charge réseau).

$ORIGIN” et “$TTL” doivent être placés en premier dans le fichier de zone.

SOA

Le premier enregistrement avec “$ORIGIN” et “$TTL” s’appelle le SOA, pour Source Of Authority. C’est un élément très important. Le premier champ après SOA désigne le serveur de nom d’origine, en l’occurrence maitre.chezmoi.tld. et le dernier champ désigne l’adresse de l’administrateur du domaine. hostmaster.chezmoi.tld. se transformera en hostmaster@chezmoi.tld . Le premier point sera transformé en @. Vous avez dû mettre un alias sur hostmaster lors de la mise en place du serveur mail. Si vous ne pouvez pas et devez utiliser un point dans la partie “username” (avant @) de l’adresse (Vous vous compliquez vraiment la vie ! 😲), vous devrez alors mettre un “\” devant :

jean\.perrin.chezmoi.tld.

Il faut bien voir que le serveur Source d’autorité et l’adresse de l’administrateur du domaine ne sont pas forcément situés dans le domaine en question.

Le numéro de série peut-être de diverses formes, mais il doit toujours aller en augmentant à chaque mise à jour de la zone. Ça permet aux serveurs secondaires de repérer qu’il existe une version plus récente de la zone. Certains administrateurs utilisent la date suivie d’un numéro incrémenté (2017021312 pour une zone modifiée le 13/02/2017 pour la 12è fois - oui, ça peut arriver 😁). D’autres utilisent le timestamp du moment de l’édition (horodatage unix à la seconde près). D’autres se contentent de commencer à 1 et d’incrémenter. Chaque méthode a ses avantages.

Les valeurs du SOA (refresh, retry, expire, négative), indiquées ici, ainsi que celle du TTL, sont celles recommandées par les normes (RFC). Il est tout-à-fait possible de mettre d’autres valeurs, toutefois celles indiquées ici ont fait leurs preuves.

Les valeurs sont par défaut en secondes. On peut aussi indiquer les valeurs en heures (H) jours (D) ou semaines (W).

Refresh et retry indiquent au bout de combien de temps les serveurs secondaires (esclaves), mais néanmoins toujours autoritaires pour la zone, doivent renouveler la zone. Aujourd’hui beaucoup de serveurs de noms signalent à leurs esclaves qu’ils doivent récupérer les nouvelles informations. Ces valeurs ont donc moins d’importance.

Expire indique la date limite d’utilisation des informations pour le cas où les serveurs de noms de la zone ne sont plus accessibles. C’est bien différent du TTL.

La valeur negative est en fait le temps durant lequel une réponse NXDOMAIN (non existence de la donnée recherchée) sera conservée en cache.

A, AAAA

Encore une fois : {NOM, TTL, CLASSE, TYPE, RDATA}.

Les adresses de la machine maitre.chezmoi.tld sont donc enregistrées sous cette forme :

maitre          IN A        192.0.2.2
                IN AAAA     2001:db8:1:1::2

Rappelez-vous bien que le dernier point dans les adresses, implicite dans la plupart des documentations avec des adresses Internet, devient ici très important. Il représente la zone racine. Si une donnée d’adresse ne se termine pas par un point, elle sera complétée ou provoquera un bug.

CNAME

CNAME, pour Canonical NAME est un alias.

Dans l’exemple suivant, le nom canonique (réel) de www est maitre.

www IN CNAME maitre

C’est ce qu’on fait dans le cas des hôtes virtuels (ex : blog.chezmoi.tld, webmail.chezmoi.tld…).

NS

Une zone DNS devrait avoir au minimum 2 enregistrements NS d’après les règles communément admises. Techniquement la zone fonctionnera très bien avec un seul, pour autant que le serveur de nom derrière cet enregistrement n’ait jamais de problème.

Il n’y a pas de limite technique au nombre de serveurs NS (autoritaires) dans une zone, mais certains registres en mettent une (le registre du “dk.” a par exemple une limite à 7 NS). Ça n’a l’air de rien, mais suivant les limites ou restrictions techniques mises en place par tous les intermédiaires, ça peut monter vite.

Par exemple, sur le registre dk. cité précédemment, un bureau d’enregistrement très populaire a déjà cinq serveurs. Si on enregistre le domaine chez eux, il y aura alors ces cinq serveurs dans la liste de serveurs autoritaires, c’est comme ça, vous n’y pouvez rien. Par contre, vous pouvez les mettre en esclaves. Mais ils seront présents. Reste la place pour votre serveur maître, et peut-être un autre serveur d’un ami, sur lequel vous avez la main “par délégation”.

chezmoi.tld.   IN  NS   maitre.chezmoi.tld.

Cet enregistrement signifie : pour la zone chezmoi.tld, le serveur de nom autoritaire (NS) est maitre.chezmoi.tld. On aurait pu aussi l’écrire comme ça :

@     IN NS   maitre

Dans le premier cas, le @ se trouve remplacé par le $ORIGIN de la zone, soit en fait son nom (complet, jusqu’à la racine, c’est à dire avec un point final) et maitre est complété aussi en “maitre.chezmoi.tld.”.

Dans le deuxième cas, le nom recherché n’a toujours pas de point donc on complète avec “$ORIGIN”.

Pour que les serveurs de noms soient connus du reste du monde, il vous faut les enregistrer dans le registre (la zone du tld, voir “les principes généraux du DNS”). C’est d’ailleurs un des deux seuls enregistrements à faire sur le registre, avec l’enregistrement des clés DNSSEC. En effet, une fois que les serveurs autoritaires sont publiés, tout se passe directement sur votre serveur.

Lors de l’enregistrement des NS sur le registre (via le bureau d’enregistrement, ou registrar), on fournit en général deux champs : le nom d’hôte complet de la machine, maitre.chezmoi.tld en l’occurrence, et l’adresse(s). On parle dans ce cas de Glue Record. Comment faire pour connaître l’adresse de maitre.chezmoi.tld puisque c’est lui-même qui a les adresses de la zone chezmoi.tld ? Dans ce cas, exceptionnellement, l’adresse sera écrite directement dans le registre.

Pour enregistrer des serveurs de noms autoritaires sur le registre, il vous faut vous connecter chez votre bureau d’enregistrement. Chez GANDI, c’est facile :

Cliquez d’abord sur “Domaines” :

gandi glue 1

Choisissez ensuite votre domaine :

gandi glue 2

Sur la gauche, vous pouvez voir une entrée “Glue Records” :

gandi glue 3

Vous pouvez ajouter un nouveau serveur glue en cliquant sur “Ajouter”.

Dans l’exemple ci-dessous, ledzep.ouaf.xyz est un glue record déjà présent.

gandi glue 4

Entrez maintenant le nom de domaine de votre serveur autoritaire maitre puis l’adresse IP correspondante :

gandi glue 5

Validez, vous voyez apparaître ce nouveau glue record.

Maintenant que l’enregistrement glue est défini, cliquez sur le lien à gauche “Serveurs de nom”.

gandi glue 6

Dans ce nouvel écran, ajoutez en premier (DNS1) l’enregistrement glue défini précédemment. Vous pouvez aussi ajouter des serveurs secondaires, comme celui de gandi ns6.gandi.net.

gandi glue 7

On prend ensuite pour exemple l’interface web du registre danois (dk-hostmaster).

glue dk 1

(On doit fournir un nom d’hôte complet, ainsi qu’une adresse IP.)

glue dk 2

Cette étape vous a permis de créer une glue ou colle, de votre serveur dans le registre. Il ne reste plus qu’à le marquer comme autoritaire (c’est généralement un autre espace de l’interface qu’il vous faut utiliser).

glue dk 3

(On a ici la liste des adresses des serveurs de nom autoritaires pour la zone 22december.dk.)

Cette partie s’avère délicate car toujours différente d’un registre à l’autre. Certains ont des administrations centralisées, d’autres délèguent tout au bureau d’enregistrement. Il y a également le problème de la langue dans laquelle sont conçues et affichées ces interfaces.

Au sujet des registres, vous pouvez lire cet article.

MX

MX, c’est un peu comme NS, ça indique un service pour la zone, en l’occurrence le dépôt du courrier. L’enregistrement est un peu conçu de la même manière :

@     IN MX 10   mail1
@     IN MX 20   mail2

Pour la zone chezmoi.tld, le serveur de mail (MX) est mail1.chezmoi.tld.

Seule différence, le 10, qui indique la priorité. Quand on a plusieurs serveurs dans la zone, quel est le serveur qui doit recevoir le courrier en priorité ? Celui qui a le poids le plus faible.

En auto-hébergement, vous pouvez vous contenter d’utiliser le nom de domaine seul plutôt que de créer un sous-domaine mail correspondant à un champ A. Tout simplement :

@     IN MX 10   chezmoi.tld.

MX et NS ne peuvent pas être des redirections (CNAME).

Tout au plus accepte-t-on, avec réticence, des adresses IP. Mais normalement, les champs MX et NS pointent sur des noms d’hôtes.


Page suivante →