Search Again:

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




Messages In This Thread:



Return to Digital Point Solutions' Home Page