configuration serveur DNS société connue

[e-kiwi]

Bonjour,

voici la configuration d'un de nos domaines chez une grosse société francaise :

configuration DNS actuelle du domaine chez xxx , dumpé avec un nslookup en mode SOA :

notredomaine.fr
origin = ns0.xxxxx
mail addr = hostmaster.xxxxx
serial = 2008072300
refresh = 14400
retry = 7200
expire = 5184000
minimum = 159200

Rafraichissement : 4heures ( la limite, correct)
Temps minimum entre 2 visites de serveurs DNS : 44h (159200 / 3600)


Ce qui signifie que si un serveur DNS vient de requeter le serveur autoritaire de la société il y a 10h par exemple ne reviendra pas avant 32h.

Avec une autre configuration, par exemple un rafraichissement défini 1h et un temps minimum entre 2 visites de 3mn, la propagation aurait été mondiale en 1h02 maximum.

vous êtes d accord avec moi ? je me trompes quelquepart

Merci !!

[jcaron]

Les valeurs présentes dans le SOA ne dictent que le comportement des serveurs de noms secondaires pour cette zone (et encore, sans tenir compte des choses plus "modernes" qui permettent une mise à jour instantanée maintenant).

Ce qui affecte le comportement des resolvers (clients et serveurs intermédiaires) c'est le TTL sur l'enregistrement final et éventuellement sur ceux des enregistrements "sur le chemin" (NS notamment).

Le TTL c'est le champ (facultatif) entre le nom et le "IN" dans un enregistrement classique. Sa valeur par défaut peut aussi être définie pour un fichier complet avec la directive $TTL.

Jacques.

[e-kiwi]

mon raisonnement est don incorrect ? (sur la délai du refresh / temps de visite) car j'ai un autre domaine avec un refresh d'une heure et un temps minimum de 3mn et j'ai bien eu les modifications en 1heures.

[jcaron]

Quand un client veut l'adresse qui va avec un nom, il se passe ça:
- il cherche dans son cache local
- s'il trouve, il vérifie que l'âge est inférieur au TTL, si c'est le cas il a fini
- s'il ne trouve pas, il va demander à l'un des serveurs configurés
- même raisonnement, éventuellement plusieurs fois si on a une hiéarchie de caches
- si toujours pas trouvé une entrée en cache valide, le serveur va faire une recherche récursive pour trouver le résultat, en partant de . (la zone "racine" de l'arbre DNS), où il va faire le même genre de vérifications à chaque niveau, et suivre les branches de l'arbre jusqu'à destination
- au bout du compte, il va interroger l'un des serveurs DNS listés pour la zone

Quand tu fais une modif, il faut donc que:
- la modif soit transmise du primaire au(x) secondaire(s): ce sont les champs du SOA qui vont dicter à quel rythme le(s) secondaire(s) vont venir interroger le primaire pour obtenir la nouvelle zone (sauf s'ils utilisent les méchanismes plus récents qui leur permettent d'être informés des modifs dès qu'elles interviennent)
- les caches du client et des serveurs sur le chemin aient décidé que ton entrée a expiré et qu'il faut aller chercher la nouvelle valeur: c'est le TTL de l'enregistrement qui dicte ce résultat (et le fait que l'enregistrement soit effectivement déjà en cache ou pas).

Donc si tu fais une modif et que ton TTL est de 24 heures, tous ceux qui l'on déjà en cache vont garder l'ancienne valeur pendant 24 heures (modulo tout plein de paramètres: ils ne retiennent pas forcément tout, c'est un cache, hein, et certains ignorent plus ou moins les TTL, ou on des valeurs min/max), quelle que soit la valeur des champs du SOA.

Mais inversement, si tu as un TTL faible sur l'enregistrement modifié (avant sa modif, évidemment), si jamais les serveurs DNS utilisent la mise à jour "traditionnelle" basée sur le SOA, et que c'est un secondaire qui est interrogé, si tu as des valeurs extrêmement longues dans ton SOA tu cours le risque que le secondaire renvoie l'ancienne valeur.

Jacques.

[e-kiwi]

Ok, le raisonnement est finalement juste alors, la configuration de ce serveur autoritaire est donc bien le frein à la rapidité de le mise à jour(récursive) des différents caches DNS.

[Bool]

Bah déjà, quelle est la valeur du "TTL" sur l'enregistrement qui t'intéresse ?

[e-kiwi]

je ne comprend pas ta question, quelle est la différence avec la valeur "minimum" que je donne ?

[Bool]

Comme jcaron t'a (longuement) expliqué ces deux valeurs n'ont rien à voir...

Le TTL est la seule valeur qui intervient pour les caches.
Utilise dig pour interroger ton serveur DNS, la valeur de TTL sera indiquée.

Celle du SOA ne sert (servait ?) qu'à la synchronisation des DNS secondaires ; pas pour les clients ou les caches.

[e-kiwi]

ah oui scuse, je suis allé trop vite. le TTL est maintenant de 1h

[Bool]

Et donc, où est le soucis si le délai était déjà à 1H ?

[e-kiwi]

>> ces deux valeurs n'ont rien à voir...

ah non, il dit juste que l'on interroge le secondaire et qu'il n'est pas forcement à jour car il utilise le retry (donc de 4h là) pour se mettre à jour,

mais minumum = defaut TTl = avant 44h, et là on a fait changé à 1h, qui sera donc à jour dans max 5h, le 1h + 4h de retry.

mais dans sa réponse, il ne dit pas que le minimum est autre chose que le TTL defaut. dailleurs tu fais la commande sous linux ou sous windows, l'un te sort "defaut ttl" et l'autre "minumum"

[Bool]

Certains vieux softs DNS auraient attendu les 4h oui... mais vérifie : interroge directement tes serveurs principaux et secondaires, il y a de très bonnes chances pour qu'ils se soient mis à jour en même temps, comme c'est généralement le cas avec les softs actuels.

Le "minimum TTL" n'est plus utilisé dans ce sens depuis Bind 9 : source

RFC 2308 (implemented by BIND 9) redefined this value to be the negative caching time - the time a NAME ERROR = NXDOMAIN record is cached. The maximum value allowed by BIND 9 for this parameter is 3 hours (10800 seconds). This value was (in BIND 4 and 8 ) used by any RR from the zone that did not specify an explicit TTL i.e. the zone default TTL. BIND 9 uses the $TTL directive as the zone default TTL (and which was also standarized in RFC 2308). You may find older documentation or zone file configurations which reflect the old usage (there there are still a lot of BIND 4 sites operational).

Sur mes domaines cette valeur est configurée à 38400, et pourtant quand tu interroges avec "dig" c'est bien 3600 (la valeur de mon $TTL) qui est indiquée.

[e-kiwi]

j'ai intérrogé mes serveurs, c'est pour ça que je dis ça. on a la moitié des internautes qui sont sur la nouvelle IP, et l'autre moitié bloqués sur l'ancienne... enfin bon maintenant c'est trop tard, on a dépassé la période ^^ et bizaremment chez eux ils ont modifié le 44h en 1h pour notre zone DNS suite à l histoire, donc je suppose que ce n'etait pas tout a fait si propre que ça