Transfert de Serveur Web - Eparpillement du DNS :(

Support Debian
#1

Bonjour

J’ai épuisé toutes mes idées pour la recherche du problème, je vous le soumet donc…
Il y a toujours eu plus d’idées dans plusieurs têtes que dans 1 seule…

J’avai un serveur web dédié monté en Debian 5.0.
Ca commencais a dater… Nous avons profité d’un concours de circonstances pour louer un autre serveur dédié et préparer le transfert des domaines et sites de l’ancien serveur au nouveau.

Nous avons sauvegardé l’ancien serveur et nous l’avons reformaté complètement qu’il ne nous perturbe pas…

Nous avons donc installé le nouveau serveur en Debian 7.2, réinstallé apache, postfix
Recréé les dossiers des sites, les gestions de virtualhosts dans apaches et bien sur les binds!

Avec une idée (surement idiote mais c’est trop tard!) de reprendre le même nom de machine que l’ancien, afin de permettre une reconfiguration plus rapide et plus simple (du moins le pensait on…)

Tous les fichiers bind ont été réécrits avec l’ip du nouveau serveur. Il n’y a nulle part dans la nouvelle configuration de référence à l’ip de l’ancien serveur…

Mais voila… A part le domaine principal qui est totalement et parfaitement muté, à peu près la moitié des autres domaines ou sous-domaines pointe encore inlassablement vers l’ip de l’ancienne machine…

Si ca peut orienter les réflexions, nous sommes 2 a nous casser la tête sur ce mystere, moi qui suis à Bordeaux et une autre personne à Montpellier…
Quand nous pingons les domaines ou les sous-domaines; nous n’avons pas tous les 2 toujours la même réponse. Lui peut le voir pointer sur la nouvelle IP et moi sur l’ancienne, ou inversement…

Le transfert a été fait il y a 3 jours, les caches auraient du être mis a jour?

Si vous aviez une idée d’où regarder, ca m’arrangerais, je commence a m’arracher les derniers cheveux qu’il me reste…

#2

[moderation]Salut et bienvenue,

Trucs & Astuces = section réservée aux tutoriels
Support = pour poser des questions

Je déplace.[/moderation]

#3

Pour un des (sous) domaines qui pose problème, sur ta machine fais un [mono]dig sous.domaine.com @8.8.8.8[/mono] (installe le paquet [mono]dnsutils[/mono] si nécessaire).
Si tu obtiens la bonne IP, compare avec un simple [mono]dig sous.domaine.com[/mono], et si tu as une différence le problème se trouve sur le serveur DNS que tu utilises sur ta connexion internet (celui de ton FAI probablement).

#4

Merci

Désolé,comme je venais de lire un certain nombre de tutos, j’ai pas fait attention… :confused:

DIG, voila une commande interessante que je ne connaissais pas…

Petite question, pourquoi @8.8.8.8 ?

Sinon, voila le résultat…

[quote]dig sous.domaine.com

Nouvelle IP Serveur[/quote]

[quote]dig sous.domaine.com @8.8.8.8

Ancienne IP Serveur[/quote]

[quote]dig sous.domaine.com @dns.domaine.com (mon serveur DNS)

Nouvelle IP Serveur[/quote]

[quote]dig sous.domaine.com @dns.gandi.net (second dns utilisé jusq’ici)

Ancienne IP Serveur[/quote]

:doh:

#5

C’est le serveur DNS de Google, accessible publiquement donc très bien pour faire des tests (et puis c’est facile à retenir…).

[quote=“PMSphere”][code]dig sous.domaine.com

Nouvelle IP Serveur

dig sous.domaine.com @8.8.8.8

Ancienne IP Serveur

dig sous.domaine.com @dns.domaine.com (mon serveur DNS)

Nouvelle IP Serveur

dig sous.domaine.com @dns.gandi.net (second dns utilisé jusq’ici)

Ancienne IP Serveur[/code][/quote]

Effectivement c’est bien le bordel. :open_mouth: En tous cas à vue de nez ça ressemble bien à un problème de cache/propagation.
Quel est le TTL de ton domaine ? Souvent c’est 24h (86400 secondes) mais si tu l’as augmenté c’est normal que certains serveurs DNS aient toujours l’ancienne IP en cache.

Quand tu fais un [mono]dig[/mono] tu peux aussi voir le TTL restant (en secondes) sur le serveur DNS avant qu’il n’invalide le cache de ton domaine. Dans l’exemple suivant c’est les 300 entre [mono]google.com.[/mono] et [mono]IN A[/mono] :

[code]$ dig google.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40076
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 300 IN A 173.194.67.101
google.com. 300 IN A 173.194.67.100
google.com. 300 IN A 173.194.67.102
google.com. 300 IN A 173.194.67.138
google.com. 300 IN A 173.194.67.139
google.com. 300 IN A 173.194.67.113

;; Query time: 228 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 2 18:37:19 2013
;; MSG SIZE rcvd: 124[/code]
En changeant de serveur DNS ([mono]@…[/mono] mais tu l’avais bien compris) ça te permettra de voir où en est le cache de chaque serveur.

#6

Et surtout il ne ment pas, contrairement à d’autres serveurs DNS “ouverts”.

[quote=“PMSphere”]Nous avons donc installé le nouveau serveur en Debian 7.2, réinstallé apache, postfix
Recréé les dossiers des sites, les gestions de virtualhosts dans apaches et bien sur les binds![/quote]
“Les binds” ? De quoi s’agit-il ?

Je suppose que tu parles des fichiers de zone ?
Sur quels serveurs DNS ?
Le numéro de série du SOA a-t-il été incrémenté ?
Le serveur qui a changé d’adresse IP faisait-il aussi office de DNS maître pour la zone ? Dans ce cas son nom et son adresse IP ont-ils été mis à jour sur les serveurs DNS esclaves pour la synchronisation de la zone, ainsi qu’auprès du registrar ?

Si tu donnais le nom de la zone et du sous-domaine, ce serait beaucoup plus simple de chercher ce qui cloche.

#7

Déjà merci pour ces réponses rapide, c’est un véritable bonheur :slightly_smiling:

Le DNS de google, voila effectivement une adresse a noter…

Le TTL des domaines (il y a effectivement plusieurs domaines sur le serveur) est réglé à 38400.
C’était comme ca dans la première config et je dois avouer avoir reproduit sans chercher plus loin.

Tous les indices concordent effectivement sur un problème de propagation, mais NonDiDiou pourquoi donc? :119

Il semble que le DNS secondaire, celui de gandi, ne se soit pas mis a jour et que celui de google non plus.
Mais la migration a été faite vendredi soir et nous sommes lundi soir… Meme si c’était 24h, elles sont passées? (enfin je crois… :shifty: )

Et là où c’est étonnant, c’est que les informations concernant le domaine principal du serveur, identique au nom de la machine, identique au nom du dns ont été mis a jour quasi instantanément.
Etonnant aussi, parmi les domaines hébergés par ce serveur, certains se sont mis a jour complètement (domaine et sous domaines), certains ne sont pas a jour du tout et d’autres sont partiellement a jour (domaine et certains sous domaines) et meme certains ont un domaine pas à jour mais certains sous domaine si!

J’y pense, mes domaines utilisent Gandi comme registrar, si l’info peut avoir une importance?

#8

Bonjour PascalHambourg

Je suis en grande partie autodidacte, et il est vrai que la terminologie pour désigner certaines choses n’est pas toujours académique. J’essaye d’apprendre au fur et à mesure pour devenir “compréhensible” par tous, mais il y a encore des couacs :slightly_smiling:

[quote=“PascalHambourg”]“Les binds” ? De quoi s’agit-il ?
Je suppose que tu parles des fichiers de zone ?[/quote]
Je pense que c’est ca oui. Des fichiers qui ressemblent à cela :

$ttl 38400 williamsonena.com. IN SOA ns0.thespheregroup.com. postmaster.thespheregroup.com. ( 2013120202 6h 3600 7d 24h ) williamsonena.com. IN NS ns0.thespheregroup.com. williamsonena.com. IN NS ns6.gandi.net. williamsonena.com. IN A 176.31.249.37 ns0.thespheregroup.com. IN A 176.31.249.37 ns6.gandi.net. IN A 217.70.177.40 www.williamsonena.com. IN A 176.31.249.37 pop.williamsonena.com. IN A 176.31.249.37

Sur le mien du coup : ns0.thespheregroup.com

Voila une excellente question… Ou trouverais je le numéro de serie du SOA?
S’il s’agit du numéro en haut, du fichier précédent au format AAAAMMJJnn, oui il l’est à chaque modification.

Oui, la 1ere machine servait de dns primaire et de serveur web. Elle a été reformatée afin d’éviter que 2 machines n’aient le même nom sur le réseau.
La seconde machine a été installée avec le même nom, et une ip différente, elle est dns primaire et serveur web.

Le DNS secondaire est celui de mon registrar, de Gandi donc. Selon les pages d’aide de gandi que j’ai parcouru, le dns secondaire ns6.gandi.net (celui qui était utilisé et qui l’est également avec le nouveau serveur) se met a jour automatiquement dans une période de 2 heures max. Je n’ai pas trouvé de process, de fonction, de bouton pour forcer une synchronisation.

Voila c’est fait, tout est dans le fichier de zone ( :smiley: ) que j’ai copié un peu plus haut

#9

ns0.thespheregroup.com. IN A 176.31.249.37 ns6.gandi.net. IN A 217.70.177.40
Ces enregistrements n’ont rien à faire dans le fichier de la zone williamsonena.com ; ils sont définis ailleurs, dans leurs zones respectives.

[code]$ host -vt ns thespheregroup.com e.gtld-servers.net.
;; AUTHORITY SECTION:
thespheregroup.com. 172800 IN NS ns6.gandi.net.
thespheregroup.com. 172800 IN NS ns0.thespheregroup.com.

;; ADDITIONAL SECTION:
ns6.gandi.net. 172800 IN A 217.70.177.40
ns0.thespheregroup.com. 172800 IN A 176.31.249.37[/code]
Bon point, le “glue record” contenant l’adresse du NS primaire ns0.thespheregroup.com dans la zone parente .com est à jour.

[code]$ host -t soa thespheregroup.com 176.31.249.37
thespheregroup.com has SOA record ns0.thespheregroup.com. postmaster.thespheregroup.com. 2013120202 21600 3600 604800 86400

$ host -t soa thespheregroup.com ns6.gandi.net.
Host thespheregroup.com not found: 2(SERVFAIL)[/code]
Par contre la zone sur le NS secondaire ns6.gandi.net est en erreur. Peut-être parce qu’elle n’a pas pu se rafraîchir à partir du NS primaire depuis trop longtemps.

[code]$ host -t soa williamsonena.com. 176.31.249.37
williamsonena.com has SOA record ns0.thespheregroup.com. postmaster.thespheregroup.com. 2013120202 21600 3600 604800 86400

$ host -t a williamsonena.com. 176.31.249.37
williamsonena.com has address 176.31.249.37

$ host -t soa williamsonena.com. ns6.gandi.net.
williamsonena.com has SOA record ns0.thespheregroup.com. postmaster.thespheregroup.com. 2011110603 21600 3600 604800 86400

$ host -t a williamsonena.com. ns6.gandi.net.
williamsonena.com has address 91.121.67.119[/code]
La zone williamsonena.com n’est pas en erreur sur le NS secondaire ns6.gandi.net mais elle n’est pas à jour comme en témoignent la valeur du serial du SOA et l’adresse IP différentes de celles sur le NS primaire.

Je soupçonne que l’adresse IP définie chez Gandi comme NS primaire pour les deux domaines n’a pas été mise à jour, et que le NS secondaire tente toujours de se rafraîchir à partir de l’ancienne adresse qui ne répond plus.

#10

Merci bien pour ce cheminement, j’ai encore découvert des options que je ne connaissais pas, j’adoooooore ca :slightly_smiling:

Et voila où le bas blesse… (à moins qu’une faiblesse de connaissances ne fausse mes conclusions :slightly_smiling:…)
Parce que si on interroge le ns6.gandi.net à propos du dns primaire, soit ns0.thespheregroup.com, ben… Il sait exactement ou il est! (Si j’ai pas fait d’erreur dans la syntaxe)

[code]$ dig ns0.thespheregroup.com @ns6.gandi.net

;; QUESTION SECTION:
;ns0.thespheregroup.com. IN A

;; ANSWER SECTION:
ns0.thespheregroup.com. 38400 IN A 176.31.249.37

;; AUTHORITY SECTION:
thespheregroup.com. 38400 IN NS ns6.gandi.net.
thespheregroup.com. 38400 IN NS ns0.thespheregroup.com.[/code]

Et dans la configuration du domaine chez Gandi, on a :

DNS 1 : ns0.thespheregroup.com DNS 2 : ns6.gandi.net

J’en concluais que Gandi savait où aller chercher le ns0.thespheregroup.com ?

Y aurait il une instruction qui pourrait bloquer, ou au contraire une instruction à ajouter pour “forcer”, la propagation entre le DNS primaire et secondaire? Parce que à cette étape je ne vois que ca :frowning:

#11

Ce matin les deux zones sont à jour dans ns6.gandi.net. L’ancienne adresse devrait disparaître avec l’expiration des caches des serveurs récursifs.

Oui, l’envoi d’un NOTIFY par le NS primaire au NS secondaire. Normalement c’est activé par défaut dans BIND. Par contre il faut que le NS secondaire soit configuré pour accepter les NOTIFY provenant de la nouvelle adresse IP du primaire. Par exemple dans BIND cela se fait par adresse IP, donc il faut la mettre à jour même si le nom de domaine du NS primaire ne change pas.

Mais même sans NOTIFY, le NS secondaire doit périodiquement vérifier auprès du NS primaire si la zone a changé. La période est spécifiée dans un des champs du SOA.

#12

Les sous.domaines se mettent lentement a jour, mais je reste interrogatif.
Les délais d’interrogation pour synchronisation annoncés par Gandi sont de 2 heures.
La mise en route du nouveau serveur date de vendredi 29/11 à 23h00… Ca fait donc plus de 80h et tout n’est pas synchro dans les bases du DNS de Gandi…

En tous les cas un grand merci pour toutes ces explications. Comme d’habitude, un probleme m’a permis d’en apprendre toujours plus, et c’est cool :slightly_smiling: