• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Best Practices

The following are a series of general rules to follow when working with DNS:

  • Never create more than one CNAME record for an individual A record. It is best to use CNAME records as sparingly as possible, especially in the context of Dynamic DNS. There is no mechanism that will keep conflicts from arising if a machine registers a name in an A record that is already being used by another CNAME record.

  • No resource record should ever point to a CNAME record. For example, I wouldn't create a CNAME record called mail and point an MX record at mail.shazbot.com. Most resource records that point at other records should only be pointing at A records. This ensures that things will only be as complex as you can handle.

  • Build fault-tolerance into your DNS architecture. Make sure that every zone has at least one secondary server, even if that server is a non-Windows 2000 server in your ISP's network.

  • Seriously consider name-resolution traffic flow and determine how best to use caching servers to reduce both traffic and the time a name resolution takes to complete.

  • Pay attention to SOA serial numbers on your master and slave servers. The difference in the serial numbers in the zone files on each will tell you how well the slave servers are doing at keeping up. Never change the serial number in the primary zone file to a lower number. If you do so, the slaves will never update again unless you change theirs to an even lower number. Use the serial number on the primary to force full (AXFR) zone transfers if you are worried about slaves only partially updating.

  • Active Directory-integrated zones can make life a lot easier. Redundancy and fault-tolerance are built into AD and should be well-leveraged by a DNS administrator. Let your Domain Controllers wear the name of server hats. The only exception to this rule would be servers that sit on the outside of your firewall. It is best to use a non-Domain Controller that is a secondary server in that role.

  • Get out there and use the extensive DNS resources that exist on the Internet. Newsgroups, FAQs, RFCs, tutorials, and other documentation are abundant and a balm to the DNS administrator's weary brain. A good place to start is http://www.dns.net/dnsrd/, which is a clearinghouse for DNS-related resources.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint