Migration vers un nouveau kimsufi : étape ultime

Normalement, j'avais terminé la migration vers mon nouveau serveur mais c'était sans compter sur une erreur humaine !

Avant de partir en vacances, tout fonctionnait correctement. Enfin c'est ce que je croyais.

Je suis parti le 9 juillet. OVH a comme prévu récupéré mon ancien serveur le 10 juillet et à partir de là le nouveau a été aux abonnés absents. J'ai mis du temps à m'en rendre compte car je n'avais pas internet sur mes lieux de vacances !!! En fait jusqu'au 9 juillet c'était en fait l'ancien serveur qui renseignait les DNS de la planète sur mon nom de domaine. Le nouveau serveur était mal configuré et refusait les connexions sur le port 53. Du coup pendant un mois, mon serveur ne répondait plus. 

Le fichier de configuration fautif était /etc/bind/named.conf.options. Sur mon ancien serveur, j'avais :

options {
        directory "/var/cache/bind";
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
        allow-recursion { localhost; };
};

Le nouveau était :

options {
       directory "/var/cache/bind";
       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { ::1; };
       listen-on-v6 { any; };
       listen-on { 127.0.0.1; };
       allow-recursion { 127.0.0.1; };
};

La ligne fautive était la ligne 6. Elle n'était pas présente dans l'ancienne configuration et faisait que le serveur ne répondait que localement. En la commentant tout est rentré dans l'ordre en quelques heures, le temps que la propagation se fasse.

Le changement de serveur avant de partir en vacances, c'est un peu comme la mise en production d'une nouvelle version majeure un vendredi, c'est à éviter absolument. On ne s'en rappelle vraiment que quand on a fait une fois la bêtise !

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.