Wednesday, July 12, 2006
DNS Client :: DNS Resolution Suffixes
What is DNS?
DNS is an interesting, but very well thought-out concept for name-to-IP, IP-to-name, SRV-to-name, and other types of resolution. It is much more versatile than NetBIOS, it's easier to manage, it's more organized, and it just makes sense, plain and simple. DNS also allows you to have multiple servers of the same name, but still be able to tell them apart.
Microsoft's Active Directory relies heavily on DNS and is required for operating an Active Directory Domain. It is required for clients to locate vital services via DNS Service Records (SRV records) such as LDAP, Global Catalogue, and a Kerberos Key Distribution Center (KDC). With this in mind, you ought to realize that without DNS, you can't really have a working Active Directory Domain. So ... what if you have several Active Directory domains and you need to set up proper DNS name resolution on your client machines?
A Multi-Domain Environment
Well, say you have a tri-Active Directory Domain environment with the names DomA.local, DomB.local, and DomC.local, and you need your clients to be able to access resources in each of these domains (in case you haven't guessed, this is the scenario at my current employer). Well, normally (I shouldn't say normally, because these are all old technologies), your clients would resolve names via NetBIOS broadcasts, a HOSTS file (ugh), or WINS, but WINS is dying, so we're left with a pure DNS environment (ahhhhhh, when properly set up, DNS is best). So your clients are most likely pointed to whichever DNS server is authoritative for the client's domain, and when you ping a resource by hostname alone, everything works okay, right? Well, that depends entirely on which domain you are trying to access a resource in. If your client is a member of DomA.local, is pointed at the authoritative server for that domain, and you're trying to access a resource in DomB.local by only its hostname (eg. server01), chances are that you'll be unable to resolve its name properly. Why is this?
A Scenario of Ambiguous Names
When a DNS client attempts to resolve a name in DNS, it must resolve its Fully Qualified Domain Name (FQDN) because you could have an identically named resource that's in a different domain. The DNS suffix (the actual domain name itself) is what separates an identically named resource in DomA.local, DomB.local, and even DomC.local. What this means is that if you have a server named server01 in each of your three domains, your clients would have to resolve it via its FQDN to void the ambiguity of the three identically named servers. So how can you avoid having to type the FQDN of a server if it has an similarly named twin in another domain? Well, you can't! But there is a way to tell your clients which one to locate first, and this is what we'll investigate below.
Also ...
Another scenario may be this: You have a client that is a member of DomA.local. The client needs to resolve the IP of server99.DomB.local, but doesn't specify the domain name (aka domain suffix), only the hostname (server99). If it doesn't try to append DomB.local when resolving the name, it will fail, because DomA.local doesn't have a server99, and it stops there. You must instruct the client to append DomB.local when trying to resolve the hostname in order for it to work properly (this is assuming that your DNS Administrator has properly set up conditional forwarding for each of the domains).
So What Do I Have to Change?
Once you know how the setting is stored, you can then decide on how to change the given setting. The setting in question is a comma-separated string value stored in the HKEY_LOCAL_MACHINE registry hive on each computer. Here is the full path: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\SearchList. So in order to change this setting, all you need to do is figure out what domains you have (DomA.local, DomB.local, and DomC.local), and decide on what order you would like clients to resolve names in. In most, if not all, circumstances your clients should first try the domain suffix which they are a member of (eg. client is member of DomA.local, and should therefore attempt to resolve names to that domain first) so that they can contact Domain Controllers and such properly, but beyond that it's basically up to you what order you'd like them to try name resolution in. Basically, you'll end up having a string value looking like "doma.local,domb.local,domc.local". If you ever add a 4th domain (DomD.local), just append a comma and the domain name to it.
And How Do I Change It?
In Windows, the DNS client's Default Search Suffix(es) is configurable via the TCP/IP properties of a particular network adapter. This setting tells the client which Domain Names (aka Suffixes) to append to a hostname, when only a hostname is provided, to attempt to resolve its name. Multiple domains can be specified, and the top one is always tried first, followed by the 2nd, 3rd, and so on. If none of the FQDNs generated by appending the suffix to the hostname can be resolved, the client will fail. Setting this option through the Windows GUI is easy (see screenshot), but how, as a desktop administrator, can you configure this option on 10 clients at once? What about 50, or 500?
I Knew You'd Say That ...
Yes indeed, once again in our lifetime, we'll need to write a script to change this. As you probably can recall from a previous article, I showed you how to change registry data with a Visual Basic Script plus the added strength of WMI. You don't need WMI and can also change registry data with a Wscript.Shell object which we'll review here briefly; The nice thing about WMI is that you can run one script locally on your management workstation or server, instead of having to delpoy a script to all your workstations. We'll write one script to see how to change the actual registry value using a Wscript.Shell object, and then we'll write a script with WMI and ADSI/LDAP to grab all your computer accounts from your Active Directory domain, and connect to each of them to change this value. Here goes:
'Create a shell object
set myShell = CreateObject("Wscript.Shell")
'Write the registry value
myShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\SearchList","doma.local,domb.local,domc.local"
Simply save that text to a file with a vbs extension and double-click it. OMG was that hard or what? Two lines of actual code to accomplish our simple administration task? It cannot be! My hope is that you realize that programming/scripting is not as hard as it seems, and that you too can master it even if you haven't started, or just recently starting learning it. The code to connect to a directory service and use WMI is almost just as easy, it's just a little bit more code. For simplicity purposes, this script will assume that all your computer objects are in the default Computers container in Active Directory.
'Get the RootDSE LDAP object
set oLDAP = GetObject("LDAP://RootDSE")
'Extract the domain name in LDAP format
myDomain = oLDAP.Get("defaultNamingContext")
'Get the default computers container in your domain
set oLDAP = GetObject("LDAP://cn=computers," & myDomain)
'For each computer object in the computers container, call the updateDNSSearchOrder method with the computer's name LDAP attribute
for each item in oLDAP
if item.class = computer then updateDNSSearchOrder(item.name)
next
'Create a function that takes the target PC name as a parameter
function updateDNSSearchOrder(computername)
'Get a WMI object on the remote machine pointing to the StdRegProv class in the root\default namespace
set objWMI = GetObject("winmgmts:\\" & computername & "\root\default:StdRegProv")
'Set the string value using the SetStringValue method of the StdRegProv class. Note the comma at the beginning. Because HKEY_LOCAL_MACHINE is the default hive, you don't need to specify the value for it
objWMI.SetStringValue ,"SYSTEM\CurrentControlSet\Services\TcpIp\Parameters","SearchList","doma.local,domb.local,domc.local"
end function
There, that wasn't so bad was it? If you remove all the comments in the code, it's only a few lines long, in fact it's exactly 10! Not bad at all for making a domain-wide change! Anyway, I hope you learned something from this tutorial! Feel free to e-mail me if you have any questions at pcNOgeekSPAM101@gmail.com!
¶ 9:45 AM
DNS is an interesting, but very well thought-out concept for name-to-IP, IP-to-name, SRV-to-name, and other types of resolution. It is much more versatile than NetBIOS, it's easier to manage, it's more organized, and it just makes sense, plain and simple. DNS also allows you to have multiple servers of the same name, but still be able to tell them apart.
Microsoft's Active Directory relies heavily on DNS and is required for operating an Active Directory Domain. It is required for clients to locate vital services via DNS Service Records (SRV records) such as LDAP, Global Catalogue, and a Kerberos Key Distribution Center (KDC). With this in mind, you ought to realize that without DNS, you can't really have a working Active Directory Domain. So ... what if you have several Active Directory domains and you need to set up proper DNS name resolution on your client machines?
A Multi-Domain Environment
Well, say you have a tri-Active Directory Domain environment with the names DomA.local, DomB.local, and DomC.local, and you need your clients to be able to access resources in each of these domains (in case you haven't guessed, this is the scenario at my current employer). Well, normally (I shouldn't say normally, because these are all old technologies), your clients would resolve names via NetBIOS broadcasts, a HOSTS file (ugh), or WINS, but WINS is dying, so we're left with a pure DNS environment (ahhhhhh, when properly set up, DNS is best). So your clients are most likely pointed to whichever DNS server is authoritative for the client's domain, and when you ping a resource by hostname alone, everything works okay, right? Well, that depends entirely on which domain you are trying to access a resource in. If your client is a member of DomA.local, is pointed at the authoritative server for that domain, and you're trying to access a resource in DomB.local by only its hostname (eg. server01), chances are that you'll be unable to resolve its name properly. Why is this?
A Scenario of Ambiguous Names
When a DNS client attempts to resolve a name in DNS, it must resolve its Fully Qualified Domain Name (FQDN) because you could have an identically named resource that's in a different domain. The DNS suffix (the actual domain name itself) is what separates an identically named resource in DomA.local, DomB.local, and even DomC.local. What this means is that if you have a server named server01 in each of your three domains, your clients would have to resolve it via its FQDN to void the ambiguity of the three identically named servers. So how can you avoid having to type the FQDN of a server if it has an similarly named twin in another domain? Well, you can't! But there is a way to tell your clients which one to locate first, and this is what we'll investigate below.
Also ...
Another scenario may be this: You have a client that is a member of DomA.local. The client needs to resolve the IP of server99.DomB.local, but doesn't specify the domain name (aka domain suffix), only the hostname (server99). If it doesn't try to append DomB.local when resolving the name, it will fail, because DomA.local doesn't have a server99, and it stops there. You must instruct the client to append DomB.local when trying to resolve the hostname in order for it to work properly (this is assuming that your DNS Administrator has properly set up conditional forwarding for each of the domains).
So What Do I Have to Change?
Once you know how the setting is stored, you can then decide on how to change the given setting. The setting in question is a comma-separated string value stored in the HKEY_LOCAL_MACHINE registry hive on each computer. Here is the full path: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\SearchList. So in order to change this setting, all you need to do is figure out what domains you have (DomA.local, DomB.local, and DomC.local), and decide on what order you would like clients to resolve names in. In most, if not all, circumstances your clients should first try the domain suffix which they are a member of (eg. client is member of DomA.local, and should therefore attempt to resolve names to that domain first) so that they can contact Domain Controllers and such properly, but beyond that it's basically up to you what order you'd like them to try name resolution in. Basically, you'll end up having a string value looking like "doma.local,domb.local,domc.local". If you ever add a 4th domain (DomD.local), just append a comma and the domain name to it.
And How Do I Change It?In Windows, the DNS client's Default Search Suffix(es) is configurable via the TCP/IP properties of a particular network adapter. This setting tells the client which Domain Names (aka Suffixes) to append to a hostname, when only a hostname is provided, to attempt to resolve its name. Multiple domains can be specified, and the top one is always tried first, followed by the 2nd, 3rd, and so on. If none of the FQDNs generated by appending the suffix to the hostname can be resolved, the client will fail. Setting this option through the Windows GUI is easy (see screenshot), but how, as a desktop administrator, can you configure this option on 10 clients at once? What about 50, or 500?
I Knew You'd Say That ...
Yes indeed, once again in our lifetime, we'll need to write a script to change this. As you probably can recall from a previous article, I showed you how to change registry data with a Visual Basic Script plus the added strength of WMI. You don't need WMI and can also change registry data with a Wscript.Shell object which we'll review here briefly; The nice thing about WMI is that you can run one script locally on your management workstation or server, instead of having to delpoy a script to all your workstations. We'll write one script to see how to change the actual registry value using a Wscript.Shell object, and then we'll write a script with WMI and ADSI/LDAP to grab all your computer accounts from your Active Directory domain, and connect to each of them to change this value. Here goes:
'Create a shell object
set myShell = CreateObject("Wscript.Shell")
'Write the registry value
myShell.RegWrite "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\SearchList","doma.local,domb.local,domc.local"
Simply save that text to a file with a vbs extension and double-click it. OMG was that hard or what? Two lines of actual code to accomplish our simple administration task? It cannot be! My hope is that you realize that programming/scripting is not as hard as it seems, and that you too can master it even if you haven't started, or just recently starting learning it. The code to connect to a directory service and use WMI is almost just as easy, it's just a little bit more code. For simplicity purposes, this script will assume that all your computer objects are in the default Computers container in Active Directory.
'Get the RootDSE LDAP object
set oLDAP = GetObject("LDAP://RootDSE")
'Extract the domain name in LDAP format
myDomain = oLDAP.Get("defaultNamingContext")
'Get the default computers container in your domain
set oLDAP = GetObject("LDAP://cn=computers," & myDomain)
'For each computer object in the computers container, call the updateDNSSearchOrder method with the computer's name LDAP attribute
for each item in oLDAP
if item.class = computer then updateDNSSearchOrder(item.name)
next
'Create a function that takes the target PC name as a parameter
function updateDNSSearchOrder(computername)
'Get a WMI object on the remote machine pointing to the StdRegProv class in the root\default namespace
set objWMI = GetObject("winmgmts:\\" & computername & "\root\default:StdRegProv")
'Set the string value using the SetStringValue method of the StdRegProv class. Note the comma at the beginning. Because HKEY_LOCAL_MACHINE is the default hive, you don't need to specify the value for it
objWMI.SetStringValue ,"SYSTEM\CurrentControlSet\Services\TcpIp\Parameters","SearchList","doma.local,domb.local,domc.local"
end function
There, that wasn't so bad was it? If you remove all the comments in the code, it's only a few lines long, in fact it's exactly 10! Not bad at all for making a domain-wide change! Anyway, I hope you learned something from this tutorial! Feel free to e-mail me if you have any questions at pcNOgeekSPAM101@gmail.com!
¶ 9:45 AM
