[gull] DNS prive & caching

Leopoldo Ghielmetti leopoldo.ghielmetti at a3.epfl.ch
Tue Aug 28 18:09:53 CEST 2007


On Tue, 2007-08-28 at 16:49 +0200, Daniel Cordey wrote:
> On Tuesday 28 August 2007, Leopoldo Ghielmetti wrote:
> 
> > Non, utiliser la date c'est décrit comme "une erreur commune", en effet
> > le numéro de série c'est un simple numéro et c'est comme ça qu'il est
> > défini. Ce n'est pas une erreur d'utiliser une date, mais les mises à
> > jour automatique des fichiers DNS (p.e. via le DHCP) vont simplement
> > incrémenter le numéro de 1 sans tenir compte de la date du jour.
> > La date est utile uniquement si on gère le fichier uniquement de façon
> > manuelle.
> 
> Ah... mais qui dit qu'il s'agit d'une erreure commune alors que je trouve 
> plein de site sur le net qui le recommande 
> (http://www.linuxjournal.com/article/6541) en precisant bien qu'il s'agit 
> d'une "convention" ?
> 
> "...
> For configuration files in /var/named/master, Hostmaster actually is the 
> e-mail address of the administrator, where the first dot replaces the at 
> symbol (@) because of syntax restrictions. In addition, the first number for 
> the IN SOA structure at the beginning of Listing 2 is the serial number 
> conventionally expressed as YYYYMMDDNN, where NN is a number incremented each 
> time the DNS zone is updated.
> ..."

Je me rappelle bien qu'il y a quelques années quand j'ai cherché des
informations la dessus il y avait spécifié que c'était mieux de ne pas
utiliser de date. Probablement il s'agit de différences dans les
différentes documentations. Comme d'hab, vu qu'il s'agit uniquement de
recommandations on y trouve du tout.

> Il y a ceux qui precisent bien qu'il suffit d'incrementer un nombre et que 
> par "convention"... et d'autres qui ne s'embarassent meme pas de ce genre de 
> consideration : c'est sous la forme YYYYMMDDXX punkt :-)
> 
> Je mentionnerai finalement "DNS and BIND (4th edition); O'Reilly" page 152, 
> qui a un paragraphe entier au sujet de l'usage du format YYYYMMDDXX et qui 
> ose meme dire :
> 
> "...It also has the advantage of leaving you an indication if the zone fileof 
> when you last incremented the serial number. h2n (Host To Nameserver; Perl 
> script) will generate the serial number drom the date if you use the -y 
> option..."
> 
> Pouvoir effectuer 99 updates d'un fichier de "zone" dans la meme journee me 
> semble suffisant. Je me suis trouve une fois dans une situation embarassante 
> avec mon serveutr DNS et mon ISP. J'ai fait une quantite de modifs dans la 
> journee, mais n'ai jamais atteind 99...

Oui, dans une journée oui, mais si ça tourne toute une année? La mise à
jour de bind depuis un serveur DHCP incrémente simplement la valeur du
serial (sans format). Donc si tu définis ton fichier le 1er janvier 2008
et tu fais 4000 mises à jour pendant l'année, le 31 décembre tu te
retrouves avec 2008014100 qui n'est pas vraiment ce que tu cherches.

> > La date est utile uniquement si on gère le fichier uniquement de façon
> > manuelle.
> 
> Ben... en tant que "master" c'est ce que je fais. J'ai donc ecrit un script 
> pour gerer mes fichiers de zone; avec le format de la date. C'est un peu plus 
> complique a ecrire que pour un simple incrementation, mais cela me dit 
> clairement quand j'ai effectue mon changement. 

Oui, mais cela suppose une mise à jour manuelle et pas automatique, même
si tu utilises des scripts ça reste manuelle, le bind met à jour ces
fichiers sans passer par des scripts et en faisant simplement +1.

> > Avant j'utilisais bien la date, mais je me suis retrouvé avec des dates
> > totalement étranges dès que j'ai activé la mise à jour automatique des
> > entrées DNS. 
> 
> Sur un slave ? Quel programme faisait la mise a jour ?

bind! Et il ne s'agit pas d'un slave mais du master (en fait il n'y a
pas de slave pour cette zone la).

> > Donc on commence avec une date et quelque mois plus tard on se trouve
> > avec quelque chose du type 2007085678 car il y a eu quelque milliers de
> > mises à jour qui ont impacté sur le jour.
> 
> Sauf que YYYY -> annee
> 	MM -> mois
> 	DD -> Jour
> 	XX -> libre (0 -> 99)
> 
> Donc, meme le lendemain, on a de nouveau 99 chiffre a dispo. 

Oui, mais pas après des mois de fonctionnement, 99 ne suffisent
peut-être pas.

> J'ai aussi adhere a cette convention car il s'agissait d'une demande de mon 
> fournisseur d'acces internet.

ça c'est une question d'habitude, moi je n'y vois pas de raison et vu
que ça génère de la confusion (sauf si on met à jour manuellement, chose
que je ne fais pas) je préfère laisser le serveur bind s'organiser tout
seul et donc je laisse un serial numérique.

> dc

ciao, Leo





More information about the gull mailing list