Type of dns zones in windows 2003

Also, it meant that all the changes you made to DNS had to be performed on a single name server the primary , which could be an inconvenience if the company spanned several locations. Windows provided a solution to these issues by introducing Active Directory Integrated zones , which stored their zone information within Active Directory instead of text files.

The advantages of this new type of zone included using Active Directory replication for zone transfers and allowing resource records to be added or modified on any domain controller running DNS. In other words, all Active Directory Integrated zones are always primary zones as they contain writable copies of the zone database.

Active Directory Integrated zones work well for most Windows based networks, but they do have some issues. One limitation is if you are dealing with two separate forests disjointed namespace , a common scenario when companies are merging or form part of a conglomerate.

The usual way of providing them this access would be for the DNS administrator of Company A to add a standard secondary zone on each of Company A's name servers. These secondary zones would then point to name servers on Company B's network as their master name servers, and would obtain their resource records by zone transfers with Company B's name servers.

While that works, it's overkill for several reasons. First, it generates a lot of zone transfer traffic between name servers in Company A and Company B, which can pose a problem if the companies are linked together by a slow WAN connection. Second, if Company B decides to decommission one of its name servers without telling the administrator of Company A, some of the secondary zones on Company A's name servers could suddenly find themselves without a master, and once their records expire the Company A clients that use them will no longer be able to access resources in Company B.

Enter stub zones to the rescue. A stub zone is like a secondary zone in that it obtains its resource records from other name servers one or more master name servers. A stub zone is also read-only like a secondary zone, so administrators can't manually add, remove, or modify resource records on it. But the differences end here, as stub zones are quite different from secondary zones in a couple of significant ways.

First, while secondary zones contain copies of all the resource records in the corresponding zone on the master name server, stub zones contain only three kinds of resource records:. So while a secondary zone can be quite large for a big company's network, a stub zone is always very small, just a few records.

This means replicating zone information from master to stub zone adds almost nil DNS traffic to your network as the records for name servers rarely change unless you decommission an old name server or deploy a new one. Also, while most DNS servers can be configured to prevent zone transfers to secondary zones from occurring, stub zones request only SOA, NS, and A records for name servers, all of which are provided without restriction by any name server since these records are essential for name resolution to function properly.

Only by viewing the multiple sides of DNS will you be able to you judge how to configure your servers. Be sure to research thoroughly, plan carefully and test to destruction before you implement a production DNS network. See more on resource records.

Secondary Zone — Read only copies of records, gets updates from the primary server by zone transfer. Stub Zone — New in Windows , a tiny zone with just pointers to another domain.

Think of Stub Domains like secondary zones, but with only 3 records. See more on Stub Zones here. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload. Its second best feature is the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you give this Network Performance Monitor a try.

This is a huge advantage over the old model where you had to update records manually. With secure updates you avoid lots of rogue records cluttering your DNS records. After you integrate a zone, you can use the access control list ACL editing features that are available in the DNS snap-in to add or to remove users or groups from the ACL for a specific zone or for a resource record. For more information, search for the "To modify security for a resource record" topic or the "To modify security for a directory integrated zone" topic in Windows Server Help.

By default, dynamic update security for Windows Server DNS servers and clients is handled in the following manner:. Windows Server-based DNS clients try to use nonsecure dynamic updates first. If the nonsecure update is refused, clients try to use a secure update. Also, clients use a default update policy that lets them to try to overwrite a previously registered resource record, unless they are specifically blocked by update security.

By default, when you use standard zone storage, the DNS Server service does not enable dynamic updates on its zones. For zones that are either directory-integrated or use standard file-based storage, you can change the zone to enable all dynamic updates. This enables all updates to be accepted by passing the use of secure updates.

The secure dynamic updates functionality can be compromised if the following conditions are true:. For more information, see the "Security considerations when you use the DnsUpdateProxy group" section. The secure dynamic update functionality is supported only for Active Directory-integrated zones. If you configure a different zone type, change the zone type, and then integrate the zone before you secure it for DNS updates.

If you use secure dynamic updates in this configuration with Windows Server-based DNS servers, resource records may become stale. In some circumstances, this scenario may cause problems. For example, if DHCP1 fails and a second backup DHCP server comes online, the backup server cannot update the client name because the server is not the owner of the name. In another example, assume that the DHCP server performs dynamic updates for legacy clients.

If you upgrade those clients to a version supporting dynamic updates, the upgraded client cannot take ownership or update its DNS records. To solve this problem, a built-in security group named DnsUpdateProxy is provided. If all DHCP servers are added to the DnsUpdateProxy group, the records of one server can be updated by another server if the first server fails. Also, all the objects that are created by the members of the DnsUpdateProxy group are not secured.

Therefore, the first user who is not a member of the DnsUpdateProxy group and that modifies the set of records that is associated with a DNS name becomes its owner. When legacy clients are upgraded, they can take ownership of their name records at the DNS server. If every DHCP server that registers resource records for legacy clients is a member of the DnsUpdateProxy group, many problems are eliminated.

If you are using multiple DHCP servers for fault tolerance and secure dynamic updates, add each server to the DnsUpdateProxy global security group. Also, objects that are created by the members of the DnsUpdateProxy group are not secure. Therefore, you cannot use this group effectively in an Active Directory-integrated zone that enables only secure dynamic updates unless you take additional steps to enable records that are created by members of the group to be secured.

To help protect against nonsecure records or to enable members of the DnsUpdateProxy group to register records in zones that enable only secured dynamic updates, follow these steps:. A dedicated user account is a user account whose sole purpose is to supply DHCP servers with credentials for DNS dynamic update registrations.

Assume that you have created a dedicated user account and configured DHCP servers with the account credentials. The dedicated user account should be created in the forest where the primary DNS server for the zone to be updated resides.

The dedicated user account can also be located in another forest. However, the forest that the account resides in must have a forest trust established with the forest that contains the primary DNS server for the zone to be updated. When the DHCP Server service is installed on a domain controller, you can configure the DHCP server by using the credentials of the dedicated user account to prevent the server from inheriting, and possibly misusing, the power of the domain controller.

When the DHCP Server service is installed on a domain controller, it inherits the security permissions of the domain controller. The service also has the authority to update or delete any DNS record that is registered in a secure Active Directory-integrated zone. This includes records that were securely registered by other Windows-based computers, and by domain controllers. The dynamic update functionality that is included in Windows follows RFC By default, the name that is used in the DNS registration is a concatenation of the computer name and the primary DNS suffix.

Right-click the connection that you want to configure, and then click Properties. This default configuration causes the client to request that the client register the A resource record and the server register the PTR resource record. If the DHCP server is configured to register DNS records according to the client's request, the client registers the following records:.

To configure the client to make no requests for DNS registration, click to clear the Register this connection's address in DNS check box.