J’ai un doute sur le temps max que je dois attendre pour être sûr qu’une zone soit bien propagée jusqu’à un dns FAI éloigné de mes serveurs dns:
Lequel des délais entre expire, retry, refresh le fai va t il attendre au max avant de se mettre à jour ?
Un certain temps 
qui dépend du TTL de chacun des serveurs traversés … et donc pas (uniquement) du paramétrage de tes serveurs dns.
Selon mon expérience, ça prend entre 5 secondes en tout et 3 heures de plus que le TTL dépendant de la modification effectuée et des états des serveurs DNS.
Vous n’avez donc pas compris ma question, mais c’est vrai qu’elle était mal posée.
Oui, bien sur, elle peut mettre un temps illimité à se propager jusqu’à un serveur, notamment par exemple, si le dit serveur est éteint, par exemple.
Je reformule donc autrement ma question:
quel paramètre d’une zone un resolver à qui on pose une question va t’il utiliser pour décider que ses données en cache sont obsolètes et qu’il doit les rafraîchir avant de répondre ?
A mon humble avis, j’ai toujours la même réponse, un seul paramètre, le TTL du domaine recherché, qui, s’il n’est pas modifié, est identique sur tous les resolvers.
Trés énervé par cette réponse qui ne correspondait pas à ce que j’avais comme vague idée du sens des différents timings du SOA, je suis RTFM (RTFRFC plutôt dans ce cas), pour trouver une citation pour te montrer que tu disais n’importe quoi.
Donc, je dis n’importe quoi:
les trois timings expire, retry, refresh, concernent les transferts entre serveurs du domaine, pas du tout pour les temps de fraicheur des resolvers qui sont ABSOLUMENT bordés par le TTL.
Je suis niais.
En effet les temps du SOA servent à la synchronisation entre les serveurs faisant autorité pour la zone, pas aux serveurs caches. Le TTL d’un enregistrement est utilisé par les serveurs caches.
Je suppose que tu parles de la modification d’une zone existante et pas d’une nouvelle zone ?
Dans le pire cas, il faut additionner le temps de refresh de la zone (si le serveur esclave n’est pas notifié par le serveur maître lors d’une modification de la zone) et l’ancien TTL de l’enregistrement considéré pour être sûr de récupérer le nouvel enregistrement sur n’importe quel serveur cache.
Oui.
Alors j’ai oublié sur quel domaine je travaillais et pourquoi j’attendais une synchro, mais je crois me souvenir que j’étais en train de règler un probléme de SPF/DKIM sur mail-tester.com qui m’indiquait une incohérence, alors que j’avais mis à jour ma zone, et qu’elle s’était parfaitement propagée selon www.whatsmydns.net
En creusant, je venais de m’apercevoir que bizarrement, un seul des deux resolver d’online était à jour, le deuxième, non. Et ça durait, aussi bien sur mail-tester qui continuait à me signaler une erreur que sur le 2e resolver online qui ne se synchronisait pas, même aprés des heures.
Du coup, j’essayais de savoir si ça venait d’une erreur de ma part qualque part, ou si c’était lié aux timings du SOA.
Et j’ai du règler le probléme puisque tout est bon maintenant.