Posts tagged ‘dns’

Access a resource using the same internal and external FQDN

For simplicity there are many reasons you may want a single URL or FQDN to access a resource internal or external to your corporate domain.  If the internal and external domain names are the same it can sometimes cause DNS issues resolving the public domain name from the corporate network.  I am often asked about this in reference to web sites; “why is our website accessible from anywhere but our buisiness network””?”   For example you want to access from a network that uses the internal domain net-works.local.  The internal DNS server manages DNS for net-works so it doesn’t pass on the request to the forwarder, but it also doesn’t have a DNS record for the www Host.  The simple solution is to create an internal zone for the host name you are trying to access. SBS 2008/2011 did this automatically for “remote” so that the same URL could be used internally and externally.  This technique can be used for access ing websites, dvr systems, or anything you like that uses a FQDN.

To do so open the DNS management console, expand the folders under your server name, right click on the “Forward Lookup Zones folder, and select New Zone.  A wizard starts, click next and you can select the zone type.  Accept the defaults, Primary Zone and next.


Select “To all DNS servers running on domain controllers in this domain”.


In this case I am going to set up a universal URL for access to a DVR system, so I will enter  This could be www, remote, or what ever meets your needs.  Keep in mind for external access you must set up the DVR, or matching,  Host record with whichever service manages DNS for your public domain.


Again accept defaults, and click next, and finish.


Now right click on the new zone folder and choose “New Host (A or AAAA)” record. Finally, again accept defaults except insert the IP address.  In this case it is an internal IP.  There should be no need for a PTR record creation.


When complete it should look similar to this:


Remotely change DNS server IP’s

I was recently asked how to change the DNS server IP’s in the NIC configurations of numerous servers, which of course have static IP’s.  Sounds simple right?  Maybe not.

  • You can use Group Policy to do so but apparently it will not work with all O/S’s and it will only work if DNS is working. 
  • You can deploy a script but that requires logon or reboot to apply. 
  • You use psexec and a text file list of servers with something similar to: “psexec @textfilename netsh interface ip set dns name = “Local Area Connection” source = static addr =”  however it requires the NIC name be accurate and it is not always named “Local Area Connection”

One proposed great solution is to use a VBS script by Alexxxandre K8L0 on TechNet.  This uses a text file list of server names or IP’s and updates each in the list.  The article can be found in the following link, but since occasionally the links change or articles ‘disappear’ I have posted the content here, but I take no credit for its design:

Syntax: cscript SetDNSv2.vbs inputfile outputfile dns_ips
Input file: Put IP or Hostname of server line by line on a text file.
Output file: Is a log of return status “Inputed,Host,Adapter,Return Status”
dns_ips: Ips of DNS Servers separated by commas.
Example: cscript SetDNSv2.vbs inputfile.txt outputfile.txt,,

‘Set DNS By k8l0
‘By k8l0
If WScript.Arguments.Count = 3 Then
    strInputFile = WScript.Arguments.Item(0)
    strOutputFile = WScript.Arguments.Item(1)
    strNewDNS = WScript.Arguments.Item(2)
    wscript.echo “Sintaxe: cscript SetDNSv2.vbs inputfile.txt outputfile.txt,,”
end if    
On error resume next
Const ForReading = 1
Const ForAppending = 8
Set objFSO = CreateObject(“Scripting.FileSystemObject”) 
Set objTextFileIn = objFSO.OpenTextFile(strInputFile, ForReading)
Set objTextFileOut = objFSO.OpenTextFile(strOutputFile, ForAppending, True)
wscript.echo “Host        Adapter        Return Status”
wscript.echo “—-        ——-        ————-”
objTextFileOut.WriteLine(“Inputed,Host,Adapter,Return Status”)
Do Until objTextFileIn.AtEndOfStream 
    strComputer = Trim(objTextFileIn.Readline)
    Set objWMIService = GetObject(“winmgmts:” & “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2”)
    Set colNicConfigs = objWMIService.ExecQuery(“SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True”)
    For Each objNicConfig In colNicConfigs
        If Not IsNull(objNicConfig.DNSServerSearchOrder) Then
            strReturn = “”
            arrNewDNSServerSearchOrder = Split(strNewDNS,”,”)
            intSetDNSServers = objNicConfig.SetDNSServerSearchOrder(arrNewDNSServerSearchOrder)
            If intSetDNSServers = 0 Then
                strReturn = “””” & “Replaced DNS server search order list to ” & strNewDNS & “.” & “”””
                strReturn = “Unable to replace DNS server search order list.”
            End If
            strReturn = “DNS server search order is null. Nothing changed!”
        End If
        strDNSHostName = objNicConfig.DNSHostName
        strIndex = objNicConfig.Index
        strDescription = objNicConfig.Description
        strAdapter = “Network Adapter ” & strIndex & ” – ” & strDescription
        wscript.echo strDNSHostName & VBTab & strAdapter & VBTab & strReturn
        objTextFileOut.WriteLine(strComputer & “,” & strDNSHostName & “,” & strAdapter & “,” & strReturn)
wscript.echo “Finished!!!”

Hosts and LMHosts files

Though rare, there still is an occational need or advantage to using Hosts and LMHosts files.  Though simple text files, the syntax used is critical.  The following is a repost from an older blog of mine.  I have done so in hopes that it may be helpful to some folk, and also it will be useful in and upcoming post regarding Hyper-V configuration and management.

There are two files in the %systemroot%\system32\drivers\etc directory that can be used for name resolution. The Hosts file, used for DNS name resolution, and the LMHosts.sam file used for NetBIOS name resolution. In an age where DNS dominates your network both locally and throughout the Internet, these two files are seldom ever used, but they can be very useful in a few situations. Both are simple text files that match names to IP addresses, and are very easy to create and implement. Most people are familiar with these files, but are often frustrated when they do not work as expected. This is usually due to the fact that they have some very simple, but specific requirements, for them to work at all.

LMHosts (NetBIOS names):

The primary use today for an LMHosts file, is for name resolution over a VPN. If DNS is configured on the host and client machines there should be no need of static text files for resolving names, but it does work well, and many folks uses them as a dependable simple solution. The catch is there are a few gotcha’s you need to be aware of:

  • The LMHosts file in it’s default form, is named lmhosts.sam The .sam represents sample. If you are planning on using this file it needs to be saved without a file extension – lmhosts. Be careful if using a text editor like NotePad as it will add a .txt file extension to the name. The safest method is to save the file using quotes, “lmhosts” to assure no extensions are added.
  • Text following a # in the LMHosts file is a comment and can be ignored or deleted.
  • A typical entry would look like: COMPUTERNAME #PRE #my notes

  • When making a new entry you must hit enter at the end of the line, which adds a “carriage return”
  • Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.
  • Though it is not needed, adding the #PRE parameter or extension will load the entry into the local NetBIOS name cache when the computer boots. This allows for a slightly faster resolving of the name, before it has been added to the cache.
  • Most entries such as #PRE, #DOM, DOMAIN names and such are case sensitive. Always use uppercase to be safe.
  • It is a good idea to add the domain name as well. This requires two lines, and uses extremely critical formatting. A sample would be: DCNAME #PRE #DOM:YOUR-DOMAIN “YOUR-DOMAIN x1b” #PRE

There must be exactly 20 characters, including spaces, between the quotes in “YOUR-DOMAIN x1b”, and the spaces need to be between the domain name and the x1b. The domain name used is the NetBIOS name, not the FQDN. If your domain name exceeds 15 characters, you must truncate it at the 15th character, it will still work.

If you find this last step tedious, the University Of Sait Louis has a little Java script that will create these two lines for you:

Hosts (DNS names):

The Hosts file today seems to be more used for blocking unwanted web sites. This is done by simply entering the website address and substituting the IP address with the localhost IP address such as: site

There are subscription services that will actually update your Hosts file, according to a schedule, with a list of known unwanted sites.

Another handy use of the Hosts file is to create abbreviations for your own use. For example quick access to a website like Google can be achieved adding an abbreviation like ‘G”, or your firewall with ‘F”, or I frequently uses it for accessing client sites with remote desktop using 3 letter acronyms such as ACL for Acme Corp Ltd. : G #Google F #my firewall ACL #Acme Corp Ltd

Most of the rules that apply to the LMHosts file, apply to the Hosts file as well:

  • The Hosts file already has no file extension, so there is no need to change it like the LMHosts file. Just be careful when editing you don’t accidentally add one such as .txt when using NotePad or a similar editor.
  • Text following a # in the Hosts file is a comment, and can be ignored or deleted
  • A typical entry would look like: FTP site

  • When making a new entry you must hit enter at the end of the line, which adds a “carriage return”
  • Use the Tab key between items in each line rather than spaces (recommended but not necessary), but there must be a space.

Keep in mind when editing these files you can run into conflicts, or ineffective changes if you do not reboot or purge the local name caches. To clear the NetBIOS cache ( and PREload), at a command line enter (R is case sensitive):

nbtstat -R

To clear the DNS cache, at a command line enter:

ipconfig /flushdns

For the record, the Hosts file can also be used for IPv6 addressing. Vista for example includes the IPV6 localhost entry, by default:

::1 localhost

Google Apps and DomainsAtCost Registrar

Probably only a select few will encounter this problem as it would only affect those setting up DomainsAtCost as a Domain registrar and DNS manager, in combination with Google Apps. However, there are many posts stating folk are unable to configure Google Apps with this registrar as Google cannot verify the domain ownership due to it not recognizing the necessary DNS Txt  record. Perhaps the few having problems ‘resolving’ this issue may find it helpful.

Before Google will activate your new Google Apps account it understandably needs to verify domain ownership. There are several ways to do so relating to your web site but if you do not have a website for your domain, you are limited to adding a DNS record with whomever manages DNS for your Domain. In the past Google requested you create a Host [A} record, but a year ago they switched to using Txt records. The Google instructions are simple and straight forward, you just enter a lengthy 68 character text string in the “Text” box and then either leave the “Host” box empty or enter an @ symbol.  (see: )image

However if you are with DomainsAtCost and using their Advanced DNS Management the @ symbol is the catch. Their site instead requires you manually enter the domain name in the Host field. Doing so will very quickly update DNS and allow Google apps to verify your domain ownership. The DomainsAtCost site will accept the @ but it will not be resolvable by internet based DNS servers. i.e. it doesn’t work. You can test if your Txt record has propagated to public DNS servers by entering  in the MX lookup box at

Once domain ownership has been verified by Google you can continue the set up by adding your MX records to your DomainsAtCost DNS configuration. It is interesting though that in the DomainsAtCost Host field for the MX record, which does require the domain name, if you insert the @ character when you save it it will automatically convert to the domain name. This does not happen in the Txt record Host field.

Tag Cloud