DNS Conditional Forwarders – AD integrated

Ward of the Windows Server Devision Weblog wrote earlier this summer about a “new feature” in Windows Server Codename “Longhorn”, the possible integration of Conditional Forwarders in Active Directory. I’ve posted an comment that this is already available in Windows Server 2003 using the commandline and received a few questions about it, so I decided to write down some more details about this topic.

OK – lets resume what conditional forwarders are. Usually when a DNS-Server is receiving a request from a client or himself [1] he’s first checking if the request is for a name he’s holding a zone for [2], then he’s checking the cache, and if he’s still unsucessfull he’s forwarding the request to the IP-Adresses configured in the Forwarders-Tab of the Server Properties in the DNS-Managementconsole dnsmgmt.msc. Therefore it was always quite tricky if you hold disjointed namespaces in your company (e.g. unix.example.com and windows.mycompany.org) but have not (enough) control over the parent namespaces. You usually had to resolve this by forwarders and secondary zones, or secondaries on both sides a.s.o.

Windows Server 2003 introduced some new features which provide more flexibility. Conditional Forwarders allows you to configure specific forwarders if the request is for a well-known namespace. They were configured in the same Tab than the forwarders in WS2k3. The default forwarder was underneath “All other domains”, and you were able to configure additional namespaces (by their parent DNS-Domain) and which DNS-Servers they should forward to. Additional Windows Server 2003 introduced Stub-Zones, however I will cover those in a later post not to get way off topic. Technically a conditional forwarder is only a “zone” with static NS- and A-Records for the DNS-Servers of the target DNS-Namespace.

When you configured Conditional Forwarders in the Managementconsole, you were not able to configure a conditional forwarder to be stored and replicated in Active Directory (like Active Directory-Integrated Zones). You may want to do this if all DNS-Servers/DCs in the replication scope [3] should directly forward requests of that namespace. In Windows Server Codename “Longhorn” you can configure this now in dnsmgmt.msc, see Wards Post or read further [;)].

However when you configured the conditional forwarder using the commandline utility dnscmd.exe you are even in Windows Server 2003 able to configure a forwarder which is AD-Integrated and therefore replicates to all DNS-Server/DCs in the replication scope.

Use the following syntax to configure a conditional server for the namespace myexample.net:

dnscmd /ZoneAdd myexample.net /DsForwarder

After you did this, you can see the new conditional forwarder in the DNS-Managementconsole, and note that you are even able to see that this forwarder is Integrated in Active Directory:

One of the questions I got asked about this is where the Conditional Forwarder is stored in Active Directory (which of the partitions [3]) and if you are able to change this, e.g. having a certain Forwarder replicated across the Forest and another one across the Domain. Yes – this is possible. By default a Conditional Forwarder which is AD-Integrated with the above command will end in the DomainDnsZones-Applicationpartition, and therefore replicating to all DNS/DCs in the domain. If you prefer other scopes you can define this in the commandline using the parameter /DP. DP takes the following parameters:

  • /legacy: replicates to all DCs in the domain whether they are DNS-Servers or not
  • /domain: replicates to all DCs in the domain which are also DNS-Servers
  • /forest: replicates to all DCs in the forest which are also DNS-Servers
  • FQDN of a custom Applicationpartiton: Yes – this is weired, but here we have to provide the FQDN (instead of the distinguishedName) of a custom application partition where we’d like to store the Conditional Forwarder

So for an example the following two commands will work against the local DNS-Server if it’s a WS2k3-DC. For the second example you need a custom applicationpartition dc=MunichDnsZones,dc=example,dc=com (which you are able to create with NTDSUtil -> Partition Management, however do this only in a test environment if you are not absolutely certain what you want to accomblish with the custom partition):

dnscmd /ZoneAdd myforestexample.net /DsForwarder /DP /forest

dnscmd /ZoneAdd mycustomexample.net /DsForwarder /DP MunichDnsZones.example.com

So let’s finish this post with showing how this is exposed in the DNS-Managementconsole in Windows Server Codename “Longhorn”. If you look into the console one of the first things you’ll notice is that Conditional Forwarders are not in the Server Properties anymore, they’ve made it into their own node in the navigation pane. That’s a good move – as I mentioned earlier Conditional Forwarders are actually like zones with only the NS- and A-Records for each delegated server. And another Yes – Delegations are also almost the same, but they are still created in their “parent zone” because it’s more logical. Conditional Forwarders, just like Forward Lookup Zones and Reverse Lookup Zones are not required to have a parent zone on the same Server so it’s also logical to have them separately.

When you decide to create a new Conditional Forwarder you get a dialog box which also provides you with the possibilities to store the Forwarder in Active Directory and you are also able to select which applicationpartitions you’d like to store the Conditional Forwarder in. This even works for your custom applicationpartitions (and this sounds like another post – explaining when custom applicationpartitions might be usefull).

Also note that Longhorn tries to resolve the FQDN of the target Server of a Conditional Forwarder. Don’t be worried if you don’t receive results. This is not necessary. However if you have Reverse Lookup Zones set up correctly you might want to fix this.

[1] Many people tend to forget that any system always asks the DNS-Server which is configured in the TCP/IP-Properties. Even if a server holds the DNS-Server-Service it will resolve his requests through the DNS-Server which is configured in the TCP/IP-Properties and only uses himself if he’s configured to do so.
Also keep in mind that you are able to configure multiple DNS-Servers, however the second, third a.s.o. DNS-Server is only used if the previous ones are not reachable via TCP/IP – as long as the server is online there’s no fallback to other servers, even if the DNS-Server Service is not running or even not installed.

[2] If a server is receiving a request for a name where he holds a zone for but the name does not exist, it assumes the name is not used and will not forward the request. You have to keep this in mind when “overwriting” parent or external (ISP) zones.

[3] In Windows 2000 there was only one replication scope: As soon as you integrated a DNS-Zone into Active Directory the informations in the zone are replicated to all Active Directory Domain Controllers of that Domain (no matter if a DNS-Server-Service is installed and therefore the information is usefull on this server).
In Windows Server 2003 two new replication scopes (= Application Partitions) where introduced: DomainDnsZones and ForestDnsZones. While the first one will replicate to all DCs which also hold the DNS-Server role in that Domain, the second will replicate to all DNS-Server/DCs in the Forest.

Leave a Reply