Home » Posts tagged 'DNS'

Tag Archives: DNS

Advertisements

Quick review of flushdns, registerdns, and DNS queries

There seems to be a bit of a misconception on how DNS cache flushing works. I’ve heard techs talking about running ipconfig /flushdns and ipconfig /registerdns to flush the DNS cache. It looks like there needs to be a bit of clarification on how these commands work:

ipconfig /flushdns: “Flushes and resets the contents of the DNS client resolver cache. During DNS troubleshooting, you can use this procedure to discard negative cache entries from the cache, as well as any other entries that have been added dynamically”

ipconfig /registerdns: “Initiates manual dynamic registration for the DNS names and IP addresses that are configured at a computer. You can use this parameter to troubleshoot a failed DNS name registration or resolve a dynamic update problem between a client and the DNS server without rebooting the client computer. The DNS settings in the advanced properties of the TCP/IP protocol determine which names are registered in DNS.”

Now as you can see from the above documentation that the parameters operate independently. You would only issue a /registerdns parameter in cases where the client system’s name is not being resolved. There is no requirement to run it with the /flushdns parameter.

Something that you may find of interest is that there is also a parameter to show the contents of the DNS cache. ipconfig /displaydns will print out in the terminal window the entire contents of the DNS cache. You can verify from there whether it truly has the correct address for whatever you’re having issues resolving or not.

A quick refresher on how name resolution works. First the name is submitted for DNS resolution. The system checks to see if the name is a FQDN, single label or multi label. This is determined by the dots within the name i.e. http://www.microsoft.com. is an FQDN while http://www.microsoft.com is a multi label and just www is a single label. Note the terminating period on the FQDN and the lack of a terminating period on the multi label name. Let’s first check how resolution works for an FQDN:

1.       Checks DNS cache (this is built from previous DNS queries and the hosts file, hosts file always win)

2.       Queries primary DNS server

3.       If no response in two seconds it queries all remaining DNS servers

4.       Resends queries to all servers at the four and eight second marks

5.       Returns time outs for all queries after thirty seconds

6.       Query is evaluated on whether it is 15 bytes or less

7.       If less then query is submitted for NetBIOS resolution

8.       Query finally fails if no resolution has been achieved

Now if a multi label name was submitted such as http://www.microsoft.com (note the lack of a terminating period) then the resolver terminates it with a period to make it an FQDN and submits it to the same resolution list as above, with a slight difference:

1.       Checks DNS cache (this is built from previous DNS queries and the hosts file, hosts file always win)

2.       Queries primary DNS server

3.       If no response in two seconds it queries all remaining DNS servers

4.       Resends queries to all servers at the four and eight second marks

5.       Returns time outs for all queries after thirty seconds

6.       Queries are re-issued with the connection specific DNS appended to the query

7.       Queries are then reissued devolving the parent DNS until only two labels are left

8.       Query is evaluated on whether it is 15 bytes or less

9.       If less then query is submitted for NetBIOS resolution

10.   Query finally fails if no resolution has been achieved

For a single label name the connection specific DNS is appended immediately and then it is submitted to the same resolution order as the FQDN.

For more information and flow charts look at the documentation links below.

Documentation taken from here:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ipconfig.mspx?mfr=true

http://technet.microsoft.com/en-us/library/cc961411.aspx

Advertisements

Active Directory Internal Naming and DNS Strategy

This post touches on something that is rather simple, yet I’ve seen it done improperly at many of the SMB clients that I work with by a previous provider. This has resulted in some unnecessary complexity and even migrations to a new forest to meet requirements such as for Exchange 2007 when it did not support single label domains. When you are first creating your Active Directory forest you want to put some thought into what you are naming it. You need to first think about the company’s internet facing domain names and what sort of traffic is being generated through them. This changes your DNS strategy depending upon, for instance, if the company’s website is being hosted by the company or if it is hosted by a third party. You will also need to think about where your public DNS is being served from. Another thing to throw into the mix is security, which ties into the previous issue. Let’s take a look at a few things here.

Microsoft has some best practices guidelines here. My personal preference is to go for a non-registered TLD such as .internal or .local so as to provide no confusion with TLDs such as .com or .net. Microsoft would prefer for you to go with a subdomain of your external domain i.e. corporate.contoso.com for your AD forest while using contoso.com on the internet facing side. Either way of doing it a benefit you reap is that name resolution for contoso.com is done externally. The reason for this is that while your internal DNS is authoritative for contoso.local or corporate.contoso.com it is not authoritative for contoso.com itself so it will find a server that is. This will return the internet facing IP address for whatever is in contoso.com. The reason you would want this is because, especially for the majority of SMBs that I work with, most often their website is hosted at a 3rd party provider. If your AD forest was contoso.com that would add complexity as you would have to manage internet addresses both internally and externally as you would no longer be able to forward requests to your public DNS provider. For example for the record of http://www.contoso.com if you switched 3rd party hosting providers you would need to update that A record on your public DNS. You would also need to update that record internally, otherwise the next day your client will be calling in to let you know that their website is “down.”

Now what if you were hosting your own DNS? For security you would want to put your public DNS into your DMZ serving different zones than your private DNS servers. The reason for this is to restrict public access to your internal DNS hierarchy. Access to that would give hackers a huge amount of information on your internal network such as naming conventions, internal ip addressing and even names of your DCs. Your private DNS would then forward requests for contoso.com to your public DNS and management is simplified since internal changes would not affect external changes and vice versa.

Next obstacle to face is what if you were hosting some addresses internally but others are hosted at a 3rd party, such as www .contoso.com goes to your company’s website but mail.contoso.com goes to your OWA. Creation of a zone internally for that specific address would allow internal requests to be managed by your internal DNS while still forwarding requests for the company site to the public DNS side. This simplifies DNS management as well. You would have your mail.contoso.com zone and you could be migrating from one Exchange server to another and all you would have to manage internally is the mail.contoso.com zone. Your public IP address has not changed at all so your public A record for mail.contoso.com has no need to be updated. All those remote users hitting mail.contoso.com would not notice a difference, unless of course you have forgotten to change your NAT and firewall rules but that is an entirely different subject. Also if the reverse is true and you are changing your public IP address you would still only be changing your public DNS records. Private DNS would not be impacted whatsoever.

So what if you were to go with contoso.com for your AD forest as well as your public DNS? DNS changes would be more complex. You would need to manage addresses both externally and internally. An example, you have your mail.contoso.com address created externally and your remote users are using OWA. If they come into the office suddenly all their OWA requests are failing since an A record internally is not created. You create your A record pointed to your Exchange server internally and everything works properly again. Then there is the scenario of the company website which is hosted by a third party. Users are able to access http://www.contoso.com outside the company but inside the company the requests fail. You create an A record pointed to the 3rd party site and everything works again, until you switch your hosting provider. People will be unable to access the site again until you also update the internal DNS record.

There is also the single label domain name to think about. Microsoft recommends to avoid this and I would also recommend avoiding it since it requires even more initial management to get things working properly. It can also cause problems with cross forest trusts.

Keep your DNS simple and you will have less late nights trying to figure out why mail.contoso.com does not work on the company network.

Exchange 2007 Single Server Migrations for Profit or Headache

I was originally writing up a guide for migrating, actually transitioning, Exchange 2003 to Exchange 2007. There are lots of guides out there that would have better screenshots and perhaps even better written steps. Basically I would not really be meeting a need as there are already plenty out there doing so. So instead I am scrapping all of my original work and concentrating on issues that I believe are not talked about as much out there. Mostly these issues affect those that are doing single server migrations, which is basically you have one Exchange 2007 server holding all of your roles. They have caused me a great deal of headache and drama which I am sure is true for others doing such migrations as well. I would imagine that this is mostly the SMB sector, which is where the majority of my work in this is being done. Let’s talk about the biggest issue now, client access.

The CAS role plays a big part in your Exchange organization as it is the broker for all requests to your mailboxes. You will have MAPI requests as well as HTTPS, POP3 and others coming into this server. By the way as a security side note the recommended set up is to have your CAS role on your internal network with a reverse proxy in your DMZ for proxying requests through to your CAS. The CAS when it receives a request for a mailbox that resides on a 2003 servers proxies that request through to your 2003 server. No issues at all there. The problem that comes up, though, with having a CAS on the same server as your MB is that web requests no longer get proxied to your 2003 servers, they get redirected. This is due to davex.dll handling the requests on a mailbox server, and it will grab the requests first. Exprox.dll is what handles proxying. This redirection is not configurable either. So that causes a problem when it is redirecting an external request to an internal FQDN. That doesn’t work out too well and you get lots of angry OWA users wondering why their logins take them to an invalid address. For a more in depth explanation take a look here. Let’s take a look at a few ideas for mitigating this issue.

First off an easy fix would be to make sure your Exchange 2003 FQDN has a matching public address. This is not a recommended set up though at all. It is against best practices to have your internal domain match your external domain. Not to mention you can get a number of funny DNS issues going on if this is the case unless you’ve planned things out well. Read this article for some more DNS information, and especially look at the split-brain section. All of this can turn your easy fix into a much more complicated fix. If the stars do just happen to be right on your migration though, then go for this. Set up a public record matching your internal Exchange 2003 name and you’ll be set. This will be transparent to your users.

Next up would be to use a reverse proxy such as ISA 2006. This would be great as it keeps the strict definitions of your DMZ as it keeps your Exchange servers from having to blur the lines. This doesn’t seem to be something that most SMBs care about in my experience though. They don’t seem to see the need for security and how having a properly defined DMZ fits into this. But that goes into an entirely separate article and could sound a bit ranty.

Other methods will require a bit more cooperation from your users. Remember, in Exchange 2007 the OWA access by default is /owa. So you will need to communicate this to your users as you migrate their mailboxes over. Then, remove the /exchange virtual directory through the Exchange Shell and recreate it in IIS. Finally, set up /exchange with a custom 403 redirect to a different port on your external address. Mind you that you’ll need to make sure that port does point to your legacy server. This either requires your firewall to be able to do port translation or changing the ports on your 2003 server.

Finally, and the most recommended method, is to set up a temporary virtual machine that will purely host a CAS role. Then everything will be proxied as it is supposed to be. The down side to this is that it would require a separate license in which case you might as well plan for as separate CAS to begin with.

Fortunately as long as everything is configured properly Outlook Anywhere and ActiveSync seem to work just fine. Some dangers with those is if you are having some DNS issues internally or improper communication with a global catalog. This can add to your headache so you will want to cozy up to rcpping which you can grab from Microsoft and get more info about how to work it from here. Another great site I have recently found out about is the Remote Connectivity Analyzer. This site will enable you to test Outlook Anywhere, ActiveSync, SMTP and Autodiscover with detailed error messages about where these break down. It will become your best friend very swiftly.

I guess the moral of all these suggestions is to make sure you have your migration well planned out. Run it through a test lab first if you are able. Definitely make sure you test it out, and definitely don’t spring it on your users unawares. You could be in for quite a “fun” surprise.

Troubleshooting 554 Relay Access Denied NDRs

This week I was called up by a former employer to come in and check out their Exchange 2003 server. They had been having problems with a few domains rejecting their e-mails for the past few weeks and what made it a big problem was that one of the domains was their largest customer. Not a good scene there. They were receiving several NDRs of which the most prominent was something like <mail.domain.com #5.7.1 smtp;554 5.7.1 foo@otherdomain.com: Relay access denied> as well as some from another domain referencing authentication. I don’t have it in front of me so unfortunately I can not quote it. Doing some research I found that there was not much information on troubleshooting this and related problems even though there were lots of people asking. So I am putting together a quick little guide based off how I came to a resolution. Your results may vary.

E-mail problems generally break down to two types. Either you are having DNS problems, or you have a misconfigured server. First thing to do of course is to narrow down whether the problem is on your end or if it is on their end. Generally one would suspect the problem to be on their end when it is only a couple of domains giving you a problem, but that isn’t always the case. Easiest way to narrow it down is to break out the command line utilities. First verify that you are using the same DNS as your Exchange server. This is very important otherwise it may skew the results of your test. Next off you need to find your problem domain’s mail server. You have several options for this. The lazy way is to go to MX Lookup Tool and put in the domain. It should return the mail servers for that domain. You’d be best off going with the first one. The site also has some interesting diagnostic utilities that you could run against your mail server as well as their own. The non-lazy method, and one you should learn anyhow, is using nslookup. Pop open your command line and run nslookup. Here’s the steps to go through to get the MX records for their domain.

> set type=mx
> problemdomain.com
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
problemdomain.com mail exchanger = 10 mail.problemdomain.com.

Authoritative answers can be found from:

There’s the mail server that you are working with. Sometimes there are more than one so start from the top and work your way down. Next up is we’re going to send an e-mail the archaic way, through telnet. Note that not all SMTP servers respond with the exact same banners and responses, though the codes should generally line-up. Open up a telnet prompt.

telnet>  open mail.problemdomain.com 25

Trying 64.24.111.68…
Connected to mail.problemdomain.com.
Escape character is ‘^]’.
220 mail.yourdomain.com ESMTP Sendmail 8.9.3/8.9.3; Tue, 27 Aug 2002 16:20:32 -0500

At this point you need to identify yourself as your mail server.

ehlo mail.mydomain.com

250-mail.problemdomain.com mail.mydomain.com [203.32.9.6] pleased to meet you
250-8BITMIME
250-SIZE 10000000
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP

Now it is time to identify who you are.

mail from:yourself@mydomain.com

250 Ok

Next is who you are e-mailing.

rcpt to:testaccount@problemdomain.com notify=success,failure

250 Ok

If you get a 250 Ok at this point then telnet will most likely complete successfully. Also if you get a  510 Bad user that is ok as well, since you are not getting a relay access denied which is what your Exchange server is getting when it communicates with this server. This means their server has passed the telnet test so you need to start digging into your server to fix the problem. If you get a 550 Relaying denied error though that is different. Time to modify the test. Change your DNS server to a known good external DNS server that resolves both forward AND reverse look-ups correctly. If it does not resolve reverse look-ups it is no good to you. Switch your machine over to that DNS server and run through the test against. If it is successful then you’ve tracked the problem down. Time to look at what DNS servers your Exchange is using. Or it may also be time to check on your own internal DNS servers, as they may not be resolving addresses correctly. If, though, you receive a failure from your telnet test with a known good set of DNS servers then things may be a bit more complex. Do a look up on whether your domain is in any Realtime Blackhole Lists (RBL). If it is then definitely check to see if you are running an open relay and get yourself off those lists fast. If not then you had best get on the phone with the admin over at problemdomain.com to find out if your domain has been blacklisted. Finally another thing to verify is your SPF record on your external facing DNS. Here is a site to help craft an SPF record.

For completeness here are the rest of the directions to finish sending your e-mail through telnet:

data
354 End data with <CR><LF>.<CR><LF>
Test e-mail
.
250 Ok
quit
221 Bye
Connection closed by foreign host.
telnet>

In case you were wondering at the client’s site it turned out the Exchange server was set up to use an external DNS server that was not resolving reverse look-ups. This was causing a few sites to return the 554 relay access denied NDRs.

Some other tools that may be helpful in diagnosing your problem:

SMTPDiag.exe

Exchange Best Practices Analyzer

Configuring DNS Zones in Core

Now that you grok more completely the concepts of DNS and how it works we will be going over some of the actual implementation details, on Server 2008 Core of course. We’ll jump on the primary DNS server for our lab and set up a subdomain and put together some records for it. Then we’ll set up another DNS server and do a zone transfer to it and make it authoritative for the zone. We’ll be adding a reverse look-up zone for our ip range as well. That should get you started on managing zones and records from the command line. Let’s begin with a reverse look-up zone for our shinra.inc domain.As mentioned earlier for creating a reverse look-up zone you read from right to left for the ip address. I need to clean-up a bit first, though.

C:\>dnscmd /zonedelete 0.60.10.in-addr.arpa /dsdel

I had a zone left over from some previous work so we are going to remove it and start over. Note the addition of /dsdel to the command. This is require to remove the zone from AD if it is AD integrated. Otherwise you will receive an error such as DNS_ERROR_INVALID_ZONE_TYPE 9611. If you are working with a non-AD integrated zone then it is fine without /dsdel. Now let’s recreate our reverse look-up zone.

C:\>dnscmd /zoneadd 0.60.10.in-addr.arpa /dsprimary

This gets us an AD integrated zone. Pretty much you’ll want to always great AD integrated zones, unless you have requirements such as needing to replicate to a DNS server that is not a DC such as a BIND server set up on your Linux box. AD integrated zones enable you to configure secure dynamic updates. This allows an ACL to secure who can read and update particular records. We’ll set up some PTR records now for our machines.

C:\>dnscmd /recordadd 0.60.10.in-addr.arpa 2 PTR cloudcore.shinra.inc

Now if you execute an nslookup of 10.60.0.2 you’ll find a response of cloudcore.shinra.inc. Here’s the anatomy of how this works. After the /recordadd you specify your zone name which is 0.60.10.in-addr.arpa, then next comes your node which is your ip address relative to the zone name. Since our server is 10.60.0.2 in 0.60.10.in-addr.arpa this would be 2. If the zone was only the first two octets it would be 60.10.in-addr.arpa which would mean our node would be 2.0 for this zone. Then we specify that it is a PTR RR and give the FQDN. We’ll add in a few more records to flesh out the zone.

C:\>dnscmd /recordadd 0.60.10.in-addr.arpa 10 PTR renocore.shinra.inc
C:\>dnscmd /recordadd 0.60.10.in-addr.arpa 12 PTR rudecore.shinra.inc

Note that DHCP clients can add their own PTR records in addition to A records. To verify this list of records we’ve added we’ll do a recordsenum.

C:\>dnscmd /enumrecords 0.60.10.in-addr.arpa @
Returned records:
@ 3600 NS cloudcore.shinra.inc.
3600 SOA cloudcore.shinra.inc. hostmaster.shinra.inc. 13 900 600 86400 3600
2 3600 PTR cloudcore.shinra.inc.
10 3600 PTR renocore.shinra.inc.
12 3600 PTR rudecore.shinra.inc.

This should show that your reverse look-up zone is properly created and populated. We will now move on to our next exercise of creating a subdomain. Since we will also be using this zone for non-AD integrated zone transfers will be creating it is a regular zone which requires it to be stored as a file and not in a directory partition.

C:\>dnscmd /zoneadd lab.shinra.inc /primary /file lab.shinra.inc.dns

We’ll add a few A records for a few non-existent machines to populate the zone. We’ll use a quick batch script to aid in this. Here’s the contents of the script.

for /L %%C in (%1, 1, %2) do dnscmd /recordadd lab.shinra.inc experiment%%C /createptr A 10.60.0.2%%C

Then run from the command line with adddns.bat 10 30. This will populate your zone with a good number of A records. You can verify with dnscmd /enumrecords lab.shinra.inc @. You can also verify that the corresponding PTR record was created with dnscmd /enumrecords 0.60.10.in-addr.arpa @. Now we’ll set up a second server to transfer this zone over to. Configure your server as normal and join it to the AD or not as it doesn’t really matter in this case. If you do join it to the AD you can transfer over AD integrated zones as well though. Let’s get our DNS role installed on it. Here’s a good way to find out the name of a service for installation without having to scroll through a long list.

C:\>oclist | find /I “dns”

Now to install it.

C:\>start /w ocsetup DNS-Server-Core-Role

Once that finishes the role will be installed. We need to configure our original DNS server to allow zone transfers to this new server.

C:\>dnscmd /zoneresetsecondaries lab.shinra.inc /securelist 10.60.0.25

Then we jump back onto our new server to get the zone set up and transferred.

C:\>dnscmd /zoneadd lab.shinra.inc /secondary 10.60.0.2
C:\>dnscmd /zonerefresh lab.shinra.inc

Once this has finished transferring, which with these sizes and being in the same network should be instantaneous, you’ll have a complete read only copy of the zone on this server. Now to make it a master we decommission the old server and make the new one the primary. On the old server we delete the zone.

C:\>dnscmd /zonedelete lab.shinra.inc

Then on the new server we switch it to being a primary zone.

C:\>dnscmd /zoneresettype lab.shinra.inc /primary /file lab.shinra.inc.dns

Then we’ll verify that we were successful from the zone RRs themselves.

C:\>dnscmd /zoneprint lab.shinra.inc

Check your SOA record if you see that your new server is listed then the transfer of the master server was successful. Most likely your NS records will not have been updated properly, so we will go through an recreate those ourselves.

C:\>dnscmd /recordadd lab.shinra.inc @ NS redxiiicore.shinra.inc
C:\>dnscmd /recorddelete lab.shinra.inc @ NS cloudcore.shinra.inc

Now we could even take it a step further and create a stub zone on our previous server for our lab.shinra.inc zone. Hop on your old server and let’s get this created.

C:\>dnscmd /zoneadd lab.shinra.inc /stub 10.60.0.25

Check the zone info and you should be seeing the SOA and NS records in there for the zone, but none of the horde of A records that we had created.

You should be feeling up to speed on managing DNS from the command line on your Core installations. Don’t forget that you can also use these on your full Server 2008 (or even older versions) installations as well. The GUI can be easier but don’t let it be your only tool in your arsenal. Remember that one of the places the CLI can shine is in scripting, as demonstrated earlier. For some reference reading this post will be useful for you as it has a list of commands for dnscmd and a quick example.

DNSCMD Reference

Understanding DNS

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:

%d bloggers like this: