[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.            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
> 


Reply to: