Securing your DNS using TMG 2010

1. Introduction

Nowadays information is much easier to find than it was in the past, you can find information about pretty much everything by just searching on the web (try for example). For this reason it is even more important to be diligent while protecting your company’s data by avoiding data leakage and data enumeration.

One of the pre-attack phases is exactly the enumeration of data for the target system (or company), during this phase the attacker will try to gather as much information as possible about the target, going from the basic stuff that it can find about the target on the company’s web site to a more detail data enumeration using tools and techniques. One of the steps for data enumeration is query the target DNS system in order to obtain more information about hosts and IPs. This process can start by simply using the nslookup command. Assuming a successfully query, the attacker can try to transfer all the information for that domain by attempting a zone transfer operation. This post will explain how to configure your DNS Publishing rule on TMG to avoid zone transfer.

2. What you want to avoid?

The scenario that I described above is an unfortunate common scenario, many times because the system administrator forgot to securely configure the DNS Server on the internal network to not allow zone transfer for all systems. Here an example of a DNS that is wide open for zone transfer:


When this configuration is place the following result will happen if the client tries to transfer a zone using nslookup:

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

Default Server: mysrv
> server
Default Server: TMGFW

> set q=all


Server: TMGFW
Address: internet address = nameserver =
primary name server =
responsible mail addr =
serial = 494
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour) internet address =

> ls -d

[TMGFW.home] SOA (494 900 600 86400 3600) A NS
_msdcs NS
_gc._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=3268,
_kerberos._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=88,
_ldap._tcp.Default-First-Site-Name._sites SRV priority=0, weight=100, port=389,
_gc._tcp SRV priority=0, weight=100, port=3268,
_kerberos._tcp SRV priority=0, weight=100, port=88,
_kpasswd._tcp SRV priority=0, weight=100, port=464,
_ldap._tcp SRV priority=0, weight=100, port=389,
_kerberos._udp SRV priority=0, weight=100, port=88,
_kpasswd._udp SRV priority=0, weight=100, port=464,
casrv A
dc01 A
DomainDnsZones A
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones SRV priority=0, weight=100, port=389,
_ldap._tcp.DomainDnsZones SRV priority=0, weight=100, port=389,
farm CNAME
ForestDnsZones A
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones SRV priority=0, weight=100, port=389,
_ldap._tcp.ForestDnsZones SRV priority=0, weight=100, port=389,
WKSVista A SOA (494 900 600 86400 3600)

Well, this is not nice at all…here it is my whole internal domain zone exposed to all Internet users just because the system administrator forgot to disable one checkbox.

3. Protecting Internal Resources

If system administrator didn’t do his homework, you as firewall admin MUST do it ASAP. However it is very important to emphasize that this band aid solution on the perimeter shouldn’t be the main one, we always need to fix the root cause of the problem, which in this case is to securely configure the DNS Server. The fact that you are protecting the DNS Publishing on your perimeter is just a countermeasure to avoid a potential attempt to transfer the internal DNS zone to an external (non trusted) resource.

The DNS Filter on TMG is enabled by default as shown below:


This filter has the following capabilities pre-configured by default:

  • DNS_Intrusion_detection= 1
  • DNS_Hostname_Overflow=1
  • DNS_Length_Overflow=1

As zone transfer can or cannot be a legitimate type of access the parameter DNS_Zone_Transfer is set to 0 by default. In other words: if you want to allow zone transfer you should leave this parameter as is. The recommendation is to make sure to allow zone transfer only to trusted DNS servers, which means that you should configure your DNZ zone to allow transfer only for the server’s IPs that you trust. If all the servers that you trust are behind TMG (on the internal network) then you can safely block zone transfer attempts from traffic coming from the external (Internet) network. To do that you need to run the following script:

Set root = CreateObject("FPC.Root")
Set isaArray = root.GetContainingArray()
Set attackDetection = isaArray.ArrayPolicy.AttackDetection
Set dnsFilter = isaArray.Extensions.ApplicationFilters.Item("{49FE2B2F-3BB4-495C-87C8-3890C3C35756}")

dnsFilter.Enabled = True
Set vpSets = dnsFilter.VendorParametersSets

On Error Resume Next
vpSets.Add "{D96C5E7F-5B13-4E1A-94A1-36CA7B54604E}", False, False
On Error Goto 0 ‘ If a vendor parameters sets for DNS Filter already exists

vpSets.Item("{D96C5E7F-5B13-4E1A-94A1-36CA7B54604E}").Value("DNS_Zone_Transfer") = "1"


…OR you can also use the UI to make this change using the option below:


Note: if you run the script while the console is open and you try to see if this option is enabled on the UI, the option might still be disabled. To refresh it, close TMG console and open it again.

After running this script (or changing it on the UI), make sure to restart Firewall Service and then try again to run the nslookup ls command from an external computer. The expected result is shown below:

> ls -d


*** Can’t list domain Unspecified error

The DNS server refused to transfer the zone to your computer. If this is incorrect, check the zone transfer security settings for on the DNS server at IP address

Now this for sure is a better result for an external user to get it.

Comments (0)