Differences between current version and revision by previous author of ResourceRecord.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 14 | Last edited on Tuesday, January 2, 2007 10:33:27 pm | by LawrenceDoliveiro | |
| Older page: | version 10 | Last edited on Sunday, November 28, 2004 11:38:44 am | by AristotlePagaltzis | Revert |
@@ -82,9 +82,9 @@
Also, the host name (<tt>mail.foo.com</tt> in the example) __MUST__ have an <tt>A</tt> record, __NOT__ a <tt>CNAME</tt> record.
__<tt>NS</tt>__:
- Authoritative
NameServer for a
domain. Specified in RFC:1035.
+ In the initial part of a ZoneFile, indicates the
NameServer~s which are [authoritative|AuthoritativeNameServer]
for this
domain. Elsewhere, indicates that a [subdomain|DomainName] is being [delegated|Delegation] to another set of NameServer~s
. Specified in RFC:1035.
__<tt>PTR</tt>__:
A pointer. Used for a ReverseLookup. Specified in RFC:1035. Example:
<verbatim>
@@ -106,21 +106,23 @@
</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).
Neg TTL::
Defines the number of seconds that a client should remember that a negative response was received from this server. So, if a remote server asks us what the address for <tt>foo.ethernal.tla</tt> is but it doesn't exist, it will cache the negative answer we gave it for this many seconds, even if we add that name to the zone a couple of seconds later.
+
+__<tt>[SRV]</tt>__
__<tt>TXT</tt>__:
Up to 255 bytes of arbitrary binary data. Specified in RFC:1035.
A more comprehensive list of ResourceRecord~s is at: http://www.dns.net/dnsrd/rr.html
----
CategoryDns
