Differences between version 6 and revision by previous author of DNSBestPractices.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 6 | Last edited on Saturday, December 18, 2004 2:17:57 pm | by MikeMachuidel | Revert |
| Older page: | version 3 | Last edited on Sunday, November 28, 2004 11:19:54 am | by AristotlePagaltzis | Revert |
@@ -12,9 +12,9 @@
!! Expire
The expire value is how long a secondary will continue to serve information if it has been unable to contact the primary name server. Once this time has expired the server will no longer return authorative results and will be considered lame.
-A good value for this is about 1209600 (2 weeks) to 2419200 seconds (4 weeks). In general setting this too low will cause your secondary to become lame prematurely, and if your primary is down for an extended outage, you want your secondary to continue to server records, however if the secondary for some reason is unable to contact your primary you want the secondary to stop sending incorrect stale information to clients. We recommend a value of 2419200 seconds (2
weeks).
+A good value for this is about 1209600 (2 weeks) to 2419200 seconds (4 weeks). In general setting this too low will cause your secondary to become lame prematurely, and if your primary is down for an extended outage, you want your secondary to continue to server records, however if the secondary for some reason is unable to contact your primary you want the secondary to stop sending incorrect stale information to clients. We recommend a value of 2419200 seconds (4
weeks).
!! Negative cache TTL / Minimum TTL.
The last value in the SOA is the minimum ttl. This was originally what the minimum TTL is for records returned from this zone, if no ttl was specified then this value was used, hence it is sometimes incorrectly refered to as the "Default TTL" for a zone. More recent [RFC]'s suggest you use the $TTL directive for this. Most modern bind implementations will moan if a $TTL is not there.
@@ -31,9 +31,9 @@
|__Name__|__Service__
|cvs|cvs server (viewcvs available over http, pserver and ssh access)
|ftp|ftp server
|www|web server
-|mail| Smarthost for internal clients/[
MX]
+|mail| Smarthost for internal clients/MX
|MX''n''|Machine for external reception of mail
|NS''n''|Nameserver. Note that DJBDNS prefers(?) nameservers be called a.ns and b.ns
|proxy|web proxy
|[wpad|WPAD]|Proxy autodiscovery
@@ -45,10 +45,11 @@
All IP addresses that you are authorative for should be given reverse lookups, even DHCP ranges, where you can use the $GENERATE directive.
All IP's that have a reverse lookup should have a forward lookup for the same name that returns the same IP.
-!!!Names
-Remember the . at the end of the domain name. Remember [
NS]
,[
MX]
,[
CNAME]
,[
DNAME]
all require a name on the right hand side, and will not accept an IP address. Consider running a [script|http://www.wlug.org.nz/archive/validate_zones] from cron to check for blindingly obvious mistakes.
+!!! Names
+
+Remember the . at the end of the domain name. Remember that the
NS, MX, CNAME, DNAME records
all require a name on the right hand side, and will not accept an IP address. Consider running a [script|http://www.wlug.org.nz/archive/validate_zones] from cron to check for blindingly obvious mistakes.
Avoid _ / and % in names. _ for instance is valid in [DNS] but is not valid as a hostnames.
Try to give a machine the least number of names possible. While this contracts the above where you should have one name per service (since one machine often has multiple services), at least reusing the name for a service is a good idea. For instance, if you host 5 domains, have them all use "ns.example.com" as their primary nameserver.
