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

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


Reply to: