WindowsNetworking.com Monthly Newsletter of August 2008 Sponsored by: GFI

Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@windowsnetworking.com

1. More on DNS Forwarding, Forwarders and Slave Servers

Last month we talked about how the domain name system works how DNS queries are formulated. This month we will complete the story by getting into the details of DNS forwarders and slave servers.

DNS Forwarders and Slave Servers

A DNS Forwarder is a DNS server that accepts recursive queries from another DNS server.  Caching only servers make good forwarders. A caching-only forwarder can be used to protect internal zone files from Internet access.

A Caching-only DNS Server is one that does not contain any zone database files. A Caching-only server can only answer DNS queries by either performing iterative queries, or by answering directly from entries contained in its cache.

Let's look at an example. A DNS client sends a recursive query to its Preferred DNS server. The query is for a host in a domain for which the DNS Server is not authoritative and it does not contain the answer in its cache.

The Preferred server must resolve the host name for the client or return a "host not found" or similar DNS error. To solve this problem, you can configure the DNS client's DNS server to forward or pass-on all queries for which it is not authoritative to another DNS Server. In this case, your DNS server issues a recursive query to another DNS server called a forwarder. 

Forwarding and Forwarder Servers

When talking about Forwarders, the terminology can get a little tricky. In our example, the client's Preferred server is forwarding the request to the forwarder. The client's DNS server is the forwarding DNS server. The DNS server receiving the forwarding server's query is the Forwarder. Therefore, the process of forwarding a DNS query involves both a forwarding DNS server and a Forwarder DNS server.

Resolving FQDNs Using Forwarders

When the Forwarder receives a query from a forwarding DNS Server, it can resolve the request by retrieving the information from its cache, from a zone file, or by issuing a series of iterative queries. The forwarding server completes its recursion by returning this IP address to the DNS client that initiated the query.

If the forwarder cannot resolve the hostname to an IP address, it will return to the forwarding DNS server a "host not found" error. If this happens, the forwarding DNS server will attempt to resolve the host name itself. The forwarding server will perform its own iterative queries to resolve the host name. If unsuccessful, a "host not found" or similar error is finally returned to the client.

"Get That Internet Away from Me!"

You may not want the forwarding DNS server to issue iterative queries to servers located on the Internet. This may be true when the forwarding server is an internal DNS server, since you really would like to avoid Internet hosts from having direct "contact" with your internal DNS Server, which might contain information about your internal DNS zones. Internal DNS servers that issue iterative queries for Internet host name resolution can become potential prey for hackers.

You can configure the forwarding server to not resolve host names when the forwarder fails to return a valid IP address. When the forwarding computer is configured in this way, it is referred to as a Slave server. The Slave server accepts responses from the forwarder and relays them to the client and never attempts to resolve host names via iterative queries.

It is a good idea to disable recursion on machines that use Forwarders. If the Forwarder was unable to answer the query, what is the likelihood that the forwarding DNS server will be able to do so? By disabling recursion on the forwarding server, you reduce the amount of network traffic that would have been generated by attempts to resolve the host via iterative queries that already didn't work for the Forwarder.

Forwarders and Firewalls

To stave off Internet intruders from poaching your DNS records, you can implement a combination of Slave and Caching-only DNS Servers. We can use this combination to prevent users on the other side of a firewall from having access to information on our Internal DNS Server.

For example, we have an internal DNS server we use to resolve DNS requests for resources inside our corporate environment. As long as the requests are for hosts in our internal network, DNS requests represent no security risk. However, what happens when users on our internal network need to access resources on the Internet?

Let's say a user wants to connect to windowsnetworking.com. When the recursive request arrives at our internal DNS server (which is authoritative only for our internal domain), what does the server do? 

The internal DNS Server begins to issue iterative queries to other DNS servers on the Internet in order to resolve the Internet host names. In the process, Internet DNS servers send their responses directly to our Internal DNS machine. This exposes our internal DNS server, its zone data, and the nature of our requests to users on the Internet. How can we avoid this potentially dangerous situation?

Caching-only Servers Get You Out of Harm's Way

We can place a caching-only Forwarder on the far side of a firewall and configure our internal DNS server to be a Slave server. When one of our internal DNS clients issues a name resolution request for an Internet host to the internal DNS server, the internal server forwards the request to the Forwarder on the outside of the firewall (on a DMZ segment). The firewall is configured so that inbound DNS messages are only allowed from the Caching-only DNS Server that's acting as a Forwarder.

The forwarder attempts to resolve the host name to an IP address. If successful, it will return the IP address to our internal DNS server, who will in turn return the IP address to the client that issued the request. If the forwarder is unsuccessful, it will report that to our internal server, who will report to the client that the host was not found. Our internal Slave server will not attempt to resolve the host name itself. The slave returns what the Forwarder told it to the DNS client and the query fails.

The key here is that at no time does an Internet DNS server send a response directly to our Internal server. The Slave server/Caching only forwarder combination prevents this sort of communication. In this way, our internal zone records are safe.

Summary

We have seen in this article that Internet DNS Servers can use other DNS Servers to perform queries for Internet names. You can configure your internal DNS Server to forward requests for hosts located in domains for which you DNS Server is not authoritative. The DNS Server that receives the request from your internal DNS Server is referred to as a DNS Forwarder.

You can increase the security of your DNS zone database records by preventing Internet hosts from directly interacting with your internal DNS Server. One of the best ways to do this is to use a Slave Server/Caching-only Server combination. When you implement this combination of DNS Servers, no internal zone database records are exposed to Internet hosts.

Got questions about DNS design? Send me your questions about DNS issues at tshinder@windowsnetworking.com and I'll answer them in next month's newsletter!

Thanks!
Tom 

=======================

Quote of the Month - "Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest". - Isaac Asimov

======================

2. ISA Server 2006 Migration Guide - Order Today!

3. WindowsNetworking.com Articles of Interest

• How can Windows Server 2008 WinRM & WinRS help you?
• Troubleshooting Connectivity Problems on Windows Networks (Part 1)
• Deploying Vista – Part 9: Automating the Machine OOBE
• Clearing the Confusion of OU Design
• OSI Reference Model: Layer 4 Hardware
• Troubleshooting Logon Problems
• Special WindowsNetworking.com Offer: Download a free copy of SolarWinds Exchange Monitor!

4. KB Articles of the Month

• The Offer Remote Assistance feature does not work when you use a VPN to connect a Windows Vista-based computer to a corporate network
• When you run the Netproj.exe utility on a Windows Vista SP1-based computer, some network projectors may not be found
• Description of Firewall Ports for Xbox LIVE and Games for Windows LIVE
• You experience issues with UDP-dependent network services after you install DNS Server service security update 953230 (MS08-037)
• How to configure folders to share media that is stored on a Windows Media Center-based computer
• A Windows Vista-based DHCP client computer may lose its IP address after the computer resumes from sleep or from hibernation
• DNS queries that are sent across a firewall do not use random source ports after you install security update 953230 (MS08-037)
• DHCP clients may take a long time to register their names on a DNS server that is running Windows Server 2003

5. Windows Networking Tip of the Month

Sometimes a DNS server will receive a resource record for an Internet host that was valid when the record was returned, but since then the IP address of the machine has changed. Ideally, the TTL on the resource record would be short enough so that the record would expire from the DNS server's cache before the IP address changes, but this is not always the case. The problem is that the inaccurate record will remain in the DNS server's cache until it times out. What you need to do is clear the record from the DNS cache.

If you are running a Windows DNS server, you can do this in the DNS console. Right click on your server name and point to View. Then click Advanced. This will expose the Cached Lookups folder tree. If you want to clear all entries in the cache, then you can right click on the server name and click Clear Cache. If you do not want to clear the entire cache, then you can expand the Cached Lookups folder and then expand the .(root) folder. Find the top level domain that the machine belongs to and then find the second level domain in the right pane. You can delete the entire second level domain, or you can open the second-level domain folder and delete the individual records that you know are obsolete.

6. WindowsNetworking Links of the Month

• Dynamic Host Configuration Protocol for Windows Server 2003
• Dynamic Host Configuration Protocol: Frequently Asked Questions
• DHCP Technical Reference
• DHCP Troubleshooting
• Deploying DHCP

7. Ask Dr. Tom

QUESTION:

Hi Tom,

I have built an SSL VPN system for my company following your article "Configuring windows Server 2008 as Remote Access SSL VPN Server". All configurations and connections are working, but the last step SSTP VPN connection does not work.
My Active Directory Domain Controller server comes with Exchange 2007 SP1. Do I need to change some configuration? Can I install ISA 2006 server on windows server 2003 R2? Could you give my some idea to find out problem?
Thanks - Louis

ANSWER:

Hi Louis,

ISA server is not needed in this scenario. ISA 2006 cannot be installed on Windows Server 2008, and Windows Server 2008 is the only version of Windows to support the SSTP remote access server.

The most common problem with SSTP publishing not working is that you have not correctly published your CRL. Remember, the client is going to check the CRL for the VPN server certificate, and if the client can't find the CRL, the connection will fail. So pay close attention to the information I give about publishing the CRL.

QUESTION:

Dear Dr. Shinder,

I am a Network Administrator in a security company.

I have a problem with certificate configuration on IPsec. We want to establish a secure connection between server and clients, using CA. The server is "win server 2003" and the clients are "win XP, Unix, Linux, and IBM". The solution that I perform was to provide it through IPsec and Certificate Authentication. So I installed "Certification service" on "server2003" and configured it as "enterprise CA". Then define a policy through "IPsec Console" and in "Authentication method" section, I select "use certificate from this certification authority (CA)" option, find and select the mentioned CA from the list.

First problem was that in clients systems the mentioned CA were not in IPsec console list. To solve the problem, I installed "Active Directory" on another win server2003 and joined the client and CA server to the domain; mentioned CA appears in both lists.

Further, create the same policy with the same CA as server, on client. But encounter a problem again. The problem was that the connection not established between server and client. I ping the server from client; and encountered the "Negotiating IP Security" message. For testing, I set the "Kerberos v.5" on "IPsec Authentication Method" on both systems; so the connection established; But, when I using CA IPsec Authentication Method, I miss the connection.

Would you please guide me?

Thanks in Advance. Sincerely yours, Shervin

ANSWER:

Hi Servin,

I think that you are mixing up two different scenarios. In the first scenario, where you are using certificates for IPsec authentication, you are trying to implement server isolation. Server isolation is used when one or more of the machines participating in the IPsec communications is not a domain member. In order to make server isolation work with IPsec, you need to make sure that both machines have an IPsec certificate installed in their machine certificate stores, and that both machines use the CA that issued the machine IPsec certificate.

When machines are all members of the same domain, you can use domain isolation. In this case, you use Kerberos authentication to authenticate the IPsec connections. Machine certificates are still required, and all machines need to trust the CA issuing the machine certificates. Also, remember that you need to exempt some machines from the isolation environment, such as domain controllers, DHCP servers and DNS servers, since both isolated and non-isolated machines need to connect to infrastructure devices. In the case of the domain controller, if you are going to require user authentication as well in the IPsec policy, then you have to make sure the DC is exempt, since there isn't a logged on user at the time that IPsec communications are required.

Got a question for Dr. Tom? Send it to tshinder@windowsnetworking.com.