Sommaire
Installation et configuration
Dépot du nom de domaine
De la redondance
De l'automatisation
De la sécurité
Des commentaires ?
Liens :
Knot DNS ;
Netlib.re ;
Cours DNS & Mail
par Benjamin Bayart ;
DNS 1/2 : Le laisser-passer A38 d'internet
DNS 2/2 : Un .kevindu32 ?
Par la chaîne Youtube MonsieurBidouille.
Obtenir et gérer un nom de domaine (gratuit)
avec Knot et EU.org.
Nœuds et liens, l'indispensable pour la navigation.
Crédit photo : Lila.
Nom de domaine, DNS, zone, de quoi parle-t-on ?
Afin d'assurer des services sur Internet il est le plus souvent nécessaire de posséder un nom de domaine.En effet, si les machines communiquent entre elles en s'identifiant par leurs adresses IP, nous, humain⋅e⋅s, retenons plus facilement un nom qu'une suite de chiffres.
En outre, un nom de domaine servant comme identifiant que l'on peut traduire vers une adresse IP autorise plus de souplesse.
Lors d'un changement d'IP de la machine hébergeant un service, le nom de domaine peut rester inchangé, ainsi le changement est transparent aux yeux des usager⋅e⋅s du service.
Il faut mettre en place un mécanisme pour effectuer la correspondance entre un nom et une adresse IP (ou d'autres types de valeurs). L'opération se nomme « résolution d'un nom de domaine ».
Une correspondance entre une entrée et une valeur, c'est le rôle d'une base de données ; Dans notre cas cette base de donnée est mondiale, répartie et acentrée. La charge de la renseigner revient aux propriétaires de chacuns de noms de domaines, chacun⋅e⋅s est responsable de sa ou ses « zone(s) ».
Vous l'aurez compris, cette base de donnée mondiale se nomme le DNS et fonctionne grâce aux serveurs DNS, donc.
Les serveurs se contentent de répondre à des requètes, et la seule différence entre les deux types de serveurs se fait sur la façon dont ils connaissent la réponse :
1 − Les serveurs mis à disposition par votre FAI qui vont résoudre pour vous les requêtes sont couramment nommés des « resolvers ».
Si le serveur ne connait pas la réponse, alors il va aller la chercher auprès de ceux qui la connaissent, parfois en plusieurs étapes, c'est pourquoi on les nomme également des serveurs « récursifs ».
On les nommera, plus rarement, également des serveurs « caches », car ils ne connaissent pas les réponses, mais une fois acquises ces dernièrs sont conservées en mémoire un certain temps, « mises en cache ».
Si les serveurs mentent lors de leur réponse on les nommera des « DNS menteurs », c'est le cas désormais des resolvers des FAI grand public en France, principalement pour des raisons politiques.
2 − Si le serveur connait par avance la réponse sans devoir demander à personne d'autre, c'est parce qu'il est le serveur en charge de donner les réponses pour le nom de domaine en question.
On dit alors de lui qu'il fait « autorité » sur la zone DNS qu'il sert.
Vous l'avez compris, il faut donc mettre en place un serveur DNS, ou plusieurs, faisant autorité pour assurer la gestion de votre nom de domaine.
Rassurez-vous, Knot DNS ,qui nous arrive tout droit de République tchèque et que l'on va employer, est disponible sous Unix et un Raspberry Pi est amplement suffisant en terme de puissance pour le faire tourner.
Considération sur le fait de payer pour un nom
Il est convenu depuis quelques années qu'il faut payer pour obtenir un nom de domaine, pour un temps donné et limité dans le temps. Ainsi nous ne sommes jamais réellement propriétaires d'un nom de domaine. Plutôt locataires.Même si cette idée, payer pour obtenir un nom de domaine, est très largement répandue, elle n'en est pas moins inexacte.
Plus exactement il est très courant de payer en échange d'un nom de domaine à deux composants, comme qqchose.com, bidule.net, lutte-ouvriere.org ou bien potamochère.fr.
Mais un nom de domaine peut tout à fait contenir plus de deux composants, en effet edgard.fdn.fr est autant un nom de domaine que google.be.
Ainsi, l'association French Data Network fournit à ses adhérent⋅e⋅s un nom de domaine en .fdn.fr, deux de mes enfants bénéficient chacuns d'un tel domaine, sans n'avoir rien payé, juste en passant un coup de fil poli au camarade-président.
Lorsque j'étais abonné au fournisseur d'accès Nerim je disposais du nom de domaine emmanuel.bourguin.pck.nerim.net qui pointait vers mon IP publique, sans surcout.
Netlib.re qui est hébergé sur l'infrastructure du FAI associatif Alsace Réseau Neutre permet d'obtenir un domaine.
Attention, le service FreeNom (qui prétends, à tort donc, être le premier et seul fournisseur de noms de domaines gratuits) ne vous considèreras pas comme propriétaire des domaines pris chez eux mais simplement utilisateurs, comme précisé dans les CGU, avec l'absence de garanties que cela implique.
Eu.org fournit également, gratuitement, des noms de domaines.
Cette initiative a été prise en réaction à la politique de prix exorbitants mise en place à un moment de l'Histoire ou il devenait vital de posséder un nom de domaine sur Internet.
Si en 2016 les prix ont considérablement chuté pour atteindre la plupart du temps des sommes raisonnables, certains tarifs restent proprement honteux (au moment de la première rédaction de cet article : 40 €/an pour un .black ou un .lgbt, 3000 €, si si, pour un .auto…) et l'idée de payer pour pouvoir se nommer reste… curieuse.
Contrairement à un registrar classique (entendre par là, « commercial ») EU.org ne gèrera pas la zone DNS associée au nom de domaine fourni.
Le ou les serveur(s) que nous mettrons en place s'en chargeront.
Installation de Knot DNS
Dans une console, sous Debian en root :apt-get -y install knot
Configuration de Knot DNS.
Commençons par éditer le fichier de configuration principal de Knot :vim /etc/knot/knot.conf
- domain: exemple.eu.org
file: "exemple.eu.org.zone"
cd /var/lib/knot/
touch exemple.eu.org.zone
vim exemple.eu.org.zone
@ 10800 IN SOA exemple.eu.org. e.fdn.fr.
(
2018040301 ; Numero
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN 3600 NS ns.exemple.eu.org.
exemple.eu.org. IN 3600 A 93.184.216.34
exemple.eu.org. IN 3600 AAAA 2606:2800:220:1:248:1893:25c8:1946
Veillez bien entendu à adapter votre fichier de zone pour qu'il colle avec le nom de domaine que vous aurez choisi, notez bien les points finaux qui ont toute leur importance.
Sur la première ligne, après votre nom de domaine, vous devez renseigner votre adresse mail en remplaçant le @ par un point.
Par convention, le 1er point est considéré comme le @, il faut donc éviter les adresse type jean.kevin@example.eu.org ou alors mettre jean\.kevin
Les différentes valeurs numériques sont des temps exprimés en secondes, dont l'explication dépasserait le cadre de cet article.
Le plus importantes sont le numéro de série, « 2016121300 » dans l'exemple, qu'il faudra incrémenter à chaque modification de votre fichier de zone.
Une astuce classique consiste à composer le dit numéro avec la date du jour de modification, ainsi vous ne risquerez pas de le faire diminuer, ce qui aurait des conséquences facheuses.
L'autre valeur importante est le TTL, que l'on retrouve sur les deux dernières lignes. C'est une indication de la durée de validité de l'information renvoyée par votre serveur.
Elle est ici de 3600 secondes, soit une heure.
Cela signifie que les résolveurs DNS des fournisseurs d'accès considéreront que la réponse « 92.93.169.42 »
à la question « quelle est l'adresse IP associée au nom de domaine exemple.eu.org ? », est valable une heure, et la redemanderont ensuite.
Si un jour votre nom de domaine doit être associé à une autre adresse IP, pensez à baisser au préalable ce TTL afin que la coupure soit la plus courte possible.
Ré-augmentez la ensuite pour éviter de trop solliciter inutilement votre machine et sa connexion.
Redémarrage et vérification
Une fois la configuration achevée redémarrons Knot par la commande :service knot restart
service knot status
![[exemple.eu.org] loaded](images/DNS-knot-eu-org/08.jpg)
La syntaxe du fichier de configuration était donc correcte.
Ceci fait, pensez à ouvrir le port 53 en TCP et UDP et à le rediriger vers la machine sur laquelle tourne Knot dans les options NAT de votre routeur.
Inscription sur EU.org.
Tout d'abord, assurez-vous d'avoir attentivement lu la charte générale de EU.org ainsi que les les règles supplémentaires pour les sous-domaines directs.Vous pouvez vous rendre sur l'interface d'enregistrement à l'url https://nic.eu.org/arf/fr/contact/create/.
Il n'y a plus qu'à remplir le formulaire pour se créer un compte, et à cliquer sur le lien reçu par mail pour l'activer.
Création du nom de domaine
Désormais il ne reste plus qu'à se rendre sur https://nic.eu.org/arf/fr/domain/new/ afin de créer le nouveau domaine souhaité.
Renseignez dans le premier champ le nom complet du domaine, ici « exemple.eu.org ».
Les champs suivants concernant l'identification dans la base de données whois sont déjà pré-remplis.
Vous pouvez choisir de les conserver privées afin que votre identité ne soit pas publiée, ainsi seul EU.org en aura connaissance.
Dans le champ « Name1 » remplissez ns.votredomaine.eu.org, ici « ns.exemple.eu.org ».
Puis dans le champ « IP1» l'adresse IP de la machine faisant tourner Knot.
(C'est le moment de vous assurer que vous avez bien ouvert le port 53 sur votre routeur)
Une fois ceci fait, le système d'EU.org va procéder aux vérifications. Si tout est correct une demande de validation sera envoyée aux personnes administrant EU.org.
À ce stade le nom de domaine n'est pas encore créé. On peut le constater via la commande
host exemple.eu.org
qui retourne l'erreur « NXDOMAIN » (Non-eXistent Domain)
Après l'acceptation de la requête par EU.org vous recevrez un mail vous en notifiant.
Et cette fois, après un délai compris entre quelques minutes et quelques heures, le nom de domaine est existant :
Épilogue (provisoire)
Voilà, vous disposez désormais de votre nom de domaine grâce à Knot et EU.org. Retenez bien que si le service est gratuit, il a néanmoins un coût.
Ainsi, même si rien ne vous y oblige, considérez l'option de faire un petit don à EU.org si vous en avez les moyens.
Ce tuto a été réalisé dans une optique « auto-hébergement ». Les bonnes pratiques veulent que l'on dispose d'au moins deux serveurs DNS faisant autorité,
si possible éloignés géographiquement et hébergés sur deux AS différents afin de minimiser les risques d'interruptions du service si une des machines était mise hors service.
Dans le cadre de l'auto-hébergement où votre site ou serveur de mail perso est chez vous derrière une ligne *DSL ou une fibre optique cette précaution devient superflue.
Si votre connexion est coupée, il ne sert à rien qu'un autre serveur continue de résoudre le nom de domaine, votre site sera de toutes façons inaccessible.
Ce tutoriel est donc à prendre pour ce qu'il est, un exemple quick & dirty
pour un⋅e particulier⋅e qui s'auto-héberge et souhaite disposer d'un nom de domaine à moindre frais, et non comme un papier de référence dans le domaine du DNS.
Ajouter de la redondance.
Finalement on veut de la redondance ?
Un peu plus haut j'ai écrit que dans une optique « auto-hébergement », ne pas suivre les bonnes pratiques ne serait pas très grave.
Et c'est en effet vrai dans la majorité des cas, si on est auto-hébergé, on ne dispose que d'une seul exemplaire de son site ou de son serveur mail, sur une seule machine,
derrière une seule connexion. De l'ADSL bien souvent, VDSL ou fibre optique pour les chanceu⋅se⋅s ;
On utilisera parfois du câble coaxial pour les exotisme curieux ou encore 4G pour les péquenots ruraux dans mon genre.
Le point commun entre toutes ces connexions c'est qu'elles sont grand public, sans garantie de fonctionnement, pas redondées, bref, si ça coupe, y'a pas de roue de secours.
Alors pourquoi vouloir faire de la redondance ?
Hé bien parce que l'auto-hébergement n'implique pas nécessairement de rester seul⋅e dans son coin avec sa machine et bien des services peuvent être distribués.
Deux enregistrements A, une copie de votre site web chez un⋅e pote, c'est déjà de la redondance, dans sa forme la plus élémentaire, mais c'est de la redondance.
Si vous faites du mail, un MX secondaire, c'est de la redondance. Mon fournisseur d'accès à Internet, FDN propose d'être MX secondaire de ses abonné⋅e⋅s, par exemple, et ce n'est pas le seul.
Et dans ce genre de configuration, maintenir la résolution de votre nom de domaine revêt de l'importance, même si votre machine est hors-ligne à un moment donné.
Quelques pré-requis
Le DNS étant bien pensé dès le départ, la différence de configuration requise pour une zone qui n'aura pas de redondance et une zone qui en aura n'est pas énorme.
Pour commencer il faudra, bien entendu, une deuxième machine qui sera hébergée derrière une deuxième IP.
- Notre machine initiale se nomme Mazikeen et possède l'IP 92.93.169.42 (c'est du VDSL SFR)
- Notre seconde machine se nomme Cassandre et possède l'IP 80.67.179.144 (c'est du VPN FDN, cette fois).
- On accède à ces deux serveurs via un poste de travail classique nommé « Sélène ».
L'idée sera de définir deux serveurs de nom pour la zone exemple.eu.org, et pas juste un seul, de configurer ce second serveur de nom, et enfin d'assurer la communication entre ces deux serveurs de noms.
la commande DIG
Jusqu'à présent nous utilisions la commande host pour savoir ce que le grand système magique du DNS répond quand on lui pose une question.Pour la suite nous utiliserons la commande DIG, plus complète.
dig A +short exemple.eu.org
Est environ équivalente à host, elle renvoie bien la ou les adresses (champ « A ») IP de la zone concernée :
Option intéressante de DIG, l'argument « @ » permet de forcer l'interrogation d'un serveur DNS en particulier, cela nous sera utile bientôt.
Le champ A d'une zone DNS n'est pas la seule qui nous intéresse, il sera utile de savoir par quels machines est servie une zone. En d'autres termes, savoir quels sont les serveurs qui répondront aux requêtes DNS.
Voyons voir ce qui se passe sur 3 noms de domaines différents : orange.fr, fdn.fr et exemple.eu.org :
Que remarque-t-on ?
La zone orange.fr est servie par deux serveurs de noms, celle de fdn.fr l'est par trois. Et pour le moment la notre, exemple.eu.org, n'est servie que par un seul serveur.
On remarque également que les serveurs ne sont pas nommés forcément « ns.nomdudomaine.tld » ;
en effet, il ne s'agit absolument d'une obligation, plutôt d'une convention appliquée et recopiée doctement par certain⋅e⋅s admins, point.
Mettre en place le second serveur de nom.
Notre premier serveur de nom fonctionnait fort bien, nous allons appliquer la même configuration à notre second serveur de nom :(l'air de déjà vu est donc tout à fait normal) Éditons le fichier de configuration principal de Knot :
vim /etc/knot/knot.conf
Le nom de domaine sera toujours « exemple.eu.org » et le fichier de zone correspondant se nommera de nouveau « exemple.eu.org.zone ».
- domain: exemple.eu.org
file: "exemple.eu.org.zone"
cd /var/lib/knot/
touch exemple.eu.org.zone
vim exemple.eu.org.zone
@ 10800 IN SOA exemple.eu.org. e.fdn.fr.
(
2018040301 ; Numero
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN 3600 NS ns.exemple.eu.org.
IN 3600 NS ns2.exemple.eu.org.
exemple.eu.org. IN 3600 A 93.184.216.34
exemple.eu.org. IN 3600 AAAA 2606:2800:220:1:248:1893:25c8:1946
Le point important étant que désormais il y désormais un « ns2.exemple.eu.org. ».
On redémarre knot sur notre serveur secondaire avec la commande service knot restart
On vérifie que tout est OK avec service knot status.
notre serveur secondaire réponds, et il réponds la bonne réponse.
Notre primaire réponds toujours la meme bonne réponse, c'est encourageant.
Déclarer notre serveur de nom secondaire.
Nos serveurs de noms donnent la bonne réponse, si l'un des deux lache, on interroge l'autre et on a toujours notre réponse à la question « qui est exemple.eu.org ? ».Mais le but recherché c'est que ce soit tous les résolveurs d'Internet qui nous donnent la bonne réponse, au besoin en demandant à nos serveurs faisant autorité sur la zone. Comment faire ? Comme lorsque l'on a enregistré notre nom de domaine avec une seule machine pour servir la zone, en les déclarant à eu.org. Retour sur l'interface d'administration donc : https://nic.eu.org/arf/fr/
On choisit notre domaine, puis on va modifier les serveurs de noms
Et on y ajoute les informations concernant notre serveur secondaire, soit « ns2.exemple.eu.org » pour le nom et « 80.67.179.144 » concernant l'IP. Au passage, prennons conscience que si l'envie nous prend d'avoir du serveur tertiaire, quaternaire et ainsi de suite, il est tout fait possible de les mettre en œuvre.
On valide, tout se passe bien.
Vérifier que tout se passe bien.
Et désormais nos deux serveurs sont renseignés.
Les résolvers par défaut de notre FAI sont bels et bien au courant que désormais il faut poser la question à l'un de ces deux serveurs ci, considérés comme serveurs de noms pour notre zone.
Quadnine et Google Public DNS sont au courant également.
Désormais si l'un des deux tombe en panne, il en restera un pour servir notre zone.
En l'état ca ne sera pas très utile, étant donné que le nom de domaine n'est associé qu'à une seule adresse IP,
mais la redondance du service assuré pour la machine (du web ou du mail, par exemple) n'est pas à la charge du DNS, et dépasserait le cadre de cet article.
De l'automatisation.
Bien, nous avons donc notre nom de domaine, et il pointe vers une adresse IP, tout cela fonctionne parfaitement.Mieux encore, avec la redondance mise en place si une machine tombe, la seconde continuera à servir la zone, le temps que la première redevienne fonctionnelle, notre système est désormais à tolérance de pannes.
Mais un problème se pose : si l'on souhaite modifier sa zone DNs, ajouter un second champ A par exemple, ou le modifier afin que le nom de domaine pointe vers une autre IP, il va falloir le faire à deux endroits, voire davantage en fonction du nombre de machines qui servent la zone.
Pire encore, c'est multiplier d'autant le risque de faire une boulette au moment d'éditer la zone sur chaque serveur.
La solution serait d'avoir un seul fichier de configuration à modifier sur le serveur principal. Et se débrouiller pour que la dite configuration soit recopiée d'une façon ou d'une autre, mais automatiquement, sur le serveur secondaire.
Ça tombe bien, Knot prévoit tout cela.
Voici la configuration telle que nous l'avions laissée.
Ce que nous modifions sur le principal.
On ajoute la section « remote » pour indiquer qu'un correspondant distant va exister, son « id » sera cassandre et on indique son IP et son port, donc « 80.67.179.144@53 ».
La section « acl » est parlante d'elle même (on donne un nom à la règle ACL, on rappelle vers quelle IP des choses ont droit de se passer, et quelles seront les choses en question, en l'occurence un « transfer ».
Enfin dans la section « zone » on indique qu'il faudra « notify » Cassandre et on rappelle la règle ACL associée.
Ce que nous modifions sur le secondaire.
Dans la section ACL nous indiquerons cette fois que le serveur accepte non pas cette fois un transfer, mais une « notify ».
Dans la section zone nous indiquerons (terminologie vestige) que le maître est Mazikeen (une maîtresse, donc).
ajoutons un champs txt
Puis redémarrons.
On constate un message au sujet d'un transfert, notre principal a donc transféré la zone vers le secondaire avec succès.
Si l'on fait un dig vers notre primaire, on constate bien l'apparition d'un champs TXT, donc la modification de notre zone a bien fonctionné.
On aurait tout aussi bien modifier l'adresse IP vers laquelle le nom de domaine pointe, mais autant ne pas tout casser « juste pour voir ».
dig TXT +short exemple.eu.org @92.93.169.42
Interrogeons notre serveur secondaire
dig TXT +short exemple.eu.org @80.67.179.144
Le secondaire réagit comme prévu.
Et fort logiquement le reste de la terre (en tout cas le resolver de mon FAI, Google, QuadNine et le résolveur ouvert de FDN, interrogé en IPv6) réponds également pareil, donc on est plutôt pas mal.
Pour la curiosité, allons voir à quoi ressemble notre fichier de zone sur le secondaire désormais que ce n'est plus nous qui l'éditons mais Knot qui le génère lors des notify.
Rien d'énormément différent à ceux que nous écrivions à la main, au formatage et à quelques commentaires générés près, ce qui n'est pas très surprenant.
Sécuriser la communication entre nos serveurs DNS.
générer une clé avec keymgr keymgr pour ça, il utilise l'algo hmac-sha256 par défaut.keymgr tsig generate ma_petite_cle
key:
- id: ma_petite_cle
algorithm: hmac-sha256
secret: 2nQ8MrsZ08jz6YSinbzfMV9tj3UiNEi7kXA4QHd5ZzA=
notre clé est générée, il va falloir maintenant l'inclure dans les fichiers de configuration.
Du primaire, pour commencer.
en redémarrant, on obtient un message d'erreur « BADKEY », c'est tout à fait normal.
Il a tenté de communiquer avec le serveur secondaire, ce dernier n'étant pas encore configuré pour communiquer avec une clé de chiffrement, il a répondu à coté de la plaque.
Du secondaire, ensuite.
Testons désormais que le transfert de zone se fasse toujours correctement.
Il suffira de modifier la zone, pour y mettre, par exemple "test_redondance_avec_la_clé" et de voir ce que ça donne.
Notre principal et notre secondaire répondent ce qui est attendu, le serveur récursif de FDN (celui interrogé en IPv6) également.
Les gros malins de Cloudflare (1.1.1.1), Google (8.8.8.8) et QuadNine (9.9.9.9) répondent à coté de la plaque.
Pourquoi ? tout simplement car ils ont encore en cache l'ancienne réponse, réputée encore valable dans leur tête.
Quelques heures plus tard les caches ont expiré, nos serveurs ont donc été ré-interrogés, et cette fois c'est la bonne réponse qui est donnée.
Ajouter de la sécurité avec DNSSEC
C'est sur ma to-do list. En attendant quelques éléments sur Knot et DNSSEC sur la page d'Alarig Le Lay.
Commentaires ?
Mon site n'a pas de fonction permettant de commenter les articles, et il n'est pas prévu que cela arrive.Je vous propose donc si vous souhaitez interagir soit de m'envoyer un mail ou de répondre à ce message sur mon compte Twitter ou ce toot sur Mastodon.