DNS and DFS

There is a lot of outdated and unclear documentation about configuring DFS Namespaces with the fully qualified name (host.company.com) versus the NetBIOS name (HOST).  I have some authoritative guidance that arose as part of a client troubleshooting effort, and I wanted to share it with you.

You can use either format (DNS FQDN or NetBIOS Hostname) for the target of a DFS-N folder (aka “link”). 

When a client requests a referral from DFS, DFS passes the referral in whatever format you’ve used, and the client does not modify it.  The client uses the standard Windows name resolution processes to resolve the referral to an IP address, which typically will use DNS. If a hostname-only referral was passed, the client will use either domain name devolution (where it takes it’s DNS suffix and appends it to the hostname, then removes each “subdomain” from the suffix until it reaches a top-level domain), or a DNS suffix search order.

The potential for timeouts and other name resolution problems using a host-only name for any network path are huge.  So the rule is always use FQDNs.  Always, not just for DFS.  For mapped drives, for redirected folder & roaming profile configurations… always. 

Therefore, by ‘transitive properties’ :-), you should always use FQDNs for your DFS folder target referrals.  You don’t have to, but you should.

The documentation on the ‘net related to hostname-only vs. FQDN paths is for the DFS namespace root referral targets only. You can use Network Monitor to watch the root referral process.  Once the namespace server has been located, links are links (FQDN or host).  So KB244380 and other documentation referring to the DfsDnsConfig registry entry are about the root and only the root, so that clients without solid DNS can find a DFS namespace server (root target).  Why Microsoft continued the behavior of hostname only root referrals after DFS became tightly integrated with Active Directory (which of course requires a solid DNS infrastructure)… who knows… but that’s the deal.