I was wondering if there was any significance in the SOA serial value
$ date --date='@1297117089'
Tue Feb 8 00:18:09 SAST 2011
$ date --date='@1762233707'
Tue Nov 4 07:21:47 SAST 2025
...so nope (but sort of close?)
Personally - I try and use a MMDDxx format in my SOA Serial number -
Thanks, that worked perfectly!
> On Dec 17, 2020, at 12:02 PM, Reindl Harald wrote:
>
>
>
> Am 17.12.20 um 19:56 schrieb Bruce Johnson:
>> Someone updated out name server and messed up the serial number on the
>> primary; as a result our secondaries are not updating properly.
>> Primary:
>>
Bruce,
you should start by picking a policy for your serial number. Both unixtime and
datetime are viable, but you should pick one.
Then rotate to your desired policy by doing the serial number arithmetic. For
datetime, you would just bump it, but for unixtime you will need to do that in
more
The modulo arithmetic comes if you need it to be lower than in the slaves since
they will consider a lower numbered transfer to be out of date and refuse to
update. Meaning you will need to go to the top and round back to where you need
to be.
--
Best regards
Sten Carlsen
"No trees were
Suggestion I learned ages ago...
Set the serial number to match the date the change is made such as
MMDDvv (Year, month, date, version). For example: 2020121701
Of course, if you do more than 99 changes in a single day, you probably
have other problems..
On Thu, Dec 17, 2020 at 2:02 PM
Am 17.12.20 um 19:56 schrieb Bruce Johnson:
Someone updated out name server and messed up the serial number on the primary;
as a result our secondaries are not updating properly.
Primary:
bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall
+answer pharmacy.arizona.edu
Someone updated out name server and messed up the serial number on the primary;
as a result our secondaries are not updating properly.
Primary:
bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall
+answer pharmacy.arizona.edu
pharmacy.arizona.edu. 86404 IN SOA
7 matches
Mail list logo
