Re: Bind9 slave
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.1741IN 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 >
Re: Bind9 slave
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
Re: Bind9 slave
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
Re: Bind9 slave
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. 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_. Je suis sûr que ça fonctionnait précédemment. JB
Re: Bind9 slave
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 et la seconde entrée, avant le A ou 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.1741IN 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
Re: Bind9 slave
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 et la seconde entrée, avant le A ou 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.1741IN 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. JB
Re: Bind9 slave
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 et la seconde entrée, avant le A ou 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
Re: Bind9 slave
NoSpam a écrit : > > 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 >> 2019xx). 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? Oui. Root rayleigh:[/var/lib/bind] > tcpdump -i br0 -p port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:29:10.392473 IP rayleigh-udp.53522 > 192.168.1.2.domain: 47389 notify [b2&3=0x2400] [1a] SOA? 10.168.192.in-addr.arpa. (101) 18:29:10.454588 IP 192.168.1.2.domain > rayleigh-udp.53522: 47389 notify*- 0/0/0 (41) rayleigh-udp est l'adresse locale sur le VPN du master. 192.168.1.2 est l'adresse du slave. Donc le redémarrage du master envoie bien une notification au slave. Naturellement, j'ai vérifié que les deux serial étaient bons. > 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 et la seconde entrée, avant le A ou est le TTL Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans le compteur local du DNS. Cordialement, JB
Re: Bind9 slave
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 2019xx). 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 et la seconde entrée, avant le A ou est le TTL -- Daniel
Bind9 slave
Bonjour à tous, 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 2019xx). 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 ? Bien cordialement, JKB
