Petit problème avec bind9. J'ai une configuration master/slave avec le
master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un
champ sur le master en modifiant le serial pour 2020021201 (auparavant
2019xxxxxx). J'ai eu beau relancer les deux bind, je voyais passer les
paquets de notification, mais le slave n'était pas mis à jour.
En virant le fichier cache sur le slave, la zone a finalement été propagée.
Or il me semblait qu'il suffisait que le serial soit supérieur sur le
maître pour que le slave se mettre immédiatement à jour lorsqu'il était
redémarré. Suis-je dans le vrai ?
Dernière chose : il me semble qu'il existe une commande pour obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
NoSpam
Le 12/02/2020 à 16:06, BERTRAND Joël a écrit :
Bonjour à tous,
Bonjour
Petit problème avec bind9. J'ai une configuration master/slave avec le master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un champ sur le master en modifiant le serial pour 2020021201 (auparavant 2019xxxxxx). J'ai eu beau relancer les deux bind, je voyais passer les paquets de notification, mais le slave n'était pas mis à jour. En virant le fichier cache sur le slave, la zone a finalement été propagée. Or il me semblait qu'il suffisait que le serial soit supérieur sur le maître pour que le slave se mettre immédiatement à jour lorsqu'il était redémarré. Suis-je dans le vrai ?
Tu as bien un notify pour la zone vers le slave?
Dernière chose : il me semble qu'il existe une commande pour obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL -- Daniel
Le 12/02/2020 à 16:06, BERTRAND Joël a écrit :
Bonjour à tous,
Bonjour
Petit problème avec bind9. J'ai une configuration master/slave avec le
master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un
champ sur le master en modifiant le serial pour 2020021201 (auparavant
2019xxxxxx). J'ai eu beau relancer les deux bind, je voyais passer les
paquets de notification, mais le slave n'était pas mis à jour.
En virant le fichier cache sur le slave, la zone a finalement été propagée.
Or il me semblait qu'il suffisait que le serial soit supérieur sur le
maître pour que le slave se mettre immédiatement à jour lorsqu'il était
redémarré. Suis-je dans le vrai ?
Tu as bien un notify pour la zone vers le slave?
Dernière chose : il me semble qu'il existe une commande pour obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Petit problème avec bind9. J'ai une configuration master/slave avec le master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un champ sur le master en modifiant le serial pour 2020021201 (auparavant 2019xxxxxx). J'ai eu beau relancer les deux bind, je voyais passer les paquets de notification, mais le slave n'était pas mis à jour. En virant le fichier cache sur le slave, la zone a finalement été propagée. Or il me semblait qu'il suffisait que le serial soit supérieur sur le maître pour que le slave se mettre immédiatement à jour lorsqu'il était redémarré. Suis-je dans le vrai ?
Tu as bien un notify pour la zone vers le slave?
Dernière chose : il me semble qu'il existe une commande pour obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL -- Daniel
NoSpam
Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :
[...]
Dernière chose : il me semble qu'il existe une commande pour
obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant restant. J'ai bien compris ? ;) -- Daniel
Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :
[...]
Dernière chose : il me semble qu'il existe une commande pour
obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans
le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant
restant. J'ai bien compris ? ;)
Dernière chose : il me semble qu'il existe une commande pour
obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant restant. J'ai bien compris ? ;) -- Daniel
NoSpam
Le 12/02/2020 à 19:28, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :
[...]
Dernière chose : il me semble qu'il existe une commande pour
obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant restant. J'ai bien compris ? ;)
Oui. Maintenant, ce que je ne saisis pas. legendre# dig @8.8.8.8 systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr ;systella.fr. IN A systella.fr. 1741 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Ça semble normal (1741). Sur le slave : legendre# dig @localhost systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la seconde fois et celles d'après le TTL décrémenté. Si tu utilises des views dig n'affichera que les vues locales. -- Daniel
Le 12/02/2020 à 19:28, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :
[...]
Dernière chose : il me semble qu'il existe une commande pour
obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant
dans
le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant
restant. J'ai bien compris ? ;)
Oui.
Maintenant, ce que je ne saisis pas.
legendre# dig @8.8.8.8 systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
;systella.fr. IN A
systella.fr. 1741 IN SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400
Ça semble normal (1741). Sur le slave :
legendre# dig @localhost systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
;systella.fr. IN A
systella.fr. 86400 IN SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400
(tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête
dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la
seconde fois et celles d'après le TTL décrémenté. Si tu utilises des
views dig n'affichera que les vues locales.
Dernière chose : il me semble qu'il existe une commande pour
obtenir le TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?
dig <domaine> et la seconde entrée, avant le A ou AAAA est le TTL
Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans le compteur local du DNS.
Le TTL affiché par dig est décrémenté ce qui pour moi est le tant restant. J'ai bien compris ? ;)
Oui. Maintenant, ce que je ne saisis pas. legendre# dig @8.8.8.8 systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr ;systella.fr. IN A systella.fr. 1741 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Ça semble normal (1741). Sur le slave : legendre# dig @localhost systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la seconde fois et celles d'après le TTL décrémenté. Si tu utilises des views dig n'affichera que les vues locales. -- Daniel
NoSpam
Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :
NoSpam a écrit :
Maintenant, ce que je ne saisis pas. legendre# dig @8.8.8.8 systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr ;systella.fr. IN A systella.fr. 1741 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Ça semble normal (1741). Sur le slave : legendre# dig @localhost systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la seconde fois et celles d'après le TTL décrémenté. Si tu utilises des views dig n'affichera que les vues locales.
Bon, j'obtiens toujours le même.
Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca fonctionne
Ce n'est pas grave. Ce qui l'est en revanche plus, c'est la non propagation sur le slave _sans enlever le fichier cache_.
Problème version BSD ? -- Daniel
Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :
NoSpam a écrit :
Maintenant, ce que je ne saisis pas.
legendre# dig @8.8.8.8 systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
;systella.fr. IN A
systella.fr. 1741 IN SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400
Ça semble normal (1741). Sur le slave :
legendre# dig @localhost systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
;systella.fr. IN A
systella.fr. 86400 IN SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400
(tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête
dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la
seconde fois et celles d'après le TTL décrémenté. Si tu utilises des
views dig n'affichera que les vues locales.
Bon, j'obtiens toujours le même.
Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca
fonctionne
Ce n'est pas grave. Ce qui l'est en
revanche plus, c'est la non propagation sur le slave _sans enlever le
fichier cache_.
Maintenant, ce que je ne saisis pas. legendre# dig @8.8.8.8 systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr ;systella.fr. IN A systella.fr. 1741 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Ça semble normal (1741). Sur le slave : legendre# dig @localhost systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la seconde fois et celles d'après le TTL décrémenté. Si tu utilises des views dig n'affichera que les vues locales.
Bon, j'obtiens toujours le même.
Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca fonctionne
Ce n'est pas grave. Ce qui l'est en revanche plus, c'est la non propagation sur le slave _sans enlever le fichier cache_.
Problème version BSD ? -- Daniel
Christophe Maquaire
Le jeudi 13 février 2020 à 08:24 +0100, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 12/02/2020 à 23:06, BERTRAND Joël a écrit : > NoSpam a écrit : > > > Maintenant, ce que je ne saisis pas. > > > > > > legendre# dig @8.8.8.8 systella.fr | grep systella > > > ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr > > > ;systella.fr. IN A > > > systella.fr. 1741 IN SOA > > > rayleigh.systella.fr. > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400 > > > > > > Ça semble normal (1741). Sur le slave : > > > > > > legendre# dig @localhost systella.fr | grep systella > > > ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr > > > ;systella.fr. IN A > > > systella.fr. 86400 IN SOA > > > rayleigh.systella.fr. > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400 > > > > > > (tous les slaves tant qu'à faire) et le master, j'obtiens > > > 86400. > > Avec Debian9 et Debian10 en slave, je dois faire deux fois la > > requête > > dig: la 1ere fois comme toi j'obtiens le TTL défini dans le > > master, la > > seconde fois et celles d'après le TTL décrémenté. Si tu > > utilises des > > views dig n'affichera que les vues locales. > Bon, j'obtiens toujours le même. Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca fonctionne
Oui, sur 8.8.8.8, ça fonctionne.
> Ce n'est pas grave. Ce qui l'est en > revanche plus, c'est la non propagation sur le slave _sans > enlever le > fichier cache_. Problème version BSD ?
Pas sûr. Il y a deux slaves, l'un sur un NetBSD, l'autre chez Nerim. Même motif, même punition : legendre# dig @noemie.nerim.net systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Je ne sais pas sous quel OS tourne noemie.nerim.net, mais les probabilités pour que ce serveur tourne sous un NetBSD me semblent assez faibles. Autre chose : noemie.nerim.net prend immédiatement en compte le serial et met à jour la zone. Je viens de tester en incrémentant le serial. Heureusement d'ailleurs, parce que ce serveur utilise aussi nsupdate pour mettre à jour un certificat letsencrypt *.systella.fr. Pour information, les versions de bind9 sont les suivantes : - master (Linux Debian/testing) : BIND 9.11.14-3-Debian (Extended Support Version) - slave1 (NetBSD 8.1) : BIND 9.10.5-P1 (Extended Support Version) - slave2 (chez Nerim) : version inconnue, je ne suis même pas sûr que ce soit un bind9. La seule différence entre les deux : - slave1 récupère la vue interne (slave1 est le DNS d'un site distant relié par VPN et n'est pas un DNC public) ; - slave2 récupère la vue externe (et est, lui, public). dig axfr @master fonctionne parfaitement (et il n'y a pas de problème réseau ou de MTU). Le système de vues fonctionne parfaitement. Lorsque la résolution des noms arrive depuis une interface LAN/VPN, bind retourne les adresses de la vue interne. Sinon, celles de la vue externe. Bref, tout ça n'est pas clair. Je comprendrais cette absence de propagation sur slave1 si la requête dig axfr depuis slave1 échouait ou s'il n'y avait pas de paquet de notification. Or dig axfr fonctionne et je vois le paquet de notification ainsi que sa réponse ! Bien cordialement, JB
Le jeudi 13 février 2020 à 08:24 +0100, BERTRAND Joël a écrit :
NoSpam a écrit :
> Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :
> > NoSpam a écrit :
> > > > Maintenant, ce que je ne saisis pas.
> > > >
> > > > legendre# dig @8.8.8.8 systella.fr | grep systella
> > > > ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
> > > > ;systella.fr. IN A
> > > > systella.fr. 1741 IN SOA
> > > > rayleigh.systella.fr.
> > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400
> > > >
> > > > Ça semble normal (1741). Sur le slave :
> > > >
> > > > legendre# dig @localhost systella.fr | grep systella
> > > > ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
> > > > ;systella.fr. IN A
> > > > systella.fr. 86400 IN SOA
> > > > rayleigh.systella.fr.
> > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400
> > > >
> > > > (tous les slaves tant qu'à faire) et le master, j'obtiens
> > > > 86400.
> > > Avec Debian9 et Debian10 en slave, je dois faire deux fois la
> > > requête
> > > dig: la 1ere fois comme toi j'obtiens le TTL défini dans le
> > > master, la
> > > seconde fois et celles d'après le TTL décrémenté. Si tu
> > > utilises des
> > > views dig n'affichera que les vues locales.
> > Bon, j'obtiens toujours le même.
> Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca
> fonctionne
Oui, sur 8.8.8.8, ça fonctionne.
> > Ce n'est pas grave. Ce qui l'est en
> > revanche plus, c'est la non propagation sur le slave _sans
> > enlever le
> > fichier cache_.
>
> Problème version BSD ?
Pas sûr. Il y a deux slaves, l'un sur un NetBSD, l'autre chez
Nerim.
Même motif, même punition :
legendre# dig @noemie.nerim.net systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net systella.fr
;systella.fr. IN A
systella.fr. 86400 IN SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400
Je ne sais pas sous quel OS tourne noemie.nerim.net, mais les
probabilités pour que ce serveur tourne sous un NetBSD me semblent
assez
faibles.
Autre chose : noemie.nerim.net prend immédiatement en compte le
serial
et met à jour la zone. Je viens de tester en incrémentant le serial.
Heureusement d'ailleurs, parce que ce serveur utilise aussi nsupdate
pour mettre à jour un certificat letsencrypt *.systella.fr.
Pour information, les versions de bind9 sont les suivantes :
- master (Linux Debian/testing) : BIND 9.11.14-3-Debian (Extended
Support Version)
- slave1 (NetBSD 8.1) : BIND 9.10.5-P1 (Extended Support Version)
- slave2 (chez Nerim) : version inconnue, je ne suis même pas sûr que
ce
soit un bind9.
La seule différence entre les deux :
- slave1 récupère la vue interne (slave1 est le DNS d'un site distant
relié par VPN et n'est pas un DNC public) ;
- slave2 récupère la vue externe (et est, lui, public).
dig axfr @master fonctionne parfaitement (et il n'y a pas de
problème
réseau ou de MTU).
Le système de vues fonctionne parfaitement. Lorsque la
résolution des
noms arrive depuis une interface LAN/VPN, bind retourne les adresses
de
la vue interne. Sinon, celles de la vue externe.
Bref, tout ça n'est pas clair. Je comprendrais cette absence de
propagation sur slave1 si la requête dig axfr depuis slave1 échouait
ou
s'il n'y avait pas de paquet de notification. Or dig axfr fonctionne
et
je vois le paquet de notification ainsi que sa réponse !
Le jeudi 13 février 2020 à 08:24 +0100, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 12/02/2020 à 23:06, BERTRAND Joël a écrit : > NoSpam a écrit : > > > Maintenant, ce que je ne saisis pas. > > > > > > legendre# dig @8.8.8.8 systella.fr | grep systella > > > ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr > > > ;systella.fr. IN A > > > systella.fr. 1741 IN SOA > > > rayleigh.systella.fr. > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400 > > > > > > Ça semble normal (1741). Sur le slave : > > > > > > legendre# dig @localhost systella.fr | grep systella > > > ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr > > > ;systella.fr. IN A > > > systella.fr. 86400 IN SOA > > > rayleigh.systella.fr. > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400 > > > > > > (tous les slaves tant qu'à faire) et le master, j'obtiens > > > 86400. > > Avec Debian9 et Debian10 en slave, je dois faire deux fois la > > requête > > dig: la 1ere fois comme toi j'obtiens le TTL défini dans le > > master, la > > seconde fois et celles d'après le TTL décrémenté. Si tu > > utilises des > > views dig n'affichera que les vues locales. > Bon, j'obtiens toujours le même. Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca fonctionne
Oui, sur 8.8.8.8, ça fonctionne.
> Ce n'est pas grave. Ce qui l'est en > revanche plus, c'est la non propagation sur le slave _sans > enlever le > fichier cache_. Problème version BSD ?
Pas sûr. Il y a deux slaves, l'un sur un NetBSD, l'autre chez Nerim. Même motif, même punition : legendre# dig @noemie.nerim.net systella.fr | grep systella ; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net systella.fr ;systella.fr. IN A systella.fr. 86400 IN SOA rayleigh.systella.fr. bertrand.systella.fr. 2020021201 28800 7200 604800 86400 Je ne sais pas sous quel OS tourne noemie.nerim.net, mais les probabilités pour que ce serveur tourne sous un NetBSD me semblent assez faibles. Autre chose : noemie.nerim.net prend immédiatement en compte le serial et met à jour la zone. Je viens de tester en incrémentant le serial. Heureusement d'ailleurs, parce que ce serveur utilise aussi nsupdate pour mettre à jour un certificat letsencrypt *.systella.fr. Pour information, les versions de bind9 sont les suivantes : - master (Linux Debian/testing) : BIND 9.11.14-3-Debian (Extended Support Version) - slave1 (NetBSD 8.1) : BIND 9.10.5-P1 (Extended Support Version) - slave2 (chez Nerim) : version inconnue, je ne suis même pas sûr que ce soit un bind9. La seule différence entre les deux : - slave1 récupère la vue interne (slave1 est le DNS d'un site distant relié par VPN et n'est pas un DNC public) ; - slave2 récupère la vue externe (et est, lui, public). dig axfr @master fonctionne parfaitement (et il n'y a pas de problème réseau ou de MTU). Le système de vues fonctionne parfaitement. Lorsque la résolution des noms arrive depuis une interface LAN/VPN, bind retourne les adresses de la vue interne. Sinon, celles de la vue externe. Bref, tout ça n'est pas clair. Je comprendrais cette absence de propagation sur slave1 si la requête dig axfr depuis slave1 échouait ou s'il n'y avait pas de paquet de notification. Or dig axfr fonctionne et je vois le paquet de notification ainsi que sa réponse ! Bien cordialement, JB
