OVH Community, votre nouvel espace communautaire.

Y-a-t-il un gourou SDNS2/DNS dans la salle?


Me.B
30/09/2014, 15h21
Moi je me méfie des DNS OVH ainsi offert et je préfere utiliser ceux de cloudflare, certes parfois plus limité sur certaines entrée pointue mais c'est assez top pour le TTL.

M B

wxyz
30/09/2014, 10h48
Les quelques pistes données ici sont en train d'être essayés.
Les problèmes d'accès au manager, d'erreur 500, d'erreur de chargement des ipFO voire de la discordance des informations entre la v3 et la v6 sont révélateurs.
Quand au dig il raconte son ignorancei:

<<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> xxxxxxxxxxx.pt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45592
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 12

;; QUESTION SECTION:
;xxxxxxxxxxxx.pt. IN A

;; ANSWER SECTION:
xxxxxxxxxxxxxxxxxx.pt. 18930 IN A xxxxxxxxxxx

;; AUTHORITY SECTION:
pt. 114506 IN NS ns.dns.br.
pt. 114506 IN NS ns2.nic.fr.
pt. 114506 IN NS ns-pt.nlnetlabs.nl.
pt. 114506 IN NS ns.dns.pt.
pt. 114506 IN NS ns2.dns.pt.
pt. 114506 IN NS sns-pb.isc.org.
pt. 114506 IN NS auth200.ns.uu.net.
pt. 114506 IN NS auth210.ns.uu.net.

;; ADDITIONAL SECTION:
ns.dns.br. 116863 IN A 200.160.0.5
ns.dns.br. 114506 IN AAAA 2001:12ff:0:a20::5
ns.dns.pt. 1775 IN A 193.136.0.1
ns.dns.pt. 1775 IN AAAA 2001:690:a00:1016:905::1
ns2.dns.pt. 2889 IN A 193.136.2.226
ns2.dns.pt. 114506 IN AAAA 2001:690:a80:4001::100
ns2.nic.fr. 114700 IN A 192.93.0.4
ns2.nic.fr. 114367 IN AAAA 2001:660:3005:1::1:2
ns-pt.nlnetlabs.nl. 9312 IN A 185.49.140.61
ns-pt.nlnetlabs.nl. 114506 IN AAAA 2a04:b900::8:0:0:61
sns-pb.isc.org. 6400 IN A 192.5.4.1
sns-pb.isc.org. 128784 IN AAAA 2001:500:2e::1

;; Query time: 0 msec
;; SERVER: 10.1.38.3#53(10.1.38.3)
;; WHEN: Tue Sep 30 10:37:58 2014
;; MSG SIZE rcvd: 512

captainadmin
29/09/2014, 23h01
Bonsoir,

Que donne le dig ns de ton nom de domaine ?

Il semble que les dns OVH posent problèmes, perso j'utilise ceux de gandi qui ont toujours été fiable.
Il faudrait purger tes domaines avec un TTL court en espérant que la propagation ne prenne pas trop de temps. 24h max pour l'europe 48 pour le monde.

Il n'y a pas de raison pour que la résolution se fasse mal sur vos sites, le seul problème visiblement est le changement de serveur dns primaire chez OVH avec une conf asymétrique.
C'est assez bizarre mais ca peut arriver.

Bon courage pour la suite
http://www.captainadmin.com

cassiopee
29/09/2014, 19h48
Tomber de Charybde en Scylla ...

Bon, là ça a l'air d'être quand même exceptionnel (heureusement)

wxyz
29/09/2014, 18h16
Citation Envoyé par cassiopee
De mon côté, lorsqu'il s'agit de site web professionnels, j'ai renoncé à utiliser les serveurs DNS esclaves d'OVH (sdns1.ovh.net, sdns2.ovh.net).

Il y a trop d'aléas, de bugs, etc. Et même lorsque tout est au vert, la synchronisation peut se faire en 5 minutes comme en plusieurs heures.

Lorsque l'on a à gérer 1 ou 2 noms de domaines, pourquoi pas mais autrement non.

Récemment, j'ai eu à transférer 150 noms de domaines d'un serveur dédié à un autre. Comme ils n'utilisaient pas d'IP failover
dans le serveur de départ, il a fallu faire les 150 changements au niveau noms des serveurs DNS (et donc faire également
150 purges dans le manager de l'ancien dédié)

Rien que pour gérer les 5 premiers, il a fallu attendre plus de 6 heures ... ce n'était pas possible de continuer comme ça.

J'ai donc mis en place un serveur DNS esclave pour mon client. Résultat au premier démarrage, il a synchronisé
les 50 premiers noms de domaines déjà transférés en ... 5 secondes, ça change la vie
Ici les sites ont une ip Failover. La migration des sites d'un serveur à l'autre se fait via le manager .....
.....que l'on n'arrive pas à atteindre ce soir:


;504 Backend unavailable

Oupps.. seems that something went wrong.

If the problems persists, please contact us, we will do our best to fix it.

cassiopee
29/09/2014, 13h27
De mon côté, lorsqu'il s'agit de site web professionnels, j'ai renoncé à utiliser les serveurs DNS esclaves d'OVH (sdns1.ovh.net, sdns2.ovh.net).

Il y a trop d'aléas, de bugs, etc. Et même lorsque tout est au vert, la synchronisation peut se faire en 5 minutes comme en plusieurs heures.

Lorsque l'on a à gérer 1 ou 2 noms de domaines, pourquoi pas mais autrement non.

Récemment, j'ai eu à transférer 150 noms de domaines d'un serveur dédié à un autre. Comme ils n'utilisaient pas d'IP failover
dans le serveur de départ, il a fallu faire les 150 changements au niveau noms des serveurs DNS (et donc faire également
150 purges dans le manager de l'ancien dédié)

Rien que pour gérer les 5 premiers, il a fallu attendre plus de 6 heures ... ce n'était pas possible de continuer comme ça.

J'ai donc mis en place un serveur DNS esclave pour mon client. Résultat au premier démarrage, il a synchronisé
les 50 premiers noms de domaines déjà transférés en ... 5 secondes, ça change la vie

bbr18
29/09/2014, 12h43
Avant de rendre tes anciens serveurs, avais-tu bien retiré tous les domaines présents dans les DNS secondaires de chacun des serveurs ?
Si tu ne l'avais pas fait, seul le support peut les retirer.

wxyz
29/09/2014, 11h15
Bonjour,
Le problème exposé ci-dessous est relié à un serveur eg 64 sous centos 6 cpanel (gamme infrastructure).

Pour certains de nos domaines hébergés sur le serveur ci-dessus , DNS2 indique des serveurs qui ne nous appartiennent plus ou pas. Ces problèmes de DNS secondaire rendent nos sites inaccessibles par intermittence.

Chaque fois que l’on dévie un site devenu inaccessible sur un autre serveur, le problème est incrémenté, c’est-à-dire le serveur indiqué par dns2 est un de nos anciens serveurs. Cette observation a été démontrée clairement par l’hébergement itératif de certains de nos ndd sur des serveurs loués à la semaine …avec des panels et OS différents.

Un ndd qui nous pose de gros problème a été isolé tout seul sur un serveur de secours, il y a 8 jours. A ce moment, pour ce ndd dns2.ovh.net donne ns311118.ip-176-31-239.eu. (serveur qui ne nous appartient plus=serveur loué à la semaine).
Des discussions ont eu lieu avec le support OVH qui raconte n’importe quoi . Le support OVH nous a parlé de DNS mal indiqués sur nos serveurs, puis de bug dans Cpanel puis dans le firewall. Nous n’avons rien trouvé. Ces problèmes ont été également investigués par les supports de Cpanel et atomicorp qui nous ont expliqués qu’OVH racontaient des bêtises. Maintenant, le support OVH ne met plus en cause cpanel ou atomicorp, mais nous explique que c’est Gandi qui a des bugs dans la gestion de ses noms de domaine et nous suggère de rapatrier chez ovh tous nos noms de domaine…..
Mais les noms de domaine sont enregistrés chez gandi, namebay et switch…

Après cette discussion avec le support OVH, le site qui pose actuellement problème a été rapatrié sur le serveur principal depuis le serveur de secours (centos 6, plesk). Le site a été effacé du serveur de secours. Le rapatriement a été effectué via des ipFO. Huit jours après (donc hier), ça se cassait la figure. Le site a été remonté sur le serveur de secours et devenait accessible. A cet instant, dig indiquait non plus ns311118, mais le serveur de secours actuel (donc nouvelle incrémentation !). Aucun changement n’a été effectué chez gandi qui indique depuis 6 mois au moins le serveur principal.

Pour nous, il devient clair qu’il existe des problèmes itérativement reproductibles de cache/reroutage dans SDNS2 et que le problème se situe chez ovh et non ailleurs (c’est-à-dire pas dans nos serveurs ni chez les registrar). D'ailleurs la coïncidence avec un manageur v6 qui renvoie des erreurs 500 ou des erreurs chargement d’ip est troublante.

Y-a-t-il un moyen de forcer sdns2 à reconnaître le serveur principal malgré les bugs ovh ?
Y-a-t-il un moyen de contacter une personne de support niveau plus élevé ?
merci de nous soumettre toutes vos idées (nous on en a plus!)


N.B.: le serveur de secours est aussi dans la gamme infrastructure (eg32, centos6, plesk12)