[TUTO] [Zone publique sur DNS Server] Renouvellement automatisé de certificat wildcard

[.Shad.]

Pré-requis

Ce tutoriel s'adresse à ceux qui ont déjà parcouru le tutoriel de @Fenrir sur la mise en place d'un serveur DNS, et qui sont allés jusqu'à héberger la zone publique de leur domaine.
On part donc dans l'hypothèse que :

• vous hébergez votre zone DNS, qu'elle est SOA (Start of Authority). Le NAS hébergeant la zone est un serveur de nom (nameserver ou NS) pour cette zone et ce nom de domaine.
• vous avez éventuellement (c'est fortement recommandé mais non obligatoire) d'autres serveurs de noms, auto-hébergés (autre(s) NAS), votre registrar (OVH, etc...) ou des hébergeurs DNS (Cloudflare, GoDaddy, etc...).
• vous êtes relativement à l'aise avec le vocabulaire relatif au DNS.
• vous avez installé acme.sh sur votre NAS.

Préambule

L'origine de ce tutoriel vient de la volonté de @Jeff777 de trouver un moyen de mettre en place un renouvellement automatique de son certificat pour son domaine. Merci à lui pour le nombre incalculable de tests qu'il a effectués et pour les feedback complets qu'il m'a procurés.
Dans la foulée, on s'est dit que ça pourrait intéresser d'autres personnes, d'où ce tutoriel. 😉 
Même si on a bien conscience que le nombre de personnes concernées est très marginal.

Actuellement, pour un nom de domaine Synology, DSM inclut la possibilité de renouveler automatiquement un certificat wildcard depuis l'interface dédiée dans l'onglet Sécurité.
Pour tout autre nom de domaine, on est tributaire de logiciels tiers comme par exemple acme.sh, un script gérant l'obtention et le renouvellement automatique des certificats.
Lorsqu'on héberge sa zone DNS chez un registrar ou un hébergeur DNS connu, on a des grandes chances qu'acme.sh dispose d'un plugin permettant de communiquer avec l'API de l'hébergeur en question. Sous réserve de bien configurer les paramètres du script, tout sera automatisé.

Ce n'est évidemment pas le cas lorsqu'on héberge soi-même sa zone.
Plusieurs solutions existent :

• https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode : J'héberge sur mon NAS la zone publique maître de mon domaine, mais je dispose d'un autre nom de domaine hébergé chez un prestataire mettant à disposition une API par laquelle acme.sh peut communiquer (par exemple OVH). Je redirige donc les enregistrements _acme.challenge nécessaires pour la validation de notre premier domaine vers le second. Je me sers donc du 2ème nom de domaine pour valider le premier. Facile et malin, à prioriser quand applicable.
   
• https://github.com/acmesh-official/acme.sh/wiki/DNS-API-Dev-Guide : développer sa propre API en créant son propre plugin de communication. Clairement pas à la portée de tout le monde, mais sûrement la meilleure méthode qui soit.
   
• Développer un script permettant d'extraire les enregistrements TXT _acme.challenge et les ajouter à sa zone pour la validation.

C'est cette dernière solution que nous nous sommes attachés à développer.

Hypothèses

Vous avez déjà installé acme.sh sur votre NAS via ligne de commande, vous pouvez trouver une procédure détaillée dans le tutoriel de @oracle7, à suivre jusqu'au point 2) inclus.
J'attire l'attention sur les arguments utilisés lors de l'installation d'acme.sh

• --home : il permet de définir où est installé le script acme.sh et les fichiers qui l'accompagnent.
• --cert-home : c'est le dossier dans lequel les certificats sont sauvegardés lorsqu'ils sont générés.

Paramétrage du script

Maintenant qu'acme.sh est installé, vous pouvez téléchargez le script et le placer où vous le souhaitez dans votre NAS : dsm_public-dns-zone_renewal_automation_15-02-22.sh
Il va falloir maintenant le configurer, je l'édite ici directement dans File Station avec le paquet Éditeur de texte dans le centre de paquets Synology.
Vous pouvez évidemment l'éditer en SSH avec votre éditeur de texte préféré.

Il va falloir attribuer une valeur à certaines variables pour que le script s'exécute sans encombre.
Ces variables se trouvent dans la fonction init(), dans la sous-partie titrée VARIABLES TO SET.

Par commodité, je reprends certains noms de variables utilisés dans le tutoriel de @oracle7.

• CERT_DOMAIN : c'est le nom de domaine racine ("root") pour lequel vous souhaitez obtenir un certificat
• CERT_WDOMAIN : le domaine wildcard
• ZONE_NAME : le nom de la zone telle qu'elle apparaît dans cet écran :
  
  
  ou via SSH dans le dossier /var/packages/DNSServer/target/named/etc/zone/master/ :
  
  
   
• RENEWAL_CYCLE : c'est le cycle de renouvellement du certificat tel que : 60 ≤ RENEWAL_CYCLE < 90 (en jours).
  acme.sh ne renouvellera pas "naturellement" un script dont l'âge est inférieur à 60 jours, l'expiration intervenant au 90ème jour.
  On peut pour autant, si on le souhaite, forcer le renouvellement en ajoutant le paramètre --force à l'issue et au renew du certificat :

  acme.sh --force --issue [...]
  acme.sh --force --renew [...]

• ACME_DIR : c'est le dossier dans lequel vous avez installé acme.sh en amont de ce tutoriel via --home.
• CERT_HOME : c'est le dossier que vous avez défini comme répertoire de sauvegarde des certificats via --cert-home lors de l'installation d'acme.
  REMARQUE :
  • Pour les besoins du script, il est nécessaire de renseigner cette dernière variable, même si c'est le même dossier que celui défini via --home.
  • Ne pas ajouter de / à la fin des chemins renseignés dans ACME_DIR et CERT_HOME.

Si l'on souhaite déployer automatiquement le certificat sur le NAS, on va devoir également paramétrer la fonction certificate_deployment_1 un peu plus bas dans le script :

Il faut compléter les différentes variables SYNO_, par exemple :

SYNO_Scheme='http'
SYNO_Hostname='ns.ndd.tld'
SYNO_Port='5000'
SYNO_Username='admin'
SYNO_Password='password'
SYNO_Certificate="un_nom_de_certificat"
SYNO_DID=""

Notes :

• ns.ndd.tld étant l'objet d'un enregistrement A ou CNAME pointant vers l'IP de mon NAS, qu'elle soit locale ou publique (dans ce dernier cas, ce sera l'IP de la box internet, par exemple dans le cas d'un NAS hors-site).
• 5000 étant le port HTTP par défaut de DSM (on a choisi HTTP comme protocole en première ligne), à adapter au besoin (en cas de NAS distant, le port DSM (ou 443 si proxy inverse) doit être redirigé vers le NAS).
• Si vous disposez déjà d'un certificat wildcard pour ce domaine, alors il faut que la variable SYNO_Certificate soit identique au nom du certificat existant (voir cadre rouge ci-dessous). Cela permettra que tous les services qui y sont actuellement associés soient redémarrés lors du déploiement du certificat dans DSM.
  
  
  
   
• Si on veut déployer le certificat sur un autre NAS, on s'aperçoit que le script contient une fonction certificate_deployment_2.
  Il suffit alors de décommenter cette fonction (enlever tous les # devant chaque ligne, de certificate_deployment 2() { à }) et de décommenter les 2 lignes reprises dans le script :
  
  
  
  On peut ainsi ajouter autant de NAS que l'on souhaite, il suffit de définir autant de nouvelles fonctions certificate_deployment que nécessaire, et d'ajouter juste avant la ligne echo -e "\n### STEP 6 ###" pour chaque NAS un couple de lignes certificate_deployment_N et saved_syno_values_removing.
   
• Typiquement, dans le cadre d'un NAS distant, vous utilisez peut-être un proxy inverse pour limiter le nombre de ports exposés, vous pouvez passer par celui-ci pour déployer le certificat, en modifiant les variables suivantes, par exemple :

  SYNO_Scheme='https'
  SYNO_Hostname='dsm.ndd.tld'
  SYNO_Port='443'

  dsm.ndd.tld étant le nom de domaine pointant vers l'interface DSM sur le NAS.
   
• SYNO_DID est à compléter si on utilise la double authentification pour se connecter à DSM, voir le point 5.1) du tutoriel de @oracle7
   
• Il n'y a aucune obligation de procéder au déploiement du certificat, vous pourriez très bien vouloir l'utiliser sur un autre périphérique.
  Il suffit dans ce cas-là de commenter les lignes certificate_deployment_1 et saved_syno_values_removing qui suit immédiatement (voir impression d'écran ci-avant).
  Les certificats pourront être récupérés dans le dossier défini dans ${CERT_HOME}/ndd.tld

Remarques

• Dans le cas où vous n'avez pas déjà de certificat pour ce nom de domaine importé sur le NAS, il y aura une étape supplémentaire à réaliser manuellement après la première exécution du script.
  En effet, les services et applications de votre NAS sont par défaut associés au certificat Synology.com créé à l'installation de DSM, ou à tout autre certificat créé par après.
  Lorsque le script va s'exécuter et que vous le déployez sur votre NAS, vous verrez apparaître le nouveau certificat dans l'onglet qui les liste.
  Il sera configuré par défaut, mais les services seront toujours configurés pour le certificat antérieur, exemple (nom de domaine Synology antérieur au nom de domaine OVH) :
  
  
  
  Il faut donc cliquer sur Configurer, et attribuer les services souhaités au nouveau certificat.
  Lors du prochain renouvellement, les services associés seront redémarrés et exploiteront le nouveau certificat.
  C'est donc une opération à ne réaliser qu'une seule fois, dans l'hypothèse où vous n'avez pas encore de certificat pour ce nom de domaine.
  @bruno78 a développé un script en python3 permettant de transférer les services d'un certificat à l'autre, au besoin consulter le tutoriel de @oracle7 dont le lien a été donné plus avant.
  Dans le cas où un certificat pour le nom de domaine existerait déjà sur votre NAS, le script redémarrera naturellement les services qui y sont déjà associés, il faut toutefois veiller à avoir le même nom de certificat (déjà expliqué en amont).
   
• Lors de l'exécution du script, le fichier de zone original est dupliqué dans le dossier ${CERT_HOME}/ndd.tld/backup_... et un log d'acme.sh est disponible dans ${CERT_HOME}/ndd.tld
  En cas d'interruption inopinée du script, le fichier de zone original reste accessible.
  Si le script s'exécute jusqu'au bout, le duplicata de la zone originale et le log sont effacés.
   
• En outre, si le script ne s'exécute pas entièrement, vous devrez peut-être amené à supprimer

Planification du renouvellement

Le script intègre une fonction de vérification de validité du certificat, tant que le certificat n'est pas âgé de plus de RENEWAL_CYCLE jours, le renouvellement sera bloqué en amont.
Dès lors, vous pouvez très bien créer une tâche régulière qui vérifiera fréquemment, par exemple toutes les semaines ou tous les quelques jours, si le certificat a besoin d'être renouvelé.
On va donc dans Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche planifiée -> Script défini par l'utilisateur :

On définit donc une tâche exécutant le script où qu'il se trouve, ici pour l'exemple dans /volume1/scripts/ et on génère un log complet du script dans le fichier /volume1/Certs/log_acme_$(date +"%d-%m-%y").log, ce qui donnera au moment où j'écris log_acme_30-09-20.log
On peut demander au planificateur de tâches d'envoyer par mail le résultat du script, pour peu qu'on ait configuré le service de notification de DSM.

MàJ : 15/02/22

Modifié le 15 février 2022 par .Shad.
Corrections DSM 7 et CA

[Jeff777]

[oracle7]

@.Shad.

Bonjour,

Comme à ton habitude, encore un excellent TUTO. Bravo ! 😀

Juste quelques remarques et suggestions :

• Dans le script, sauf erreur de ma part, j'aurais codé aux lignes 257 et suivantes :

echo -e "### STEP 5 ###\n"
certificate_deployment_1
#certificate_deployment_2
#certificate_deployment_3
...
#certificate_deployment_N
saved_syno_values_removing

pour ne pas répéter à chaque fois la ligne "saved_syno_values_removing" à moins qu'elle soit obligatoire après chaque déploiement, dans ce cas oublies la remarque.

Le 01/10/2020 à 00:09, .Shad. a dit :

On va devoir compléter les différentes variables SYNO_, par exemple :

SYNO_Scheme='http'
SYNO_Hostname='ns.ndd.tld'
SYNO_Port='5000'
SYNO_Username='admin'
SYNO_Password='password'
SYNO_Certificate='certificat_ndd.tld'

• A ce niveau, il te manque la variable "SYNO_DID" qui doit être renseignée avec la valeur du cookies DID lorsque l'utilisateur à mis en place la double authentification sinon cela bloquera le renouvellement du certificat.
  Si pas de double authentification en place alors SYNO_DID est "vide" (ou absente mais il vaut mieux qu'elle soit présente et "vide").
   
• Maintenant pour éviter que l'utilisateur n'ai à venir modifier directement le script et donc par inadvertance faire des bêtises, je crois qu'il serait plus judicieux de passer en paramètres au script certaines variables d'environnement sachant que quelque unes peuvent être relues (puisque sauvegardées par acme.sh) directement depuis les fichiers "/usr/local/share/acme.sh/account.conf" et "/volume1/Certs/ndd.tld/ndd.tld.conf".
   
• Dernier détail : dans le script pour la fonction "zone_backup()" tu utilises des commandes "cp", il serait judicieux de leur rajouter le paramètre "-p" afin de conserver les attributs d'origine du fichier copié (propriétaire et droits).

Cordialement

oracle7😉

 

 

[.Shad.]

Salut @oracle7

Merci de ton retour, alors pour la première remarque tu as vu juste, elle est obligatoire après chaque déploiement pour supprimer notamment le "cache" des variables SYNO_XXXX qui peut mener à des erreurs, surtout si on déploie sur plusieurs NAS.
Ok pour le DID, je l'ai ajouté et je vais préciser ceci dans le tutoriel en pointant vers le tien.

Pour les variables à récupérer, ok pour récupérer le CERT_DIR (renommé CERT_HOME pour une question de cohérence avec la variable dans le fichier account.conf).
Pour le fichier .conf du certificat, je n'ai rien à y récupérer (acme.sh oui mais ça c'est son problème), je dois même justement enlever des variables (Le_DeployHook et les SAVED_SYNO en l'occurrence).

Pour la commande cp -p, bonne remarque merci c'est ajouté. 🙂 

PS : Idéalement j'aurais souhaité utiliser la commande getopts pour passer les variables de personnalisation dans la commande du script, j'en ai compris les grands traits mais pas réussi à la mettre en application pour le moment, si tu as un point de vue je suis tout ouïe. 😉 

Modifié le 2 octobre 2020 par .Shad.

[oracle7]

@.Shad.

Bonjour,

il y a 33 minutes, .Shad. a dit :

Pour le fichier .conf du certificat, je n'ai rien à y récupérer (acme.sh oui mais ça c'est son problème), je dois même justement enlever des variables (Le_DeployHook et les SAVED_SYNO en l'occurrence).

Là tu m'étonnes fortement car j'ai du mal à comprendre pourquoi tu dois te passer de ces variables, vu que acme.sh en a besoin pour faire le déploiement et que tu l'utilises en ligne 175. Il est quand même plus sûr à mon sens de les récupérer selon le certificat dans le fichier ndd.tld.conf que de les coder en dur dans ton script aux lignes 168 à 174.

il y a 40 minutes, .Shad. a dit :

PS : Idéalement j'aurais souhaité utiliser la commande getopts pour passer les variables de personnalisation dans la commande du script, j'en ai compris les grands traits mais pas réussi à la mettre en application pour le moment, si tu as un point de vue je suis tout ouïe.

Peut-être que cela pour t'aider. C'est assez clair il me semble même si cette commande getops est à la fois compliquée et puissante.

Sinon, pourquoi ne pas utiliser tout simplement la notation "$n" avec n=0 pour la commande et n=1 à X paramètres passés pour récupérer les valeurs de ces paramètres et ensuite gérer cela avec un "case" ou une boucle "for i in "$@"  "?

Cordialement

oracle7😉

 

[.Shad.]

Il y a 3 heures, oracle7 a dit :

Là tu m'étonnes fortement car j'ai du mal à comprendre pourquoi tu dois te passer de ces variables, vu que acme.sh en a besoin pour faire le déploiement et que tu l'utilises en ligne 175. Il est quand même plus sûr à mon sens de les récupérer selon le certificat dans le fichier ndd.tld.conf que de les coder en dur dans ton script aux lignes 168 à 174.

A partir du moment où tu as exécuté acme.sh une fois et déployé dans la foulée, le fichier ndd.tld.conf comprend d'une part les variables SAVED_SYNO et d'autre part l'option Le_DeployHook avec l'appel au plugin synology_dsm.sh qui déclenche le déploiement automatiquement après le renouvellement du certificat. Sans possibilité de l'empêcher.

Supposons que je souhaite déployer le script sur 2 instances de DSM, la première fois que je vais exécuter le script, il n'y aura pas de fichier ndd.tld.conf, donc il va faire un issue, puis un renew, puis un deploy_1 et un deploy_2.
60j après, lors du premier renouvellement de certificat, au moment du renew, il va directement déployer dans la foulée. Si j'ai laissé les variables SAVED_SYNO dans le fichier .conf, il va déployer sur le NAS2, puis viendra le déploiement sur NAS1, puis re-NAS2.

Avec le même script j'ai donc un comportement différent suivant qu'un certificat antérieurement ou pas.

En supprimant également la ligne Le_DeployHook, je m'assure qu'il reproduise à chaque exécution le même script : issue -> renew -> deploy_1 ->deploy_2
En supprimant les variables SAVED_SYNO, je suis sûr et certain de l'ordre dans lequel les certificats vont se déployer.
Si des variables SAVED_SYNO existent déjà dans le fichier ndd.tld.conf, acme.sh --deploy ne les écrasera pas, même si on en spécifie d'autres avant le déploiement.

Modifié le 2 octobre 2020 par .Shad.

[oracle7]

@.Shad.

Bonjour,

OK merci pour cette explication très détaillée. Je comprends mieux maintenant ta démarche et d'où l'inscription en dur des variables SYNO_x dans le script.

Cette explication qui ne manquera pas d'intéresser @bruno78 dans ses travaux actuels.

Cordialement

oracle7😉

 

[Jeff777]

Bonsoir,

Mes deux NAS ont renouvelé leur certificat aujourd'hui. Merci @.Shad.    

👍

[.Shad.]

👌

Je profite pour dire que j'ai corrigé une erreur signalée par @Jeff777 dans le script, vous pouvez soit re-télécharger le script soit modifier la ligne 207 :

sed 's/${SERIAL}/\t${INCR_SERIAL}/' ${ZONE} > ${ZONE_TEMP}

devient :

sed "s/${SERIAL}/\t${INCR_SERIAL}/" ${ZONE} > ${ZONE_TEMP}

(on remplace les quotes simples ' par des guillemets ")

[.Shad.]

Script mis à jour, notamment au niveau des entêtes et des commentaires, plus verbeux.

[Jeff777]

Salut @.Shad.

J'ai remplacé le script pour le tester dimanche 13h lors de mon renouvellement de certificats.

Par contre j'ai changé son nom  pour être homogène avec le précédent, j'ai gardé la notation dd_mm_yy  😉

[.Shad.]

Oh bah tu fais ce que tu veux, c'est pour m'internationaliser quand j'aurai conquis le monde !! (ou au moins une deuxième personne que toi 😄 😄)

[Jeff777]

Dans ce cas il va falloir faire à minima une traduction anglaise du tuto 😄

C'est vrai que je me sens un peu seul. C'est surprenant que personne d'autre ne soit intéressé.

  Quelqu'un a-t-il suivi le tuto de @Fenrir jusqu'à la zone publique????

[.Shad.]

Pas grand monde je pense, et perso j'irais jamais héberger ma zone DNS localement, même avec une IP fixe. 😛 
Le tutoriel est là pour aider, les commentaires du script se suffisent selon moi.

[Jeff777]

il y a 1 minute, .Shad. a dit :

perso j'irais jamais héberger ma zone DNS localement, même avec une IP fixe

Pourquoi ? Tu peux développer?

[.Shad.]

C'est typiquement le genre de chose que je préfère avoir sur un VPS ou directement hébergé par un tiers compétent.
Pour l'uptime, pour la latence des requêtes extérieures vers ton serveur aussi, pour DNSSEC et principalement le fait que DNS Server est juste BIND avec une interface qui limite dans certaines possibilités de configuration (même si c'est quand même assez complet).

PS : Ce n'est pas une question de sécurité, mais juste de préférence personnelle. 😉 

Modifié le 4 mars 2021 par .Shad.

[Jeff777]

il y a 8 minutes, .Shad. a dit :

PS : Ce n'est pas une question de sécurité, mais juste de préférence personnelle

Ah je suis rassuré ! et cela rassurera peut-être ceux qui veulent se lancer dans l'aventure.

[PiwiLAbruti]

Mes NAS hébergent chacun leur propre zone DNS publique (nas1.domain.tld, nas2.domain.tld, nas3.domain.tld, ...) et les répliquent entre eux.

La zone du domaine domain.tld reste (et restera) hébergé chez le registrar pour les raisons évoquées par @.Shad..

[Mic13710]

Il y a 2 heures, Jeff777 a dit :

Quelqu'un a-t-il suivi le tuto de @Fenrir jusqu'à la zone publique????

Je l'ai suivi (voir mon retour en page 2 du tuto), mais Free a eut la bonne idée de changer mon IP, ce qui a eu pour conséquence la perte de ma zone slave qui était hébergée chez Fenrir qui est comme chacun sait difficilement joignable. Ne pouvant attendre une correction de sa part, j'ai rebasculé ma zone chez OVH et elle est là depuis. De toute manière, je n'avais pas l'intention de la garder très longtemps car c'était plus pour l'exercice que pour une utilisation à long terme.

[Jeff777]

Intéressant  @PiwiLAbruti. Mais pourquoi avoir fait des zones publiques et non locales sur les nas ?

il y a 6 minutes, Mic13710 a dit :

mais Free a eut la bonne idée de changer mon IP, ce qui a eu pour conséquence la perte de ma zone slave

C'est sans doute ce qui va m'arriver lorsque je passerai à la fibre (dans les 10 ans qui viennent 🙄). Mais ma zone secondaire étant chez Hurricane Electric j'aurai toujours la main pour la modifier.

[PiwiLAbruti]

Il y a 3 heures, Jeff777 a dit :

Mais pourquoi avoir fait des zones publiques et non locales sur les nas ?

Je fais les deux. Je donnais juste un exemple d'hébergement d'une zone publique sur un NAS. Dans mon cas ça passe par des domaines supplémentaires redirigé depuis le domaine principal avec des enregistrements NS.

[.Shad.]

Il y a 3 heures, Mic13710 a dit :

Je l'ai suivi (voir mon retour en page 2 du tuto), mais Free a eut la bonne idée de changer mon IP, ce qui a eu pour conséquence la perte de ma zone slave qui était hébergée chez Fenrir qui est comme chacun sait difficilement joignable. Ne pouvant attendre une correction de sa part

Si c'est effectivement une zone esclave, il n'a rien à faire, lorsque tu mets à jour ta zone, tu incrémentes le serial et si tu as coché l'option "activer la notification des zones esclaves", ça va automatiquement les mettre à jour.
Enfin, sous réserve qu'il ait fait une transmission du port 53535, qui est le port utilisé par DNS Server justement pour la notification des zones. Et que tu aies autorisé son IP publique dans les paramètres de "Limiter le transfert de zone".

[Jeff777]

il y a 11 minutes, PiwiLAbruti a dit :

Dans mon cas ça passe par des domaines supplémentaires redirigé depuis le domaine principal avec des enregistrements NS.

Je suis intéressé. Des domaines supplémentaires : tu veux dire que nas1.domain, nas2..... sont des domaines propres avec des ip4 distinctes ? Comment rediriges tu la requête vers le bon nas...à moins d'utiliser l'IPV6. 

il y a 2 minutes, .Shad. a dit :

Si c'est effectivement une zone esclave, il n'a rien à faire, lorsque tu mets à jour ta zone, tu incrémentes le serial et si tu as coché l'option "activer la notification des zones esclaves", ça va automatiquement les mettre à jour.

Ca devrait marcher. D'ailleurs tu n'as même pas besoin de mettre à jour le sérial. DNS serveur le mettra tout seul lorsque l'on valide la nouvelle zone dans le master.

[.Shad.]

il y a 5 minutes, Jeff777 a dit :

Ca devrait marcher. D'ailleurs tu n'as même pas besoin de mettre à jour le sérial. DNS serveur le mettra tout seul lorsque l'on valide la nouvelle zone dans le master.

Je disais ça dans le sens que c'était une conséquence de modifier les enregistrements de ta zone. 😉 

[Jeff777]

il y a 1 minute, .Shad. a dit :

Je disais ça dans le sens que c'était une conséquence de modifier les enregistrements de ta zone.

Ah pardon.

 

il y a 12 minutes, .Shad. a dit :

Enfin, sous réserve qu'il ait fait une transmission du port 53535, qui est le port utilisé par DNS Server justement pour la notification des zones.

Ah ça je savais pas. Bon à savoir le jour où j'utiliserai un nas perso distant.