💾 Archived View for lord.re › posts › 143-slave-server-dns › index.gmi captured on 2024-03-21 at 15:42:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-03)
-=-=-=-=-=-=-
-------------------------------------------------
[01/12/2018] - ~5mins - #dns #knot #adminsys #autohebergement
-------------------------------------------------
Si vous avez un nom de domaine à vous (et j'espère que si vous êtes sensibilisé à votre identité numérique vous en avez un) il y a deux possibilités :
- soit vous laissez la tâche d'héberger votre zone à un prestataire (souvent celui qui vous a vendu le nom de domaine)
- soit vous l'hébergez vous-même.
Bon, personnellement je pense qu'il vaut mieux que vous l'hébergiez vous-même.
Soit dit en passant, je vous ai déjà concocté un
ref "/posts/63-dns-mega-guide" >}} joli guide concernant DNS
plutôt complet.
J'ai rien contre le fait de laisser un prestataire le faire.
Je n'ai, à vraie dire, jamais vraiment entendu d'histoire de magouille/mauvaise gestion/d'usurpation ou autre saloperie à ce propos.
C'est vraiment le B.A.BA de l'auto-hébergement.
Et qui dit auto-hébergement, dit ?
…
Panne.
Merci de suivre !
Bref, un jour où l'autre votre serveur se viandera et vous serez marron.
Par chance, comme la plupart des anciens protocoles de l'Internet, DNS a été pensé pour être vraiment résilient.
Il est très facile d'avoir plusieurs serveurs à même de répondre pour votre zone.
C'est une architecture Maître-Esclave où vous allez avoir votre serveur Maître qui connaît les informations concernant votre nom de domaine et qui les enverra aux serveurs esclaves qui recopieront ces informations et les communiqueront aux clients.
D'un point de vue de l'utilisateur, il ne verra pas de différence selon si l'info parvient d'un serveur esclave ou du maître.
Il arrive d'ailleurs parfois que le Master ne soit pas joignable depuis Internet mais uniquement par un réseau privé et que donc seul les serveurs esclaves soit utilisés par les clients.
Vous pouvez avoir autant de serveur esclave que vous le voulez.
Si jamais le maître tombe les serveurs esclaves seront toujours à même de fonctionner et vice versa.
Dans la suite je vais plutôt utiliser le terme zone DNS à la place de domaine.
Allez on met ça en place !
On commence par modifier le serveur maître.
Un remote est tout simplement un serveur distant avec lequel on interagira.
Rien de bien méchant :
{{< highlight "yaml" >}}
- id: slave_server
address: 123.321.123.321
{{< / highlight >}}
C'est tout.
Les ACL sont les régles définissants les droits que vous allez attribuer à une zone.
En gros vous voulez autoriser votre zone à envoyer les modifs vers le serveur esclave.
{{< highlight "yaml" >}}
- id: acl_slave
address: 123.321.123.321
action: ["transfer","notify"]
{{< / highlight >}}
Bon jusqu'à présent vous avez ajouté des options globales à votre configuration Knot.
Maintenant il faut affecter des options sur votre zone.
Soit vous mettez toutes les options dans un template que vous affecterez à vos zones, soit vous mettez les options à chacune de vos zones (le template permet d'appliquer les mêmes réglages à plusieurs zones d'un coup).
{{< highlight "yaml" >}}
template:
- id default
acl: [ "acl_localupdate", "acl_slave"]
notify: slave_server
…
{{< / highlight >}}
Là c'est un extrait du template par défaut où on affecte l'ACL que l'on a créé précédemment.
Et ensuite on indique qu'il faut notifier le remote créé précédemment.
Le notify permet à votre master d'indiquer au slave qu'il doit rafraîchir ses infos car le master vient de modifier la zone.
Ouai c'est tout mais faut penser à reload avec un ptit *<kbd>knotc reload</kbd>*.
Et maintenant on configure votre serveur esclave.
Ça ressemble beaucoup à la même chose que tout à l'heure vous allez me dire !
Bha ouai.
{{< highlight "yaml" >}}
- id: master_server
address: 123.321.123.321
{{< / highlight >}}
Ce coup-ci le remote est obligatoire et n'est pas là juste pour que ce soit clair.
{{< highlight "yaml" >}}
- acl: acl_master
address: 123.321.123.321
action: notify
{{< / highlight >}}
{{< highlight "yaml" >}}
- domain: mon.domaine
master: master_server
acl: acl_master
{{< / highlight >}}
Voilà c'est fait votre zone est maintenant répliquée sur un autre serveur qui peut prendre la main si votre serveur tombe en panne.
Vous pouvez le tester avec l'outil *Dig pour voir si le serveur esclave répond : <kbd>dig votre.domaine @serveur.esclave</kbd>*
Bon si vous voulez que ça fonctionne il reste deux étapes capitales :
1. Rajouter un enregistrement *NS dans votre zone pointant vers votre serveur esclave*.
2. Informer également votre registrar pour que ça soit pris en compte.
Haa non pas d'objection !
Ha bha il suffit de demander à vos amis geeks.
Héberger une zone pour un pote ça coûte absolument rien.
Et si vous avez pas d'amis bha… demandez-moi !
Ça marche même si les serveurs maîtres et esclaves n'utilisent pas les mêmes logiciels vu que c'est un fonctionnement de base du protocole.
Vous pouvez avoir du Bind et du Knot et du NSD par exemple.
C'est d'ailleurs pas mal d'avoir des implémentations différentes (en cas de bugs, tous les serveurs ne seront pas impactés).
Vous trouverez des tutos pour faire de même avec Bind dans le pire des cas ;-)
Rhaaa mais si c'est possible !
Juste que j'ai pas envie de vous faire un article fleuve mais
.
Ouai.
Et pour l'instant j'ai pas la solution car non il ne faut pas filer sa KSK au slave (on ne peut pas avoir autant confiance envers le slave).
------------------------------------
------------------------------------
[01/12/2018] [dns knot adminsys autohebergement]
------------------------------------