Remotely Manage your DNS

Setting up and managing the DNS settings in a complex network can be time consuming and even confusing. On a Windows network, you can make it easier by using the DNS classes of the Windows Server, exposed by the WMI (Windows Management Interface). Moreover, you can create a Web interface to manage it using ASP.NET. For this you need to be familiar with Win Server 2003, IIS and DNS (Read DNS Primer). Plus, some basic knowledge of WMI, ASP.NET and VB is a must. This application will run only in a Win Server 2003 environment and you need the .NET framework 1.1, IIS, Active Directory and DNS on this server. The .NET framework is already a part of the server, while DNS gets installed when you install Active Directory. You'll need to install IIS with ASP.NET support separately.

We have given the complete website as a VS.NET 2003 Web application project on our CD. The zipped executable file we have provided will extract all its files to 'C:\Inetpub\wwwroot\PCQDNSManager' by default (change this path to your website root). There are two 'problems' with the code as it stands now- neither can it use IP address-based access of this website nor can it work properly if you access using non port-80 URLs. For this reason, set up the project as a Virtual Directory (or a port-80 website using Host headers) in IIS and turn off anonymous access (only Integrated Windows Authentication).

You also need to edit the WEB.CONFIG file provided, to insert the 'administrator' account password in the IDENTITY IMPERSONATION key. You can then start modifying it by opening the project using VS.NET 2003.

WMI classes involved



The .NET Framework 1.1 provides the 'System.Management' namespace to help connect to WMI. In this article, we create a class called 'Management_DNS' that will contain the code to interact with the DNS via WMI; and a set of ASP.NET pages to use this class and provide frontend capability.

The specific classes we will use in our script, which belong to the MicrosoftDNS set are: the various MicrosoftDNS_xType classes ('x' denotes the type of RR we are manipulating like 'A', 'NS' and 'SOA'-eg, MicrosoftDNS_AType) and

MicrosoftDNS_Zone.

All the MicrosoftDNS_xType classes derive from the MicrosoftDNS_ResourceRecord base class. This class contains nine properties, which can be used in various ways. In particular, the TextRepresentation property will always denote the complete information about this RRs' data as it would appear in a traditional DNS zone file ('pcquest.com A 147.208.184.149' for an A-record). Since most of these classes (except SOA) use the same properties, we need to write only one function each for reading and writing the various RRs. SOA is more complex because it has to manage far more data than the other classes.

Run through



We need to first connect to the MicrosoftDNS root class (done in our New() function in Management_DNS class in the file '_library\Management. DNS.vb') as:

ManagementPath.DefaultPath = _



New ManagementPath("\\" & _


DomainName & _


"\root\MicrosoftDNS" _


)





oMgmt = New _


ManagementObject( _


"MicrosoftDNS_Server.Name=""" & _


DomainName & """" _


)

Now, wherever we need to use the DNS-WMI, we use the ManagementClass (System.Management) interface to connect to this instance and retrieve the collection enumerator. Then, we loop through each instance returned, checking if it is the one we want. On finding the right one, we can read, edit or delete it. If we change or delete the RR entry, we need to call the appropriate method (Modify or Delete) to commit the changes back to WMI.

oEnum = New ManagementClass (S) .GetInstances (). GetEnumerator()



.


Do While (oEnum.MoveNext())


oMgTmp = oEnum.Current


S = oMgTmp.Properties("TextRepresentation").Value


If (S = T) Then


' Do the required operation


oMgTmp.InvokeMethod( _


"CALL_THE_COMMIT_ FUNCTION", _


modParam _


)


Exit Do


End If


Loop


oMgTmp.Dispose()

Unlike other Windows API, the DNS-WMI returns rather cryptic and generalized error messages such as 'General Failure'. In one particular case (CreateRR() in Management_DNS), we have to catch and ignore this exception generated, since the

RR is already created but an exception is somehow still thrown from the WMI-API layer.

The ASP.NET part



After all that hard work in the Management_DNS class, our ASP.NET code is very simple. For example, to create a new RR (of any type), our code would be

Dim DNS As New Management_DNS(DomainName)



DNS.CreateRR(RRParentName, RRName, RRData, RRType)


DNS.Dispose()

In the sample given on our CD, we have shown how to create, edit and delete Forward Zones. It is very simple to extend this to Reverse Zones as well, by simply passing '1' instead of '0' for the 'RRType' parameter in the call to CreateZone(). Similarly, our code shows how to manipulate A, CNAME, PTR, MX and NS RRs. You can extend it to other RR types as well. As a bonus, we have added the code to display and edit SOA records as well.

Further



The application can be further enhanced using Role-based Security (see last month's article), where you may login even if you are not an administrator. Also, our code uses WMI through ADSI and that's why it requires Active Directory to be installed. Not all DNS servers are going to have this and the DNS itself may be running on a non-Windows platform. In its present form, our project does not attempt to address these issues and only gives you a kick start towards better and more scalable solutions.

You can also change the code so as to pick up the domain information from WEB.CONFIG instead of the URL. This will also solve our access IP/Port problem discussed above.

Sujay V. Sarma

DNS primer

You might already know that computers care less about human words and more about its numeric representation. So, while we would call a computer, 'officepc', the computer would refer to it as '192.168.0.1'. The human name is called its DNS name and the numeric form is its IP address. The system that performs the translation between the two is known as the DNS or Domain Name System.

Domains and domain names are organized into hierarchical entities called 'zones'. Depending on the mindset of your DNS Administrator, your zone can be single-tiered or multi-tiered. That is, if you have a domain name called 'pcquest.com', you can either have 'com' as a zone and 'pcquest' as a subzone under it. Or, can have 'pcquest.com' as a single zone. 

These zones can be Primary, Secondary or Stub. Primary zones are considered the masters (authoritative) and secondaries are 'backups'. Stub zones simply improve lookup speed for commonly searched for zones. Again, zones can be forward or reverse. Forward zones translate names to their corresponding IP addresses and reverse zones translate IP addresses to names. Each zone can contain a number of records of different types, called 'Resource Records'

(RRs).

There are many types of RRs and it is not necessary to have all of them in a zone. The commonly used types are — Host (A), Pointer (PTR), Name Server (NS), Mail Exchange (MX), Canonical Name (CNAME) and Start of Authority (SOA). A brief description of these types follows:

Host (A) : Maps a name to an IP address, eg, the domain 'pcquest.com' maps to its IP address '147.208.184.149'

Pointer (PTR) : Map an IP address to a name, ie, reverse of 'A' record

Name Server (NS) : The DNS servers authoritative for a particular zone

Mail Exchange (MX) : Specify the POP/IMAP mail servers that receive mail for a zone

Canonical Name (CNAME) : Alternative name for an 'A' record, eg, 'pcquest.com' could also be 'www.pcquest.com' or 



'pcquest.cybermedia.com'. This is used to simplify access to a host 

Start of Authority (SOA) : Provide various administrative values (such as expiry time, e-mail address of zone-administrator, etc)