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