Auteur:


Date:
30/08/2010

Catégories:
Open-source
Reseau

Tags:





De l’utilité de gérer des serials DNS standards

Depuis la migration de mon nom de domaine vers les serveurs Gandi (suite au hack du site), le blog de Nicolargo est injoignable depuis certains FAI (notamment les Freenautes ce qui le coupe de plus d'un tiers du trafic Français)...

Après des échanges ping pong entre le support de Gandi et celui de Free, j'ai décidé de prendre les choses en main, du moins en ce qui concerne l'identification du problème.

Le comportement est le suivant: sur le réseau Free, certains lecteurs voient normalement le blog tandis que d'autre sont redirigé vers l'ancienne adresse du serveur (aujourd'hui un compte iWeb8 suspendu). J'arrive parfaitement à reproduire ce comportement depuis chez moi (et oui je suis chez Free ;) ).

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 85644 IN SOA ns1.panelboxmanager.com. logs.logs.privatedns.com. (
2010072800 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
nicolargo.com. 13644 IN A 72.55.186.68
nicolargo.com. 85644 IN NS ns1.panelboxmanager.com.
nicolargo.com. 85644 IN NS ns2.panelboxmanager.com.
nicolargo.com. 13644 IN MX 0 nicolargo.com.

---

nicolargo@nicolargo-laptop:~$ dig +nocmd nicolargo.com any +multiline +noall +answer

nicolargo.com. 10080 IN MX 10 spool.mail.gandi.net.
nicolargo.com. 10080 IN MX 50 fb.mail.gandi.net.
nicolargo.com. 10080 IN A 217.70.184.38
nicolargo.com. 10080 IN SOA a.dns.gandi.net. hostmaster.gandi.net. (
1282917455 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)
nicolargo.com. 10080 IN NS a.dns.gandi.net.
nicolargo.com. 10080 IN NS b.dns.gandi.net.
nicolargo.com. 10080 IN NS c.dns.gandi.net.

Une fois la résolution de nom se fait normalement (c'est à dire avec les NS pointant chez Gandi: dns.gandi.net), une fois non (les DNS pointent encore sur panelboxmanager.com, les serveurs DNS de iWeb8).

En regardant de plus près la réponse on peut voir les deux lignes suivantes:

Réponse venant de iWeb8: "2010072800 ; serial"

Réponse venant de Gandi: "1282917455 ; serial"

Je commence alors à comprendre d'ou vient le problème: quand le domaine était géré par iWeb8, ces derniers utilisait une gestion standard des numéro de série au format ANNEE-MOIS-JOUR-ID (2010072800), ce qui n'est pas le cas de Gandi qui doit générer dynamiquement ce numéro avec un algorithme interne (1282917455). Dans mon grand malheur, le numéro de série Gandi de la zone DNS nicolargo.com est inférieur à celui chez iWeb8. Il est donc normal que les serveurs DNS ne soit pas mis à jour...

Un petit tour du coté d'un site de validation de zone DNS:

Je viens d'envoyer un mail au support Gandi pour qu'il me change le numéro de série SOA à une valeur > à  2010072800...

Sinon il ne me reste plus qu'a attendre l'expiration de la zone DNS, c'est à dire presque... 6 semaines !!! Heureusement que je ne vie pas de ce blog :) . Une autre solution serait de gérer moi même mon propre serveur DNS (c'est possible en mode expert sur les VPS Gandi), mais je n'ai pas vraiment le couple temps/envie de m'en occuper.

L'erreur que j'ai faite est de ne pas avoir modifier la zone DNS chez iWeb avant de clôturer mon compte... Cette aventure est quand même une bonne leçon à retenir pour les administrateurs de domaines DNS (par exemple pour ceux qui doivent installer un BIND): respecter les standards de numérotation des serials SOA !

Update (j+9): Comme le signale Pascal dans son commentaire le serial SOA n'est utile que pour la réplication des zones entre le serveur primaire et le/les serveurs secondaires. Ce sont les TTL des RR qui fixent le temps de rafraîchissement des caches DNS (hébergé chez les FAI). Manifestement les serveurs de caches DNS de Free ne tiennent pas compte de ces TTL (fixés à 48h pour le domaine nicolargo.com) ou sont tout simplement bugués...

Update (j+10): Je n'arrive malheureusement pas à avoir une réaction de la part du support de Free, il me dise que la mise à jour des caches se fait de manière automatique (je veux bien les croire sur ce point...) et qu'ils ne peuvent pas intervenir. Bref 10 jours après la migration, certain utilisateur ne peuvent toujours pas accéder au blog. Si quelqu'un connait un administrateur réseau chez Free je suis preneur !!!!

Update (j+11): Tout semble enfin être rentré dans l'ordre. Les DNS de Free sont enfin à jour. Le blog est donc accessible depuis l'ensemble des lecteurs. Si ce n'est pas le cas, c'est plus un problème de cache local de votre navigateur Web (d'un autre coté vous ne pouvez pas lire ce message :) ).

  • http://jve.linuxwall.info Julien

    linuxwall.info doit tourner depuis environ 5 ans avec un bind au fond d’un placard sur une freebox (non en fait, y’en a deux) et jamais eu de soucis.
    faire tourner son domaine soit meme, c’est l’une des choses les plus simples a faire, car en mettant un TTL eleve, on survole les timeouts de quelques heures/jours sans coupure de service.
    Bon, ca reste de l’amateurisme mais ca marche :)

    Un peu de lecture ? la conf de bind pour linuxwall.info: http://wiki.linuxwall.info/doku.php/fr:ressources:dossiers:dns_bind9

  • Pingback: Tweets that mention De l’utilité de gérer des serials DNS standards -- Topsy.com

  • mikala

    Gandi ne propose pas une interface « avancée » où il est possible de spécifier l’ensemble des paramètres d’une zone dns ? (sauf si c’est reinstreint à la partie situé àprès le SOA :/)

  • http://www.nicolargo.com NicoLargo

    @mikala: le mode “avancée” permet seulement de modifier “à la mimine” les enregistrements mais pas les SOA… #fail

  • http://www.web4all.fr Aurélien PONCINI

    Bonjour,
    même si il n’y a pas de norme à proprement parlé, il est tout de même dommage que Gandi ne génère pas le serial tel que 95% des utilisateurs le font.

  • Steve Bellemère

    Mais alors qui a raison dans sa manière de générer les numéros de série? Gandi ou iWeb8?

  • http://www.nicolargo.com NicoLargo

    @Steve Belemère: iWeb8 puisqu’il respecte les préconisations…

  • http://www.gandi.net/ pascal

    Bonjour,

    Le champ serial de la SOA ne sert qu’aux transferts de zone vers des serveurs esclaves — la RFC recommande (mais n’impose pas) un format YYYYMMDDXX principalement pour éviter les erreurs de saisie.

    Comme c’est un ordinateur qui génère ces zones, et que personne ne fait d’AXFR sur a/b/c, nous avons choisi de laisser le timestamp unix de dernière modification sans plus de fioritures.

    Un cache DNS, par contre, doit respecter les TTL des RRs, favoriser les informations d’autorité contre celles de son cache, et les RR NS au point de delegation com->nicolargo.com ont un TTL de 2 jours max. A ma connaissance, le cache aurait déjà du oublier les anciens NS (relus chez .com), et il devrait ignorer royalement le serial de la SOA!

    Sauf un cache buggé chez free, votre problème devrait donc être résolu. Peut-être que l’opérateur force la durée de vie des RR en cache au delà du TTL mentionné par l’autorité, en ignorant la RFC pour des raisons de charge/coûts.

    Vous n’attendrez dans ce cas pas 6 semaines (le champ expire sert à indiquer aux esclaves quand expirer une zone lorsque l’AXFR n’a toujours pas pu s’effectuer, et n’a pas d’incidence sur les caches), mais la durée configurée sur les caches.

    J’éspère ne pas avoir dit trop de bêtises (de tete, c’est parfois dur) et avoir pu vous aider à faire corriger ce problème! Il serait fortement anormal que cette propagation dure plus d’une semaine.

  • http://www.alamga.be angevoyageur

    Bonjour,
    Je ne suis pas un spécialiste DNS mais il me semble que votre raisonnement n’est pas juste.
    Il n’y a pas de recommandation ou de standard pour définir serial mais une simple convention. Serial est utilisé par le(s) serveur(s) secondaire pour éventuellement se synchroniser sur le serveur principal d’une zone.
    Le domaine nicolargo.com a 3 serveurs dns ‘authoritative’, après vérification les 3 serveurs sont bien à jour.
    Le fait que certains reçoivent une mauvaise réponse, vient plutôt selon moi d’une mauvaise gestion du cache (ttl trop long ?) sur un (au moins) des serveurs DNS utilisé par les clients de chez Free.
    Quoi qu’il en soit je suis bien intéressé de connaître le fin mot de l’histoire.

  • http://www.pingouin-barbu.info DecIRC

    Dès qu’on pense, ne fut-ce qu’au fond de sa tête à une migration, même si on n’est pas sur de le faire, la première chose que je fais c’est réduire le TTL pour prévoir ce genre d’incidents….
    Cela aide souvent…

  • http://linux-live-cd.org Boyquotes

    Bonjour,

    Certaines version du clicodrome “Plesk” confiurer le serial comme ça ( sans suivre les recommendations faites sur le net) aussi.

    Dans les dernières versions, il y a donc une case à cocher pour passer au format YYYYMMDDXX

    On s’en ai servi pour une migration de nom de domaine qui ne se rafraichissait pas à cause de ça.

    Si ça peu aiguiller certains qui se trouveraient un jour dans cette situation…

    Sinon le coup du TTL bas avant migration et une bonne chose effectivement.

    Bonne journée.
    Nicolas.

  • Koilito

    Je suis chez Free et il aura fallu attendre aujourd’hui pour ne plus avoir le message “ThisAccount has been suspended”….
    Obligé de passer par les pages “cache” de google pour voir ce qui se passait sur le blog…
    M’enfin tout est reparti ! Ouf !
    Merci pour ce blog très instructif.

  • mistur

    le serial de gandi est la date en second depuis EPOCH :

    http://fr.wikipedia.org/wiki/Epoch

    ~$ date -d “@1282917455″
    vendredi 27 août 2010, 15:57:35 (UTC+0200)

    ce qui doit être la date de la dernière modification de la zone

  • Xavier Nicollet

    Bonjour,

    il me semble que les TTL dont vous attendiez l’expiration n’était pas seulement celui des serveurs faisant autorité, anciens ou nouveaux:
    – ceux de l’ancien hébergeur,
    – ceux de gandi.
    Il faut aussi que la délégation se fasse bien, et se sont les serveurs des gTLD qui répondent.

    En clair, si les serveurs faisant autorité pour .com indiquent que nicolargo.com est gèré par:
    – ns1.ancienhebergeur.com
    et
    – ns2.ancienhebergeur.com
    et que vous n’avez pas modifié les réponses chez l’ancien hébergeur, il faudra attendre un petit moment, quels que soient vos TTL chez gandi.

    dig +trace nicolargo.com vous permet de bien visualiser tout ça.

    dig -t any nicolargo.com @f.gtld-servers.net.
    /…/
    ;; AUTHORITY SECTION:
    nicolargo.com. 172800 IN NS a.dns.gandi.net.
    /…/

    Soit une attente de 48heures, puis éventuellement, dans le pire des cas, l’attente de l’ancien TTL de la zone.

    Il est peu problable que les dns de free soient particulièrement “menteurs”, ou cachant trop.

  • http://blogmotion.fr/ Mr Xhark (Blogmotion.fr)

    Ca marche depuis FreeWifi ;)