Bonjour,
Nous utilisons SDNS2 depuis 2003 comme secondaire pour certains domaines hébergés sur nos serveurs dédiés. Si à l'époque la mise à jour des DNS se faisaient deux fois par jour (de mémoire à midi et à minuit) aujourd'hui la fréquence est plus élevée.
Pour autant elle reste insuffisante, notamment pour le module Plesk de Let's Encrypt, et ce quelque soit les paramètres SOA des domaines que nous gérons (généralement nous descendons le refresh à 10 mn).
En effet, nous estimation basée sur des dizaines de tests démontrer que la mise à jour des enregistrements DNS sur sdns2.ovh.net peuvent nécessiter jusqu'à 3H. Ce qui est trop long, dans la plupart des cas pour Let's Encrypt.
Cordialement,
Eric.
Themen: Performance optimisation
39169 
18.11.2016 09:53
Salut,
Donc tu héberges toi même le primaire ? Et dans ce cas Certbot ou autre devrait prendre en compte celui-ci non ?
Tout à fait et cela ne devrait poser aucun pb au Certbot, sauf que ce n'est pas le cas.
Je précise qu'on gère quelques centaines de domaines de domaines depuis des années dont un peu moins de 200 en prod nécessitant un certificat SSL à jour.
On constate de gros soucis depuis quelques mois, sans doute lié à une modification des tests de Let's encrypt. En tout cas cela la faible réactivité de SDNS2 (légendaire) était gérable avant. Ce n'est plus le cas.
Et visiblement OVH s'en fiche.
Bonjour,
Spoiler : au niveau DNS il n'y a pas vraiment de nation de "primaire" et "secondaire" (pour ça qu'il n'y a pas de système de poids comme sur les MX), le premier qui répond gagne.
De plus Let's Encrypt fait une validation multiple, il vérifie que le challenge est validé par plusieurs endpoint (exemple à la con par un robot chez un provider en amérique et un second en europe chez un autre provider).
Dans les logs vous voyez bien votre serveur envoyer les requêtes de MàJ vers SDNS2 ?
Aussi techniquement le refresh dans le SOA devrait être entre "1200 et 43200" (RFC 1912), mais normalement cela ne devrait pas avoir d'incidence car si vous faite une modification cela devrait envoyer un signale "NOTIFY" à SDNS2 pour faire du IXFR/AXFR. Et de mémoire sur bind9 le message part dès que le "master" observe un changement de serial et recharge la zone.
Et en dernier recours il y a des services comme : https://ns-global.zone/ & https://freedns.afraid.org/
Cordialement, janus57
" Et de mémoire sur bind9 le message part dès que le "master" observe un changement de serial et recharge la zone "
Oui sauf que sur sdns2.ovh.net c'est pas "dès que", c'est "quand il veut bien", et c'est pénible.
J'ai fais une modif sur une zone du "Maître" à 10h ce matin et sur une autre zone vers 11h : première requête de transfert AXFR de sdns2 à 13h30, bon là ça va, c'est raisonnable même si on aimerait un peu plus de réactivité. Il est 15h55 et j'attends toujours la deuxième requête et j'ai un site est en rade parceque let's encrypt interroge toujours sdns2, et impossible d'utiliser l'ancien certificat de l'ancien hébergement.
La dernière fois que j'ai eu un besoin urgent de réactivité du sdns2 je crois que la requête s'est faite en pleine nuit 15h après le notify.
Alors je sais que la RFC dit que le slave a 24h pour faire sa requête après le notify, mais on est en 2025, et tout le monde veut du tout tout le temps tout de suite, en particulier les clients, et je ne fais pas exception.
Un petit peu plus de réactivité serait le bienvenue. Des utilisateurs de ns-global pour témoigner ?
J'ai quitté afraid.org il y a quelques années, et je ne sais même plus pourquoi, mais je sais que j'avais une bonne raison.
Je suis d'accord, c'est "quand il veut bien". Et d'ailleurs, le support OVH m'a répondu : ils sont conscients du problème et n'ont pas prévu de le résoudre (!)
Du coup, de rage, on a créé un serveur DNS dédié sur une un petit VPS chez un concurrent : comme ça on aura la réactivité et l'assurance d'avoir des DNS up en cas de défaillance DNS chez OVH (de mémoire, c'est arrivé une fois vers 2017-2018 lors d'une mise à jour de leurs routeurs Cisco).
Et concernant mon utilisation un peu abusive des termes Primaires et Secondaires au lieu de Master et Slave, par le passé, même pour les domaines qui utilisaient déjà les DNS de nos serveurs dédiés on avait une répartition 55-45 sur les résolutions DNS. ;-)
Ah oui, c'est pas bête ça, un petit VPS qui ne remplit que cette fonction, je vais l'envisager aussi. Au moins on maîtrise le délai du transfert.
Oui, avant on croisait les services DNS entre nos différents serveurs de prod mais cela obligeait d'installer les domaines via nos panels sur le serveur qui servait de slave. C'était beaucoup d'effort pour pas grand chose. Maintenant, on a juste à ajouter les domaines en slaves depuis le panel de la VPS.