Differences between version 13 and predecessor to the previous major change of ResourceRecord.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 13 | Last edited on Monday, May 1, 2006 10:32:29 pm | by LawrenceDoliveiro | Revert |
| Older page: | version 12 | Last edited on Monday, May 1, 2006 10:26:09 pm | by LawrenceDoliveiro | Revert |
@@ -106,11 +106,11 @@
</verbatim>
The name is given as "<tt>@</tt>", since that is the shorthand for the value of <tt>$ORIGIN</tt>. [TTL] is missing from this example, as it takes the zone default defined above as <tt>$TTL</tt>. The name-server field is basically the [FQDN] of the PrimaryNameServer for the domain (don't forget the trailing fullstop!). The email-address field is the address of the person responsible for the domain -- the first dot should be read as an <tt>@</tt>, so above should be read as <tt>root@ethernal.tla</tt>. The values in parenthesis are described below:
Serial number::
- Generally given in YYYYMMDDXX format, giving 100 possible revisions of any given zone in a day (Usually more than enough).
+ Generally given in YYYYMMDDXX format, giving 100 possible revisions of any given zone in a day (Usually more than enough). __Always remember to increment this when editing the ZoneFile__, since a change to the serial number is what triggers ZoneTransfer~s by SecondaryNameServer~s
.
Refresh::
- Defines the number of
seconds before
a SecondaryNameServer will
refresh its copy of the zone by requesting a ZoneTransfer from the PrimaryNameServer.
+ Defines the interval in
seconds between checks by
a SecondaryNameServer as to whether the serial number has changed. When a change is detected, this means it needs to
refresh its copy of the zone by requesting a ZoneTransfer from the PrimaryNameServer.
Retry::
Defines the number of seconds for a SecondaryNameServer to wait before retrying a zone refresh, after a failure.
Expire::
Defines the number of seconds for a SecondaryNameServer to keep zone records, and answer authoritatively with them if it can't contact the PrimaryNameServer. (so, if the above refresh fails, and it's been retrying for this long).
