Let’s talk about DNS. DNS seems to be one of the mysterious issues for people working on their MCSE I have noticed. It may be due to a lack of experience as generally once you have your DNS server set up it requires very little maintenance thanks to dynamic updates. Or it may be to DNS being considered more along the networking path than the server path so candidates probably just scratch their head and wonder why they’re are looking at this stuff. Or it may be they even consider it just flat out boring. I personally have always had a fascination with names so working with a sometimes arcane system for name management is great fun for me. There are a number of concepts that you should understand first for delving into DNS management.
Microsoft makes things easier on you for actual management. In managing DNS there is a layer of abstraction between you and the server through the mmc GUI that Microsoft provides. A good exercise that I believe all admins should go through at least once is setting up a BIND server for DNS on a Linux machine. Writing out zone files by hand will give you a greater understanding of what goes into a DNS zone. Every zone is composed of a number of records. Let’s look at some of the common ones.
A records – These are the basic records that resolve a name to an ip address i.e. cloud.shinra.inc to 192.168.1.2.
NS records – These contain the DNS servers that are authoritative for this particular zone. Every zone will have at least one NS record.
MX records – These are used for routing mail to SMTP servers in your domain. They can be given weights so that you can specify an order in which these SMTP servers are approached.
PTR records – These are used in a reverse look up zone. As one would guess they map a particular ip address to its respective A record.
SRV records – These are used for locating services within a domain. They can be used for locating DCs or GCs for instance. If these break your AD will be in for a rough time.
SOA records – This is your Start Of Authority record. This points to the primary authority of the zone which is normally the server that created it and is used for revision control.
All of these records are organized into zones. There are several types of zones that you can create. A primary zone is a writable copy that is stored on that particular DNS server. shinra.inc would be an example of a primary zone that I created on cloud when I first set up the AD. You can have multiple DNS servers set up with copies of a primary zone. Then you have secondary zones. These are non-writable copies of a primary zone. They retrieve their copies and updates throne zone transfers from a DNS server with the primary zone. Then there are stub zones which are very useful in managing a DNS structure spread across volatile domains. But before we talk about that more let’s talk about zone delegations first.
A zone delegation would be something created to pass authority for a subdomain to a different DNS server. Let’s say we are setting up the subdomain lab.shinra.inc. We want to grant the lab some autonomy from our structure so we create a delegation for the subdomain to pass control to the lab subdomain’s administrator. In a delegation there is solely an NS record pointing to their primary DNS server and a glue A record containing the ip address of the DNS server. All the rest of the contents of the zone are stored and managed by lab’s DNS servers. So here is how a request would work if a computer in shinra.inc did an nslookup on experiment.lab.shinra.inc. The request would hit cloud.shinra.inc which would determine that lab is a subdomain of shinra.inc. Looking in the lab zone it would find the NS record for lab’s DNS server and the A resource. The request would get passed on to ns.lab.shinra.inc which would then check it’s zone and return the ip for experiment.lab.shinra.inc. But what if the lab environment was in flux? That would be a management pain as we would be constantly updating the delegation’s records for the zone so that queries do not break. This is where stub zones come into play.
A stub zone works like a delegation that has been beefed up. Instead of one NS record is contains NS records for each DNS server in that zone, as well as the corresponding glue A record. It also contains the SOA record from the zone so that it queries the master server of that zone at regular intervals to update its list of records. This way you can add and move around DNS servers more easily as long as your server can still contact the server specified in the SOA, which can also be updated. Do note that stub zones are a read only copy so if they ever fall out of scope you would need to recreate them. Not that this is difficult to do. So how do you know when to use a delegation or a stub zone? That depends upon your goals. Both types allow the subdomain complete control over their DNS environment. Delegations will eliminate zone transfer traffic. Stub zones will keep current with DNS servers in the subdomain through zone transfers. This means you will need to evaluate if the domain will be changing frequently or not.
Now there are two flavors that zones come in, forward lookup and reverse lookup. Shinra.inc is an example of a forward lookup zone, while 0.60.10.in-addr.arpa would be an example of a reverse lookup for 10.60.0.x. The PTR records are stored in the reverse lookup zone. Reverse lookup zones are not necessary for a healthy AD environment, but they are highly recommended. They make troubleshooting easier for your help desk, plus some applications may rely on reverse lookups. For instance some mail servers may do a reverse lookup on your SMTP server and will reject mail from it if they do not find a valid PTR record for your server.
One final zone to remember is the _msdcs zone. This is a special zone that is treated as a subdomain of your AD domain i.e. _msdcs.shinra.inc. This provides the bulk of the functionality required for a healthy AD. You will find all of your SRV locator records in here. Take a look at the second paragraph of this earlier post for some more information on how this is used.
Now that you have an understanding of how DNS works we will move on to managing DNS on your Core installation. Look for that post coming up soon. In the meanwhile here is some extra reading to beef up your DNS knowledge: