DNS secondaire non fonctionnel

Bare Metal and VPS
1

Bonjour,

Le DNS secondaire Kimsufi semble ne pas fonctionner comme attendu… Il ne résout pas quand le primaire est Hors service.


* Le whois pointe bien sur ns.kimsufi.com et mon serveur.

* le serveur DNS est référencé comme le montre le screen shoot.

737ff6ef5f3b3ca9bf92e1092806c06a5d0ec748.jpg936×258 20.6 KB

Domain1.com et domain2.com

* Le champ ownercheck dans TXT est bien réglé sur la valeur demandée dans le tableau de bord, normal, sinon le screen n'afficherait pas l'ip…

* Le transfert s'effectue selon ce que je comprends des logs :
Mar 28 10:29:26 dedie6 named[114492]: client @0x7f3f4c02dd10 213.186.33.199#41687 (domain1.com): transfer of 'domain1.com/IN': AXFR started (serial 4294967295)
Mar 28 10:29:26 dedie6 named[114492]: client @0x7f3f4c02dd10 213.186.33.199#41687 (domain1.com): transfer of 'domain1.com/IN': AXFR ended: 1 messages, 85 records, 1879 bytes, 0.001 secs (1879000 bytes/sec)

Sur les deux domaines, un seul est résolu par kimsufi (domaine2.com), d'ailleurs celui qui fonctionne n'est pas à jour malgré les multiples tentatives de mise à jour par "named".
L'outil qui gère la configuration de named est ISPConfig…

J'ai regardé les nombreux postes sur le forum ovh sur le sujet, mais cela concerne ovh t non kimsufi.

Auriez-vous une idée qui expliquerait pourquoi ns.kimsufi.com ne répond pas aux requêtes quand le serveur principale (le mien) n'est pas en service svp ?

Cordialement.

2

domain1.com


Bonjour,

Sans un vrai nom de domaine, difficile de répondre quoi que ce soit.
3

Bonjour Frtiz,

Si ca peut servir voici :

domain1.com = applireseau.com
domain2.com gyptis.org

merci :wink:

4

Si ca peut servir voici :


Vous avez un problème avec vos serial qui ne sont pas incrémentés:

voici les deux serveurs DNS

gyptis.org. 3600 IN SOA dedie.applireseau.com. jmans0001.gyptis.org. 4294967295 600 540 60480 86400

gyptis.org. 3600 IN SOA 91.121.70.33. jmans0001.gyptis.org. 4294967295 600 540 604800 86400

(d'ailleurs, le serial de votre SOA pour applireseau est identique à celui-ci !)
5

Bonjour Fritz

Merci je vais regarder ça dans ISPConfig, qui ne permet pas de modifier les N° de serie :confused:

++

6

Bonjour Fritz,

Après quelques tests, il s'avère que le N° de série n'était pas accepté de la part de ns.kimsufi ; pourtant valide, car libre…

Le nombre 4 294 967 296 (soit 2^32 ) était visiblement ce qu'il le gênait ; en utilisant un autre secondaire, cela ne posait pas de problèmes.

J'ai tenté de baisser à 3 994 967 311 mais tjs rien.
En mettant la date du jour, comme c'est coutume, il a pu accepter.

Merci encore pour ton intervention.

7

Le nombre 4 294 967 296 (soit 2^32 ) était visiblement ce qu'il le gênait ; en utilisant un autre secondaire, cela ne posait pas de problèmes.


Il faut revoir la théorie, le n° de série doit être incrémenté à chaque mise à jour.
Normalement si vous le décrémentez, le ns secondaire ne va pas prendre la mise à jour.

D'où l'utilité de mettre la date et le n° de séquence pour ce jour, ainsi on ne recule jamais l'horloge. Ce standard est communément admis mais non obligatoire, du moment que vous ne revenez jamais en arrière.
8

Tout à fait, mais si named gère le N° de série sur un registre 32 bits on a donc la solution du problème puisque 4 294 967 296 ( -1) mets tous les bits à 1 et donc le secondaire ne peut pas savoir qu'il y a eu changement.
Tout comme le primaire bloqué car il atteint la valeur limite sur 32bits. En assembleur un "add registre" remet à 0 ce dernier, mais named doit utiliser un "unsigne long int" d'où le problème.
De mémoire, le serial sert à ça.
Ce qui est rageant est que ISPConfig n'alerte pas. Mais bon, le pb est résolu c'est la seule chose qui compte :wink: