Bind9 slave

Le
BERTRAND Jo=c3=abl
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
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 ?

Bien cordialement,

JKB
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
NoSpam
Le #26538022
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
NoSpam
Le #26538034
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
NoSpam
Le #26538056
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
; ;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
; ;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 #26538088
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
; ;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
; ;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 #26538103
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
> > > ; > > > ;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
> > > ; > > > ;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
; ;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
Poster une réponse
Anonyme