[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