|
|
 |  |
Re: Question about secondary zone updates...From: Len Conrad Date: Sunday, September 9, 2001
Time: 2:57:41 am
>I was under the understanding that the REFRESH parameter (field 2) set t=
he
>time between updates,
> and the RETRY parameter (field 3) set the time delay
>between update retries,
between failures to reach the master.
> until the zones were aligned. None of this meant
>anything though until the SERIAL number (field 1) on the Primary zone ha=
d
>been incremented. After the SERIAL number is incremented
... the master will send a NOTIFY packet to all NS records in the zone.
>, then at the next
>Refresh, the secondary would look to the authorative primary for changes=
,
>and if the SERIAL is found changed and greater, start a zone transfer. T=
he
>NOTIFY just forces this behaviour but the secondary DNS still needs to
>verify that the SERIAL number has changed.
yep
>Is it possible that your SERIAL number on the primary zone is not
>imcrementing, and thus not forcing the zone transfer.
yep
>I just checked these figures, and need to know if these are standard acr=
oss
>all platforms and implementations (ie RFC based standards)
>Refresh - 3hours (10800), Retry - 60mins (3600)
I=B4d go with 900
>Expire - 3days (259200),
"expire zone" 7 to 10 days.
>MinTTL - 60mins (3600)
The last field in the SOA is now "negative TTL", and I think the max is 1=
0800.
>and TTL - 60mins (3600)
$TTL is now required before the SOA (at zone top) and is the default TTL=20
for all records not having an explicit TTL value.
btw, the default network class is INternet, so you can leave that "IN" of=
f all
records to simplify.
Len
___________________________________________________________________
Men & Mice: QuickDNS - DNS Expert - DNS Training - DNS Consulting
DNS Classes: Denver Sep. 20-21, NYC Sep. 27-28, Toronto Oct. 18,19
Frankfurt Nov.21-23, London Nov. 26-28, Maidenhead Oct. 31-Nov 2
http://MenAndMice.com/DNS-training
|

Return to Digital Point Solutions' Home Page |