Because DNS is critical to the functioning of most network services, a DNS Provider is included with Microsoft Provisioning System (MPS) to facilitate a more fully automated workflow process in the provisioning environment. With the DNS Provider incorporated into MPS, you can control and log the changes to the DNS database running on a computer running Microsoft Windows Server 2003, in addition to rolling back any failed transactions so that the database is restored to an unaltered state.

Because MPS on a server running Windows Server 2003 needs to communicate with the management interface of the DNS database on a server running Windows Server 2003, the DNS Provider is developed with distributed components. The DNS Provider assembly consists of the DNS Provider component and the DNS Provider Client component. The DNS Client component interoperates with the DNS Provider and provides the management interface for method calls that manipulate the DNS database to support provisioning tasks that require changes to DNS.

The DNS Provider component resides with MPS on a server running Windows Server 2003 and the DNS Provider Client component is installed on a server running Windows Server 2003 and DNS. These two components communicate with each other by means of .NET Remoting, a new technology in the .NET platform that is similar to Distributed Component Object Model (DCOM) or COM+.

The following figure shows data flow with .NET Remoting and the DNS Provider distributed architecture.

Figure: Data flow with .NET Remoting and DNS Provider distributed architecture

In the preceding figure, the DNS Provider on the server running Windows Server 2003 acts as an interface layer between the MPF Engine and the DNS Provider Client, which resides local to DNS on the server running Windows Server 2003. The .NET Remoting technology facilitates communication between the DNS Provider component and the DNS Provider Client through the Remoting Client and server components. The actual provisioning work of the provider assembly is accomplished by the DNS Provider Client, which handles method calls to the Windows Management Instrumentation (WMI) DNS Provider on the DNS server through the .NET 1.1 Framework's System.Management namespace.

You can use either basic or integrated authentication for connections between the DNS provider client and the DNS provider components. By default, the provider client uses basic authentication, which uses explicit username and password credentials. If you chose to use integrated authentication, then these credentials are not required and, if supplied, are ignored.

It is difficult to overstate the importance that a hoster or service provider needs to place on securing their DNS infrastructure. This is a key component to any web based service offering. This is also one of the more popular targets for attack in any data center. The broader topic of DNS Security and guidelines for securing a windows Based DNS deployment is is discussed in Security information for DNS.

MPS allows users to create, modify, delete and manipulate DNS zones and records on a Windows Based DNS server. While this is an extremely useful feature of a provisioning system, it is also a feature that must be carefully protected. Inappropriate modification could result in data loss, improper redirection to potentially rogue or dangerous servers, service interruption. Also, if internal DNS servers rather than external are targeted, Active Directory, Exchange and WSS could stop functioning properly resulting in extended service downtime. These are just a few examples of some of the risks inherent in DNS provisioning.

Considerations for securing the MPS DNS Provider architecture include:

• The account used to provision DNS should have strong credentials
• If the account used to provison DNS is persisted the credentials should be encrypted and the location secured
• Firewalls should be configured to ensure that the MPS Engine servers can only make .NET remoting connectons to approriate DNS Servers
• MPS Engine servers should be explicitly prevented from making .NET remoting connections to internal DNS server servers
• User input that is used in a DNS provisioning actions should be validated in the following ways
  • serverIdentifier should be matched against a list of known valid DNS Server targets
  • a mechanism should be inplace to validate ownership of a zoneName prior to allowing the provisoining actions
  • zoneType should be system maintained and not based on direct user input
  • If the provisioning action is to create a record pointing to a hosted service, IP Address should be supplied by the system from a list of known good IP addresses or CNames.