Le DNS est un protocole indispensable
au fonctionnement d'Internet. Non pas d'un point de vue technique,
mais d'un point de vue de son utilisation. Il est inconcevable aujourd'hui
d'utiliser des adresses IP en lieu et place des noms des sites web pour naviguer
sur Internet. Se souvenir de 58.250.12.36 est déjà compliqué, mais quand vous
surfez sur 40 sites différents par jour, cela fait quelques adresses à retenir.
Et ça, on ne sait pas faire...
Un arbre avec des branches
Le système DNS, vous l'utilisez tous les
jours quand vous naviguez sur Internet. Lorsque vous voulez accéder a google ,
le système DNS se charge de convertir (on parle de résolution)
le nom du site web demandé en adresse IP.
Un nom de domaine se décompose en plusieurs parties. Prenons l'exemple suivant :
www.google.fr
Chaque partie est séparée par un point.
On trouve l'extension en premier (en premier, mais en partant de la droite) ; on parle de Top Level Domain (TLD). Il existe des TLD nationaux (fr, it, de, es, etc.) et les TLD génériques (com, org, net, biz, etc.).
Ici, on a le découpage suivant :
www.google.fr
Il existe une infinité de possibilités pour la deuxième partie. Cela correspond à tous les sites qui existent : google.fr, ovh.net, twitter.com, etc.
Comme vous le voyez, google.fr est un sous-domaine de fr. Le domaine fr englobe tous les sous-domaines finissant par fr.
La troisième partie est exactement comme la seconde. On y retrouve généralement le fameux "www", ce qui nous donne des noms de domaine comme www.google.fr. www peut soit être un sous-domaine de google.fr, mais dans ce cas il pourrait y avoir encore des machines ou des sous-domaines à ce domaine, soit être directement le nom d'une machine.
Ici, www est le nom d'une machine dans le domaine google.fr.
On peut bien entendu ajouter autant de troisièmes parties que nécessaire, ce qui peut vous conduire à avoir un nom de domaine comme : http://adf.ly/1nFWzE.
Voici une toute petite partie de l'arborescence des noms Internet :
Mais revenons aux principes du DNS pour
étudier un dernier point important dans l'arborescence.
Dans l'architecture du service DNS, chaque label est responsable du niveau directement en dessous et uniquement de celui-ci. La racine est responsable du domaine .com, le .com de google.com et google.com de www.google.com, etc. Bien entendu, Google veut gérer lui-même le domaine google.com. L'organisme qui gère le domaine .com délègue donc la gestion de ce nom de domaine à Google.
Ainsi, chaque personne qui veut posséder un domaine sur Internet peut l'acheter, mais devra ensuite gérer un serveur DNS pour publier ses adresses.
Cependant, la plupart des entreprises qui vendent des noms de domaine (qu'on appelle registrar) proposent de gérer elles-mêmes vos enregistrements DNS, mais c'est moins fun.
La résolution, comment ça marche ?
Vous êtes connectés à votre réseau, votre
serveur DHCP vous a donné une adresse IP, un masque de sous-réseau et
probablement une passerelle par défaut, ainsi qu'un serveur DNS.
Imaginez que vous entrez www.ioriyagami.com dans votre navigateur. Lorsque vous entrez ce nom, votre machine doit commencer par le résoudre en une adresse IP.
Vous allez donc demander une résolution au serveur DNS que vous avez reçu par le DHCP. Celui-ci a deux moyens pour vous fournir la réponse :
La plupart du temps, votre serveur DNS est
bien peu savant et demande à un autre serveur de lui donner la réponse. En
effet, chaque serveur DNS étant responsable d'un domaine ou
d'un petit nombre de domaines, la résolution consiste à aller chercher la bonne
information sur le bon serveur.
Nous voulons donc joindre le site www.ioriyagami.com et voilà ce que va faire mon serveur DNS
Tout d'abord, il est évident que cette information ne se trouve pas sur notre serveur, car ce n'est pas lui qui est en charge du ioriyagami
Pour obtenir cette résolution, notre serveur va procéder de façon rigoureuse et commencer par là où il a le plus de chance d'obtenir l'information, c'est-à-dire au point de départ de notre arborescence.
Maintenant, vous avez l'adresse IP de www.ioriyagami.com !
Existe-t-il aussi un protocole pour convertir une adresse IP en nom de domaine ?
Non, c'est inutile. Le DNS sait faire cela, on parle alors de reverse DNS et de résolution inverse.
La gestion internationale des noms de
domaine
Même si le système DNS n'est pas
indispensable au fonctionnement d'Internet, il en est un élément
incontournable.
Le système de noms de domaine est géré par un organisme américain appelé l'ICANN. Celui-ci dépend directement du Département du Commerce des États-Unis. L'ICANN est responsable de la gestion des 13 serveurs DNS qui gèrent la racine du DNS. Ces 13 serveurs connaissent les adresses IP des serveurs DNS gérant les TLD (les .fr, .com; org, etc.)
Il n'y a vraiment que 13 serveurs racine ?
Oui et non.
En fait, après plusieurs attaques sur les serveurs racine, on s'est rendu compte de la faiblesse de n'avoir que 13 serveurs et de la menace que cela pouvait représenter pour le fonctionnement d'Internet.
On a donc mis en place un système qui duplique les 13 serveurs en différents endroits d'Internet. Il y a donc réellement aujourd'hui plusieurs centaines de serveurs racine qui dupliquent les informations des 13 serveurs d'origine.
Le mécanisme qui permet cette duplication de serveurs, et notamment d'adresses IP, s'appelle l'anycast
C'est l'ICANN qui autorise la création d'une nouvelle extension, comme le .xxx il y a plusieurs mois ou l'utilisation de caractères non-latins (arabes, chinois, japonais, etc.), il y a quelques années.
L'ICANN délègue ensuite les domaines de premier niveau à divers organismes. Pour l'Europe, c'est le RIPE qui délègue lui-même à L'AFNIC qui est responsable du domaine .fr (ainsi que des extensions correspondantes à la France d'outre-mer) ; pour le domaine .com, c'est VeriSign qui s'en occupe. Les labels inférieurs correspondent généralement à des sites ou à des entreprises, et la gestion du nom de domaine leur revient.
Configuration d’un serveur DNS (BIND) sur debian
Première chose, quand vous possédez un domaine, vous devez avoir deux serveurs DNS, un serveur primaire et un serveur secondaire. Ceci est nécessaire pour pouvoir garantir que si l'un tombe en panne, le second permettra toujours d'accéder à vos serveurs.
Le domaine que nous allons configurer sera : reseau.fr.
Il existera aussi une autre machine, blog.reseau.fr,
qui sera un alias de www.reseau.fr.
Un alias est une association entre un nom de machine et un autre nom de machine, alors que le DNS a l'habitude de faire la liaison entre un nom de machine et une adresse IP. C'est donc une association particulière du DNS.
Installation de Bind9
La configuration se fait en deux temps. Nous devons tout d'abord déclarer à notre serveur quels seront les noms de domaine qu'il va devoir gérer, on appelle ça des zones. Ensuite, nous devrons configurer ces zones, grâce à un fichier de configuration par zones.
Une zone se déclare de cette façon :
Vous pouvez vérifier la syntaxe du
fichier named.conf grâce à la commande
named-checkconf /etc/bind/named.conf
Celle-ci nous sera de nouveau utile pour tester le format des fichiers de zone eux-mêmes
Passons maintenant à la configuration de notre zone.
Dans ce fichier de zone, nous allons indiquer
des enregistrements. Il en existe de plusieurs types :
La première info est un TTL (Time
to Live). Quand quelqu'un va interroger votre serveur
DNS pour obtenir des informations, ces informations vont être stockées
en cache chez cette personne (dans la mémoire de son serveur DNS, pour
éviter qu'il vienne nous réinterroger de nombreuses fois s'il a de nouveau
besoin d'une information). Ce TTL est la durée pendant laquelle les
informations sont conservées en cache. Ce délai passé, une nouvelle demande
devra être faite au serveur. Le TTL est défini ici sur 1 semaine. En fonction
de la fréquence de vos mises à jour, vous pouvez décider de baisser cette
valeur pour que vos clients aient leurs informations à jour.
La deuxième info est la variable ORIGIN. Celle-ci est optionnelle. Vous voyez les petits @ plus loin ? Ces @ prennent la valeur de la variable ORIGIN. En l'absence de variable ils prendront la valeur du nom de votre zone défini dans le fichier named.conf (reseau.fr ici).
Vient ensuite notre premier enregistrement, c'est un enregistrement de type SOA (Start Of Authority). Le type SOA est suivi de deux informations. La première est le nom du serveur de domaine principal (master) et la seconde est l'adresse mail de l'administrateur du domaine (en remplaçant l'arrobase par un point). Suivent entre parenthèses différentes valeurs.
Nous trouvons ensuite les enregistrements, du
moins ceux qui nous intéressent !
Les enregistrements se découpent en 4 parties sur une ligne (parfois 5 pour des enregistrements spécifiques).
La première information, c'est l'hôte de votre domaine. Nous avons parlé du @ tout à l'heure qui est remplacé par la valeur de $ORIGIN (le cas échéant par le nom de votre zone). Notez qu'on peut ne rien mettre du tout si on veut parler du domaine entier. Rien, @, ou un nom de machine ou de sous-domaine au choix.
La première information, c'est l'hôte de votre domaine. Nous avons parlé du @ tout à l'heure qui est remplacé par la valeur de $ORIGIN (le cas échéant par le nom de votre zone). Notez qu'on peut ne rien mettre du tout si on veut parler du domaine entier. Rien, @, ou un nom de machine ou de sous-domaine au choix.
Le second, représente la classe. Ici, elle spécifie qu'il s'agit d'un enregistrement concernant Internet. Il existe d'autres valeurs mais elles ne sont pas utilisées, donc on met toujours IN.
Le troisième spécifie le type d'enregistrement dont on a détaillé les différents types précédemment.
Enfin, le dernier spécifie la valeur de l'enregistrement dépendant du type. Un type A attendra une adresse IP, un type PTR attendra un nom d'hôte, etc.
On trouve parfois, juste avant cette dernière valeur, un nombre qui indique le "poids" d'un enregistrement. On verra plus loin dans quel cas c'est utile.
On commence généralement par les enregistrements des serveurs gérant notre domaine et les services associés (le mail en l'occurrence). Dans notre cas il s'agit des types NS et MX. On utilise l'@ parce que ces enregistrements ne déterminent pas un hôte en particulier, mais bien le domaine entier.
le
"." situé à la fin de ns1.reseau.fr, car celui-ci est
extrêmement important. Cette valeur doit être un FQDN et le FQDN
contient le "." représentant la racine du DNS. Si vous aviez écrit
ns1.reseau.fr sans le ".", votre serveur aurait automatiquement
rajouté à la fin le FQDN de votre zone, ce qui aurait donné
ns1.reseau.fr.reseau.fr. ; ce qui n'a plus du tout la même valeur !
Ceci étant, réécrire à chaque fois le FQDN c'est un peu contraignant. Et comme on sait que, ne pas finir sa ligne par un "." rajoute au FQDN de votre zone, on peut se permettre de n'écrire que "ns1". Ainsi, votre serveur rajoutera "reseau.fr." et on aura le FQDN que l'on cherchait à obtenir.
Voyez la deuxième ligne qui utilise cette syntaxe raccourcie.
Les enregistrements MX utilisent la même syntaxe que pour les NS et indiquent l'adresse IP d'un serveur de messagerie, à cela près que nous avons rajouté un chiffre devant "mx1". Nous avons dit tout à l'heure que ce chiffre déterminait le "poids" d'un enregistrement, on parle aussi de priorité. Nous avons deux serveurs MX : mx1 et mx2 ; cette valeur va permettre de déterminer lequel des deux doit être utilisé en priorité. Plus elle est basse, plus le serveur est prioritaire.
Mais nous avons aussi deux serveurs NS ! Comment se passe cette priorité, étant donné qu'il n'y a pas de valeur pour les départager ?
Dans ce cas, c'est chacun son tour. Sur une machine Linux, essayez plusieurs fois de suite cette commande :
Vous verrez que les réponses que vous recevez
ne sont jamais dans le même ordre. Cela s'appelle du Round-Robin,
c'est une méthode qui permet d'équilibrer la charge entre les deux serveurs
pour ne pas les surcharger, car un serveur sera autant consulté que les autres
serveurs du même type.
Très bien, maintenant on sait que les serveurs mail de notre domaine sont mx1.reseau.fr et mx2.reseau.fr. Cependant, on ne sait toujours pas leurs adresses IP alors que c'est quand même le but d'un serveur DNS, non ?
D'ailleurs, vous voyez qu'ensuite nous définissons l'adresse IP de mx1 (sans . à la fin, donc mx1.reseau.fr ! ) avec un enregistrement de type A.
C'est ce qu'on appelle un Glue Record. On définit une première fois le nom d'hôte du serveur NS, puis on définit l'adresse IP de cet hôte. On doit faire cela, car un enregistrement NS associe un nom de serveur au nom du domaine. Il faut donc ajouter un enregistrement A pour le nom de ce serveur.
On retrouve ensuite les enregistrements les plus courants, ceux de type A (et AAAA quand on a de l'IPv6). En effet, le rôle principal du DNS est de faire correspondre un nom d'hôte avec son adresse IP, et c'est ce que fait le type A.
La syntaxe est relativement simple comme vous pouvez le voir :
Comme pour les autres enregistrements,
"tuto" ou "tuto.reseau.fr." revient au même. N'oubliez pas
le point si vous optez pour le FQDN.
Le type CNAME est aussi simple à comprendre. On fait correspondre un nom d'hôte à un autre nom d'hôte. Bien sûr, si "blog" pointe sur "www", l'enregistrement www doit exister.
Je le répète encore une fois : si vous choisissez le FQDN, n'oubliez pas le point, c'est une des premières causes d'erreurs dans les configurations DNS.
Voilà, notre zone est maintenant configurée sur notre serveur master. Vous devez redémarrer BIND pour que les changements soient pris en compte :
La configuration du serveur slave est donc relativement simple, tout se passe dans le named.conf. Il n'y a pas de fichier de zone à configurer étant donné que celui-ci sera reçu du master.
Si vous souhaitez tester complètement la mise en place du serveur DNS avec master et slave, vous pouvez tout à fait mettre en place le serveur slave sur une autre de vos machines virtuelles.
On commence par installer Bind comme pour le master et on édite /etc/bind/named.conf.
Pour l'instant, nous avons vu le protocole
DNS comme un moyen de résoudre un nom d'hôte en une adresse IP. Nous avons
parlé des enregistrements de type PTR et vous savez donc que DNS permet aussi
de faire le travail inverse. C'est une résolution inverse.
Votre serveur DNS se doit de pouvoir résoudre une adresse IP en un nom d'hôte. C'est ce que nous allons faire ici.
Retournons dans notre fichier named.conf afin d'ajouter cette zone inverse. Nous allons déclarer la zone inverse de notre adressage IP, ici c'est 192.168.0.0/24.
Alors qu'une zone "normale" se déclare de façon plutôt logique, une zone inverse doit respecter une certaine forme concernant le nom de la zone :
Voilà pour la déclaration. Il faut juste
faire attention au nommage de la zone, la partie réseau de l'adresse IP à
l'envers, puis ".in-addr.arpa".
On crée ensuite le fichier de zone.
Les points auxquels il faut faire attention :
Vérification
On va quand même vérifier le fonctionnement
de notre zone maintenant.
Commencez déjà par redémarrer votre serveur de nom pour prendre en compte les changements de configuration :
Il existe plusieurs commandes pour faire des interrogations DNS. La commande la plus utilisée est
Le programme qui fait toutes les résolutions DNS pour votre machine s'appelle le resolver. Ainsi, chaque programme qui a besoin de faire une résolution DNS s'adresse au resolver.
Son fichier de configuration se trouve dans /etc/resolv.conf qui doit au moins contenir l'adresse d'un serveur DNS à interroger :
Oui, votre serveur va s'interroger lui-même.
Vous pouvez spécifier d'autres serveurs, un par nameserver. Ce fichier peut aussi
contenir des informations sur votre domaine ou le domaine de recherche.
On peut maintenant commencer nos tests :
Nous allons donc utiliser la commande host qui permet de faire une interrogation DNS.
Sa syntaxe est la suivante:
On peut ainsi indiquer le type de la requête
(NS, A, MX, CNAME, etc.), le nom à interroger, ainsi que l'adresse IP du
serveur que l'on peut préciser.
Par exemple, si l'on cherche l'adresse des serveurs DNS du domaine reseau.fr :
Si tout se passe bien, c'est parfait. Dans le
cas contraire, penser à vérifier que les syntaxes de vos fichiers de zones sont
bonnes, avec "named-checkzone", et que vous avez bien pensé à
relancer votre serveur Bind, etc.
Nous venons de voir que grâce à la commande host (ou dig), il est possible de demander toute information contenue dans vos zones DNS, ou même sur des serveurs situés sur Internet !
Un arbre avec des branches
Une arborescence ordonnée
Un nom de domaine se décompose en plusieurs parties. Prenons l'exemple suivant :
www.google.fr
Chaque partie est séparée par un point.
On trouve l'extension en premier (en premier, mais en partant de la droite) ; on parle de Top Level Domain (TLD). Il existe des TLD nationaux (fr, it, de, es, etc.) et les TLD génériques (com, org, net, biz, etc.).
Ici, on a le découpage suivant :
www.google.fr
Il existe une infinité de possibilités pour la deuxième partie. Cela correspond à tous les sites qui existent : google.fr, ovh.net, twitter.com, etc.
Comme vous le voyez, google.fr est un sous-domaine de fr. Le domaine fr englobe tous les sous-domaines finissant par fr.
La troisième partie est exactement comme la seconde. On y retrouve généralement le fameux "www", ce qui nous donne des noms de domaine comme www.google.fr. www peut soit être un sous-domaine de google.fr, mais dans ce cas il pourrait y avoir encore des machines ou des sous-domaines à ce domaine, soit être directement le nom d'une machine.
Ici, www est le nom d'une machine dans le domaine google.fr.
On peut bien entendu ajouter autant de troisièmes parties que nécessaire, ce qui peut vous conduire à avoir un nom de domaine comme : http://adf.ly/1nFWzE.
Voici une toute petite partie de l'arborescence des noms Internet :
Chaque "partie" est
appelée label et l'ensemble des labels constitue un FQDN
: Fully Qualified Domain Name. Ce FQDN est unique. Par
convention, un FQDN se finit par un point, car au-dessus des TLD il y a la
racine du DNS, tout en haut de l'arbre. Ce point disparaît lorsque
vous utilisez les noms de domaine avec votre navigateur, mais vous verrez qu'il
deviendra très important lorsque nous configurerons notre propre serveur DNS.
Au niveau DNS, www.google.fr n'est pas un FQDN,
car il manque le point à la fin.
Tout FQDN sur Internet doit
obligatoirement se finir par un point, comme www.google.com. qui est alors bien
un FQDN, car on est sûr qu'il n'y a pas de domaine au-dessus.
Si jamais vous administrez un
réseau, et que vous possédez le domaine mondomaine.com, vous pouvez vous amuser
à ajouter dans votre serveur DNS une machine qui s'appellera www.ioriyagami.fr.mondomaine.com.
Ainsi, dès qu'une personne qui utilise votre serveur DNS demande www.ioriyagami.fr en oubliant de mettre le . à la fin, elle sera envoyée vers votre la machine www.ioriyagami.fr.mondomaine.com. !
Hacking power !
Ainsi, dès qu'une personne qui utilise votre serveur DNS demande www.ioriyagami.fr en oubliant de mettre le . à la fin, elle sera envoyée vers votre la machine www.ioriyagami.fr.mondomaine.com. !
Hacking power !
Dans l'architecture du service DNS, chaque label est responsable du niveau directement en dessous et uniquement de celui-ci. La racine est responsable du domaine .com, le .com de google.com et google.com de www.google.com, etc. Bien entendu, Google veut gérer lui-même le domaine google.com. L'organisme qui gère le domaine .com délègue donc la gestion de ce nom de domaine à Google.
Ainsi, chaque personne qui veut posséder un domaine sur Internet peut l'acheter, mais devra ensuite gérer un serveur DNS pour publier ses adresses.
Cependant, la plupart des entreprises qui vendent des noms de domaine (qu'on appelle registrar) proposent de gérer elles-mêmes vos enregistrements DNS, mais c'est moins fun.
Nous savons donc que le DNS est organisé sous forme d'une
grosse arborescence, et que chaque partie de l'arborescence peut être gérée par
la personne qui la possède.
La résolution, comment ça marche ?
Vous êtes connectés à votre réseau, votre
serveur DHCP vous a donné une adresse IP, un masque de sous-réseau et
probablement une passerelle par défaut, ainsi qu'un serveur DNS.Imaginez que vous entrez www.ioriyagami.com dans votre navigateur. Lorsque vous entrez ce nom, votre machine doit commencer par le résoudre en une adresse IP.
Vous allez donc demander une résolution au serveur DNS que vous avez reçu par le DHCP. Celui-ci a deux moyens pour vous fournir la réponse :
·
il connaît
lui-même la réponse ;
·
il doit la
demander à un autre serveur, car il ne la connaît pas.
Nous voulons donc joindre le site www.ioriyagami.com et voilà ce que va faire mon serveur DNS
Tout d'abord, il est évident que cette information ne se trouve pas sur notre serveur, car ce n'est pas lui qui est en charge du ioriyagami
Pour obtenir cette résolution, notre serveur va procéder de façon rigoureuse et commencer par là où il a le plus de chance d'obtenir l'information, c'est-à-dire au point de départ de notre arborescence.
·
Il va demander aux
serveurs racine l'adresse IP de www.ioriyagami.com. Mais comme les
serveurs racine ne sont pas responsables de ce domaine, ils vont le rediriger
vers un autre serveur qui peut lui donner une information et qui dépend de la
racine, le serveur DNS de com.
·
Il demande
ensuite au serveur DNS de com l'adresse IP de www.ioriyagami.com. Mais comme
auparavant, le serveur com renvoie l'adresse IP du serveur DNS qui dépend de
lui, le serveur DNS deioriyagami.com.
·
Enfin, il demande
au serveur DNS de siteduzero.com l'adresse IP de www.ioriyagami.com et là, ça marche : le serveur de ioriyagami.com.
connaît l'adresse IP correspondante et peut la renvoyer.
Existe-t-il aussi un protocole pour convertir une adresse IP en nom de domaine ?
Non, c'est inutile. Le DNS sait faire cela, on parle alors de reverse DNS et de résolution inverse.
La gestion internationale des noms de
domaine
Même si le système DNS n'est pas
indispensable au fonctionnement d'Internet, il en est un élément
incontournable. Le système de noms de domaine est géré par un organisme américain appelé l'ICANN. Celui-ci dépend directement du Département du Commerce des États-Unis. L'ICANN est responsable de la gestion des 13 serveurs DNS qui gèrent la racine du DNS. Ces 13 serveurs connaissent les adresses IP des serveurs DNS gérant les TLD (les .fr, .com; org, etc.)
Il n'y a vraiment que 13 serveurs racine ?
Oui et non.
En fait, après plusieurs attaques sur les serveurs racine, on s'est rendu compte de la faiblesse de n'avoir que 13 serveurs et de la menace que cela pouvait représenter pour le fonctionnement d'Internet.
On a donc mis en place un système qui duplique les 13 serveurs en différents endroits d'Internet. Il y a donc réellement aujourd'hui plusieurs centaines de serveurs racine qui dupliquent les informations des 13 serveurs d'origine.
Le mécanisme qui permet cette duplication de serveurs, et notamment d'adresses IP, s'appelle l'anycast
C'est l'ICANN qui autorise la création d'une nouvelle extension, comme le .xxx il y a plusieurs mois ou l'utilisation de caractères non-latins (arabes, chinois, japonais, etc.), il y a quelques années.
L'ICANN délègue ensuite les domaines de premier niveau à divers organismes. Pour l'Europe, c'est le RIPE qui délègue lui-même à L'AFNIC qui est responsable du domaine .fr (ainsi que des extensions correspondantes à la France d'outre-mer) ; pour le domaine .com, c'est VeriSign qui s'en occupe. Les labels inférieurs correspondent généralement à des sites ou à des entreprises, et la gestion du nom de domaine leur revient.
Configuration d’un serveur DNS (BIND) sur debian
Préparation
Présentons d'abord ce que nous allons configurer ici.Première chose, quand vous possédez un domaine, vous devez avoir deux serveurs DNS, un serveur primaire et un serveur secondaire. Ceci est nécessaire pour pouvoir garantir que si l'un tombe en panne, le second permettra toujours d'accéder à vos serveurs.
Le domaine que nous allons configurer sera : reseau.fr.
·
Ce nom de domaine
sera géré par deux serveurs dns :
o
ns1.reseau.fr -
192.168.0.1 sera notre serveur maître ;
o
ns2.reseau.fr -
192.168.0.2 sera notre serveur esclave.
·
Les adresses
email de ce nom de domaine seront gérées par deux serveurs de messagerie : il doit y avoir un serveur de messagerie qui permet de recevoir des
mails pour les adresses de notre domaine.
o
mx1.reseau.fr -
192.168.0.3 ;
o
mx2.reseau.fr -
192.168.0.4.
·
Ce nom de domaine
possédera deux machines :
o
tuto.reseau.fr -
192.168.0.5 ;
o
www.reseau.fr - 192.168.0.6.
Un alias est une association entre un nom de machine et un autre nom de machine, alors que le DNS a l'habitude de faire la liaison entre un nom de machine et une adresse IP. C'est donc une association particulière du DNS.
Installation de Bind9
apt-get install bind9
Les fichiers de configuration de Bind se
trouvent, comme on peut s'y attendre, dans /etc/bind.La configuration se fait en deux temps. Nous devons tout d'abord déclarer à notre serveur quels seront les noms de domaine qu'il va devoir gérer, on appelle ça des zones. Ensuite, nous devrons configurer ces zones, grâce à un fichier de configuration par zones.
Configuration du serveur master
Déclaration des zones
zone "reseau.fr" {
type master;
file "/etc/bind/db.reseau.fr";
allow-transfer { 192.168.0.2; };
};
Le type indique si vous êtes master
ou slave sur la zone, c'est-à-dire si c'est vous qui effectuez les
mises à jour (master) ou si vous les recevez d'un autre serveur (slave).
File indique le fichier dans lequel sera configurée votre zone.
Allow-transfer indique le serveur qui pourra recevoir vos mises à jour. Bien entendu, cette directive n'existe que dans le cas d'un serveur master.
File indique le fichier dans lequel sera configurée votre zone.
Allow-transfer indique le serveur qui pourra recevoir vos mises à jour. Bien entendu, cette directive n'existe que dans le cas d'un serveur master.
named-checkconf /etc/bind/named.conf
Celle-ci nous sera de nouveau utile pour tester le format des fichiers de zone eux-mêmes
Passons maintenant à la configuration de notre zone.
Configuration de la zone du serveur master
On édite donc le fichier /etc/bind/db.reseau.fr. Afin d'avoir une configuration "basique", vous pouvez faire une copie de /etc/bind/db.local.
cp /etc/bind/db.local /etc/bind/db.reseau.fr
vim /etc/bind/db.reseau.fr
·
A : c'est le type
le plus courant, il fait correspondre un nom d'hôte à une adresse IPv4 ;
·
AAAA : fait
correspondre un nom d'hôte à une adresse IPv6 ;
·
CNAME : permet de
créer un alias pointant sur un autre nom d'hôte ;
·
NS : définit le
ou les serveurs DNS du domaine ;
·
MX : définit le
ou les serveurs de mail du domaine ;
·
PTR : fait
correspond une IP à un nom d'hôte. Il n'est utilisé que dans le cas d'une zone
inverse, que nous verrons plus loin
·
SOA : donne les
infos de la zone, comme le serveur DNS principal, l'adresse mail de
l'administrateur de la zone, le numéro de série de la zone et des durées que
nous détaillerons.
La deuxième info est la variable ORIGIN. Celle-ci est optionnelle. Vous voyez les petits @ plus loin ? Ces @ prennent la valeur de la variable ORIGIN. En l'absence de variable ils prendront la valeur du nom de votre zone défini dans le fichier named.conf (reseau.fr ici).
Vient ensuite notre premier enregistrement, c'est un enregistrement de type SOA (Start Of Authority). Le type SOA est suivi de deux informations. La première est le nom du serveur de domaine principal (master) et la seconde est l'adresse mail de l'administrateur du domaine (en remplaçant l'arrobase par un point). Suivent entre parenthèses différentes valeurs.
·
Le serial
peut être comparé à un numéro de version de votre zone. Il doit être incrémenté
à chaque modification. Cela indique à votre serveur que votre zone a été mise à
jour et qu'il faut envoyer la notification à vos serveurs esclaves. Les best
practices recommandent une syntaxe particulière pour le serial de la forme
AAAAMMJJXX (où XX est la version du jour en question). Cela vous permet entre
autres de savoir la date de la dernière mise à jour de votre zone.
·
Refresh est le temps au bout duquel les enregistrements sont
stockés sur le serveur slave. Passer ce délai, le serveur slave
demandera une nouvelle mise à jour au serveur master.
·
Retry est le temps qu'attendra le serveur slave
dans le cas où le serveur master contacté n'est pas joignable pour
faire un nouvel essai.
·
Expire est le temps pendant lequel le serveur slave
continuera à essayer de contacter le serveur master.
·
Minimum est la durée minimale du cache ; elle est en général
égale à Refresh.
Les enregistrements se découpent en 4 parties sur une ligne (parfois 5 pour des enregistrements spécifiques).
La première information, c'est l'hôte de votre domaine. Nous avons parlé du @ tout à l'heure qui est remplacé par la valeur de $ORIGIN (le cas échéant par le nom de votre zone). Notez qu'on peut ne rien mettre du tout si on veut parler du domaine entier. Rien, @, ou un nom de machine ou de sous-domaine au choix.
La première information, c'est l'hôte de votre domaine. Nous avons parlé du @ tout à l'heure qui est remplacé par la valeur de $ORIGIN (le cas échéant par le nom de votre zone). Notez qu'on peut ne rien mettre du tout si on veut parler du domaine entier. Rien, @, ou un nom de machine ou de sous-domaine au choix.
Le second, représente la classe. Ici, elle spécifie qu'il s'agit d'un enregistrement concernant Internet. Il existe d'autres valeurs mais elles ne sont pas utilisées, donc on met toujours IN.
Le troisième spécifie le type d'enregistrement dont on a détaillé les différents types précédemment.
Enfin, le dernier spécifie la valeur de l'enregistrement dépendant du type. Un type A attendra une adresse IP, un type PTR attendra un nom d'hôte, etc.
On trouve parfois, juste avant cette dernière valeur, un nombre qui indique le "poids" d'un enregistrement. On verra plus loin dans quel cas c'est utile.
On commence généralement par les enregistrements des serveurs gérant notre domaine et les services associés (le mail en l'occurrence). Dans notre cas il s'agit des types NS et MX. On utilise l'@ parce que ces enregistrements ne déterminent pas un hôte en particulier, mais bien le domaine entier.
@ IN NS ns1.reseau.fr.
Cette ligne se traduit donc
par : "ns1.reseau.fr est un serveur de nom de domaine de reseau.fr"
Ceci étant, réécrire à chaque fois le FQDN c'est un peu contraignant. Et comme on sait que, ne pas finir sa ligne par un "." rajoute au FQDN de votre zone, on peut se permettre de n'écrire que "ns1". Ainsi, votre serveur rajoutera "reseau.fr." et on aura le FQDN que l'on cherchait à obtenir.
Voyez la deuxième ligne qui utilise cette syntaxe raccourcie.
Les enregistrements MX utilisent la même syntaxe que pour les NS et indiquent l'adresse IP d'un serveur de messagerie, à cela près que nous avons rajouté un chiffre devant "mx1". Nous avons dit tout à l'heure que ce chiffre déterminait le "poids" d'un enregistrement, on parle aussi de priorité. Nous avons deux serveurs MX : mx1 et mx2 ; cette valeur va permettre de déterminer lequel des deux doit être utilisé en priorité. Plus elle est basse, plus le serveur est prioritaire.
Mais nous avons aussi deux serveurs NS ! Comment se passe cette priorité, étant donné qu'il n'y a pas de valeur pour les départager ?
Dans ce cas, c'est chacun son tour. Sur une machine Linux, essayez plusieurs fois de suite cette commande :
host -t NS google.fr
Très bien, maintenant on sait que les serveurs mail de notre domaine sont mx1.reseau.fr et mx2.reseau.fr. Cependant, on ne sait toujours pas leurs adresses IP alors que c'est quand même le but d'un serveur DNS, non ?
D'ailleurs, vous voyez qu'ensuite nous définissons l'adresse IP de mx1 (sans . à la fin, donc mx1.reseau.fr ! ) avec un enregistrement de type A.
C'est ce qu'on appelle un Glue Record. On définit une première fois le nom d'hôte du serveur NS, puis on définit l'adresse IP de cet hôte. On doit faire cela, car un enregistrement NS associe un nom de serveur au nom du domaine. Il faut donc ajouter un enregistrement A pour le nom de ce serveur.
On retrouve ensuite les enregistrements les plus courants, ceux de type A (et AAAA quand on a de l'IPv6). En effet, le rôle principal du DNS est de faire correspondre un nom d'hôte avec son adresse IP, et c'est ce que fait le type A.
La syntaxe est relativement simple comme vous pouvez le voir :
tuto IN A 192.168.0.5
Le type CNAME est aussi simple à comprendre. On fait correspondre un nom d'hôte à un autre nom d'hôte. Bien sûr, si "blog" pointe sur "www", l'enregistrement www doit exister.
Je le répète encore une fois : si vous choisissez le FQDN, n'oubliez pas le point, c'est une des premières causes d'erreurs dans les configurations DNS.
Voilà, notre zone est maintenant configurée sur notre serveur master. Vous devez redémarrer BIND pour que les changements soient pris en compte :
# /etc/init.d/bind9 restart
Configuration du serveur slave
Nous avons prévu deux serveurs dans notre architecture . Celui que nous venons de configurer est le master ; celui que nous allons faire sera le slave. Les modifications se font sur le master, et celui-ci enverra des notifications aux slaves (il peut y en avoir plusieurs) pour que leurs zones soient mises à jour.La configuration du serveur slave est donc relativement simple, tout se passe dans le named.conf. Il n'y a pas de fichier de zone à configurer étant donné que celui-ci sera reçu du master.
Si vous souhaitez tester complètement la mise en place du serveur DNS avec master et slave, vous pouvez tout à fait mettre en place le serveur slave sur une autre de vos machines virtuelles.
On commence par installer Bind comme pour le master et on édite /etc/bind/named.conf.
zone "reseau.fr" {
type slave;
file "/var/cache/bind/db.reseau.fr";
masters { 192.168.0.1;};
};
Et c'est tout !
La directive
masters
indique l'adresse IP du serveur master duquel nous allons recevoir les
mises à jour de notre zone.Résolution inverse
Votre serveur DNS se doit de pouvoir résoudre une adresse IP en un nom d'hôte. C'est ce que nous allons faire ici.
Retournons dans notre fichier named.conf afin d'ajouter cette zone inverse. Nous allons déclarer la zone inverse de notre adressage IP, ici c'est 192.168.0.0/24.
Alors qu'une zone "normale" se déclare de façon plutôt logique, une zone inverse doit respecter une certaine forme concernant le nom de la zone :
zone "0.168.192.in-addr.arpa." {
type master;
file "/etc/bind/db.192.168.0";
};
·
une zone inverse
ne contient que des enregistrements de type NS ou PTR ;
·
dans notre zone
"normale", blog redirigeait vers www, mais là une adresse IP ne peut
pointer que vers un seul hôte ;
·
la variable
ORIGIN a changé ! Il faut donc penser à utiliser le FQDN de nos hôtes à chaque fois.
Vérification
On va quand même vérifier le fonctionnement
de notre zone maintenant.Commencez déjà par redémarrer votre serveur de nom pour prendre en compte les changements de configuration :
#/etc/init.d/bind9 restartIl existe plusieurs commandes pour faire des interrogations DNS. La commande la plus utilisée est
host mais
dig fournit plus d'informations et permet un diagnostic
plus précis en cas de problème. Vérifiez d'abord le serveur DNS utilisé par
votre machine. Comme cette machine est elle-même un serveur DNS, elle va devoir
s'interroger elle-même.Le programme qui fait toutes les résolutions DNS pour votre machine s'appelle le resolver. Ainsi, chaque programme qui a besoin de faire une résolution DNS s'adresse au resolver.
Son fichier de configuration se trouve dans /etc/resolv.conf qui doit au moins contenir l'adresse d'un serveur DNS à interroger :
nameserver 127.0.0.1
On peut maintenant commencer nos tests :
Nous allons donc utiliser la commande host qui permet de faire une interrogation DNS.
Sa syntaxe est la suivante:
# host -t type nom_a_chercher IPserveurPar exemple, si l'on cherche l'adresse des serveurs DNS du domaine reseau.fr :
# host -t a ns1.reseau.fr
ns1.reseau.fr has address 192.168.0.1
# host -t a ns2.reseau.fr
ns2.reseau.fr has address 192.168.0.2
Nous venons de voir que grâce à la commande host (ou dig), il est possible de demander toute information contenue dans vos zones DNS, ou même sur des serveurs situés sur Internet !