- Mise en situation:
Au lieu de mettre le serial de la forme YYYYMMDDxx, un moment d'égarement et hop.. je suis en 2008200501.
Impossible de base de revenir en 2008090300 car ce serial qui a pourtant la forme souhaitée est inférieur au précédent.
Le serial n'etant pas incrémenté il ne sera pas pris en compte par les slaves.
L'occasion de tester la méthode suivante...
- Explication / Solution:
Les numéros peuvent aller jusqu'a 2^32 -1 soit 4 294 967 295.
Mais le chiffre après 4 294 967 295, c'est 0. (En fait il faut voir cela comme une roue).
Donc pour tout serial de départ, il y a la moitié des autres possibilités qui sont considérées comme "supérieures" et l'autre moitié "inférieures".
4 294 967 295 / 2 = 2147483647.5
Donc si j'ai mon serial à 2008200501:
De 2 008 200 502 à 4 155 684 148 -> cette nouvelle valeur sera "supérieure"
De 4 155 684 149 à 4 294 967 295 et de 0 à 2 008 200 500 -> cette nouvelle valeur sera "inférieure"
Donc avec mon 2 008 090 300 du jour, je serais inférieur..logique..(c'est bien le problème..) tout comme je le serais également avec la valeur 4 294 967 295..moins logique...
Oui, on a donc 4 155 684 148 qui est supérieur à 4 155 684 149 au sens des serials d'une zone !!
Bref en mettant mon nouveau serial à 4 155 684 148 (max) il sera pris par les slaves car supérieur... Puis en le remettant dans la foulée à 2 008 090 300 (date du jour), il sera a nouveau considéré comme supérieur et pris à nouveau en compte. Ouf.
- Divers
Extrait de la RFC 1982:
The DNS SOA serial number
The serial number in the DNS SOA Resource Record is a Serial Number
as defined above, with SERIAL_BITS being 32. That is, the serial
number is a non negative integer with values taken from the range
[0 .. 4294967295]. That is, a 32 bit unsigned integer.
The maximum defined increment is 2147483647 (2^31 - 1).
Note: Si on supprime le fichier de zone des slaves, forcément ils vont le reprendre quelquesoit le numéro.. mais on a pas toujours la main sur les slaves.. ;)
