Differences between current version and revision by previous author of DNSBestPractices.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 9 | Last edited on Friday, July 1, 2005 12:19:44 am | by NickAndrew | |
| Older page: | version 8 | Last edited on Friday, May 20, 2005 10:26:11 am | by DanielLawson | Revert |
@@ -10,14 +10,14 @@
!! Retry
The retry value is how often secondaries will try again if a refresh failed. Values in about 120s to 7200s are reasonable. Depending on how important it is that your information is correct and up to date, I'd recommend either 600 (10 minutes) or 3600 (1 hour).
!! 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.
+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 authoritative
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 (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.
+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 referred
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.
Most modern DNS implementations are willing to give out replies with the TTL being lower than this value so it's use as it was originally defined is no longer that important.
However, name servers that support caching [NXDOMAIN] will use this value as the amount of time they will cache the result for. Hence it being called the "Negative cache TTL".
@@ -41,9 +41,9 @@
|imap
|news| news server
|dhcp-''n''|[DHCP] assigned leases
-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 addresses that you are authoritative
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
@@ -55,20 +55,20 @@
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.
Try and add [SPF] records for as many names as possible. In particular if a domain will never send mail set it's SPF to
foo.example.com IN TXT "v=spf1 -all"
-so that noone
will ever accept mail that claims to be from that domain.
+so that no-one
will ever accept mail that claims to be from that domain.
-!!!Authorative
nameservers
-If you are running a nameserver in authorative
mode, avoid using it as a nameserver for stub resolvers. (ie
, don't allow recursion for any host through it). This avoids problems where the nameserver configuration is out of date, and prevents issues with people intentionally (or unintentionally) poisoning your authorative
nameserver.
+!!!Authoritative
nameservers
+If you are running a nameserver in authoritative
mode, avoid using it as a nameserver for stub resolvers. (i.e
, don't allow recursion for any host through it). This avoids problems where the nameserver configuration is out of date, and prevents issues with people intentionally (or unintentionally) poisoning your authoritative
nameserver.
For best performance out of a DNS server, try and use one name for it. ie, call your nameserver "ns1.example.com" in ALL of your zones. Also try to make sure that TTL's for the NS records, and A records on your nameserver, and any other related glue are at least 432000 seconds (5 days). This makes sure that if anything goes wrong higher up in the heirachy, your customers can still get to your site for approximately 2 days giving you time to get the issue fixed. Since queries will still flow directly to your nameserver, you will be able to return other names (such as "www") directly even if the higher up zones are having issues.
-You may want to use the same idea for MX records. Beaware
that these make it difficult to migrate nameservers in the future, so remember to turn your TTL's down later.
+You may want to use the same idea for MX records. Be aware
that these make it difficult to migrate nameservers in the future, so remember to turn your TTL's down later.
-If you want to check to see if a server thinks it's authorative
for a zone, simply do
+If you want to check to see if a server thinks it's authoritative
for a zone, simply do
dig +norecurse -t ns domain.tld @nameserver
-If the flags line in the header of the output contains 'aa' (for authorative
answer), then the nameserver is authorative
for that domain.
+If the flags line in the header of the output contains 'aa' (for authoritative
answer), then the nameserver is authoritative
for that domain.
!!!Caching nameservers
For nameservers that are supposed to handle recursive lookups for stub resolvers, limit the IP ranges that can issue requests aggressively. People who can do recursive queries through your nameservers can end up with bad entries being cached.
