Home » Tutorials » Configuring DNS Zones in Core

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 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 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

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

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

C:\>dnscmd /zoneadd lab.shinra.inc /secondary
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

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



  1. […] managing 2k8 Core. You should be able to find some help in there and from the references I linked. Configuring DNS Zones in Core Jeffery Land’s Tech Blog __________________ Jumping on the IT blogging band wagon — […]

  2. […] and know-how, even without a final work product to show. Take a look at his blog entry called “Configuring DNS Zones in Core”, where Jeffrey explains configuration details for DNS under Windows. He’s created a helpful […]

  3. Mike Dzikowski says:

    Can you help me figure out the switches to set:

    set as primary zone
    check store zone in active directory
    set dynamic updates to secure only
    set zone data replication to all name servers (all in domain)


  4. jefferyland says:

    dnscmd /ZoneAdd foo.com /dsprimary
    dnscmd /Config foo.com /AllowUpdate 2

    Definitely take a look at dnscmd /? and dnsmcd /config /? it will get you a lot more information about what commands are available and what they do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

wordpress visitor counter

RSS Subscriptions

Contact Me

%d bloggers like this: