There is much to think about in the design of your network perimeter for Office Communications Server-several services are offered in the perimeter network through the Edge Servers. The primary goal when implementing a split-brain DNS solution is to provide a near total disassociation of the internal DNS servers and the perimeter DNS servers. This provides easier and faster resolution for clients and prohibits an external DNS server from initiating communications with your internal DNS. This article explores several design considerations and explains why it is important to include a perimeter DNS server in your network topology.
Author: Rick Kingslan
Publication date: December 2009
Product version: Office Communications Server 2007 and 2007 R2
Office Communications Server 2007 and Office Communications Server 2007 R2 use perimeter networks and Edge servers for external user access. Reverse proxies are almost always used, and the addition of Communicator Web Access adds to the perimeter network design requirements.
Services offered in the perimeter network through the Edge Servers include the following:
- Access Edge services for Session Initiation Protocol (SIP)
- Web Conferencing services for Live Meeting
- Audio/Video services for voice and audio
TA reverse proxy is responsible for making available internal services such as the Address Book Server and Group Expansion. Presentation materials from the internal Web conferencing content stores are also served to external clients through the reverse proxy. The Communicator Web Access server is also made available through the reverse proxy.
This article explores these design considerations and explains why it is important to include a perimeter DNS server in your network topology.
|
Note: |
|
This article assumes that the reader is conversant and knowledgeable about Domain Name System (DNS) and the configuration of DNS on the Windows Server 2003 and newer platforms. Resources are cited at the end of the article that will provide more detail about basic DNS concepts. |
Why You Should Include a Perimeter DNS Server in Your Design
When determining the requirements and designing your perimeter for Office Communications Server, if you are currently not using a DNS server in your perimeter for name resolution, you are likely already using one of the two following solutions:
- Internally located DNS servers are providing services for the perimeter network.
- Internet service provider (ISP) DNS is providing services for external name resolution.
While either of these could be used for Office Communications Server, some technical and security-based issues to consider are the following:
- ISP-based DNS may not be dynamic enough for your future purposes with the more complex perimeter that is introduced in Office Communications Server.
- Internal-only DNS solutions can present challenges because external users (known and unknown to you) will be accessing an internal server for name resolution.
- Some ISPs may not support SRV DNS records, which are required for external user automatic configuration and for federation.
- Your internal domain naming is different than your externally known name. For example, your external name is contoso.com, while your internal domain is contoso.local, and you do not want to host the perimeter zone on your internal DNS server.
The primary goal when implementing a split-brain DNS solution is to provide a near total disassociation of the internal DNS servers and the perimeter DNS servers. What this ends up providing is easier and faster resolution for clients and the prohibiting of an external DNS server initiating communications with your internal DNS. There are no zone transfers from the external or internal DNS servers to the other. This measure assures that your internal IP addresses and server naming does not accidentally end up on a publicly accessible DNS server-or worse-propagated to your ISP.
|
Note: |
|
For the rest of this article, the term "client" is meant to indicate client software such as Office Communicator or a Web browser, and could mean the Windows operating system for DNS client resolution processes. The term "user" is meant to indicate the person using the client software. |
How DNS Works in a Split-Brain Configuration
It was mentioned that DNS resolution is faster. Why is this? The simple answer is the client is configured to use a specific DNS server that is local to the client (usually an internal DNS or an ISP-provided DNS server), and those DNS servers have the ability to query DNS servers with more information about other domains. If the client requests information for a domain that the DNS server does not have information for, the DNS server will query other configured DNS servers and these DNS servers will have more authoritative information. After an authoritative DNS server is located, the query is resolved and the result sent back to the client.
But what if the client is internal and the query that it sends to its local DNS asks about a host that is not on the internal network? The internal DNS server should forward any query that it cannot answer to the next most authoritative server-the ISP DNS. How this results in faster DNS resolution for the typical client setup is that a domain name that is requested is compared against the domains that the client's configured DNS servers knows about. And if they don't have local knowledge of the requested domain, forward it to a more authoritative server. The process of referring to more authoritative servers continues until the DNS server that holds the Start of Authority (SOA) record is located, and the requested records (with associated IP address) are returned to the client.
Internal and Perimeter DNS Hosting the Same Domain
Looking at a simple scenario, pictured in Figure 1, there is the internal network with a user and client and a DNS server. The perimeter network contains the reverse proxy, Edge Server and another DNS server. On the Internet is an external user and client as well as the ISP's DNS server.
Figure 1. Perimeter and internal network DNS servers indicating query flow
If we consider that the internal DNS and the perimeter DNS are both hosting domains for contoso.com (Figure 1), this means that our externally known and internally known FQDNs will use the suffix contoso.com. For example, the Web server for this scenario would be www.contoso.com and would be hosted in the perimeter network. Also, our Office Communications Server pool would be known as pool01.contoso.com on the internal network.
Reviewing the query/response patterns in the same domain name example and referring to Figure 1:
-
The Internal client queries for pool01.contoso.com and the internal DNS responds with the IP address for pool01.contoso.com.
The client on the internal network queries for sip.litwareinc.com, which is a federated partner domain not directly known to your DNS. The internal DNS does not know about this domain, and knows to send all failed queries to the next most authoritative server which is located at the ISP. The ISP DNS is more knowledgeable of other domain names on the Internet.
The query from the external client happens in two parts.- The external client queries the ISP DNS for sip.contoso.com, which is the domain name of our Access Edge. The client sends a query request to the ISP DNS.
- The ISP DNS refers the query to the known most authoritative server which is the DNS server in the contoso.com perimeter. The response is the IP address of the Access Edge in the perimeter.
For this scenario, we would define the following A records in Table 1. The listed SRV records in Table 2 would allow for automatic configuration of Office Communicator clients and federated scenarios.
Table 1. DNS host A records required for contoso.com perimeter DNS server
|
Host A and Service SRV Records |
Points to |
Purpose |
|
www |
Web server |
Defines the IP address of the Web server hosted in the perimeter |
|
im |
Access edge of Edge Server |
Defines the IP address of the SIP service of the Edge Server |
|
webconf |
Web conferencing edge of the Edge Server |
Defines the IP address of the Web Conferencing service of the Edge Server |
|
av |
Audio/Video edge on the Edge Server |
Defines the IP address of the Audio/Video Conferencing service |
|
internaledge |
Internal interface of Edge Server |
Defines the IP address of the internal facing interface of the Edge Server |
|
ocsrp |
Reverse proxy listener for Communicator Web Access server, address book, group expansion, meeting content, device update, |
Defines the IP address of the reverse proxy listener that will respond and redirect traffic to the Communicator Web Access server. The reverse proxy will also handle requests from clients for content on the pool servers, and must be configured for listening for these requests as well |
Table 2. DNS service SRV records required for contoso.com perimeter DNS server
|
Host Service (SRV) Records |
Points to |
Purpose |
|
_sipfederationtls._tcp |
Access edge on Edge server over port TCP/5061 |
Defines the SRV resource record for allowing discovery of your Access edge by potential federated partners |
|
_sip._tls |
Access edge on Edge server over port TCP/443 |
Defines the SRV resource record for external clients to use in the process of automatic configuration of the client software |
One final note to consider is the case where you need to have internal clients resolving and accessing systems in the perimeter network. In the same domain name scenario, this can pose a small problem because the DNS server that has authority for that domain is the DNS server in either the perimeter or the internal network, based on where the client is. In this case, you would need to duplicate entries on the internal and the perimeter DNS. Consider the Web server. If this server is only defined on the perimeter DNS server, internal clients will fail with a query to the internal DNS server. Creating a duplicate record for internal client use is the appropriate action to resolve this issue, and for any other hosts in the perimeter that your internal clients need to access.
Internal and Perimeter DNS Hosting Different Domain Names
The second common scenario assumes that there is a different domain name being used for the internal network than what is used in the perimeter. For our purposes, contoso.com is used for the perimeter, and contoso.local is used for the internal (Figure 2).
Figure 2. DNS configuration when perimeter and internal domain names are different with query flow
In this case, much like our previous scenario, the internal DNS resolves and manages all internal resolution. And, it is also responsible for forwarding queries for domain names that it does not know to the ISP DNS.
Where the behavior changes is how the internal DNS handles the queries for perimeter server names. In cases where the internal DNS cannot answer the query for contoso.com, the rule of one trust zone is applied. A trust zone is defined as an area in which the servers in one zone are at a higher risk, and therefore less trusted. In the case of the perimeter servers, they are at a higher risk of breach or compromise than the internal network, but are at less risk than Internet-based systems. The DNS in the perimeter is less trusted than the internal DNS, and the ISP DNS is less trusted than the perimeter DNS.
To resolve the issue of the internal clients finding the perimeter DNS, conditional forwarding is used to define how to resolve queries for contoso.com. Conditional forwarding is a method to forward all queries for a defined domain name to a specific server or set of DNS servers. This functionality was introduced in Windows Server 2003. Note that the Start of Authority (SOA) for contoso.com is on the DNS server in the perimeter, while the SOA for contoso.local is on the DNS server located in the internal network.
A conditional forwarder is created on the internal DNS to forward any queries for contoso.com to the perimeter DNS server. The perimeter DNS server will provide an answer (if one exists-if the query for a non-existent host is asked, it will usually fail) and return the query to the internal DNS. This is the method used to maintain the one trust zone method for integrity of the trust zones. You can also configure the firewalls that are protecting your perimeter and internal networks to use only UDP port 53 for DNS queries because a UDP packet cannot transfer the entire zone data in one request, where TCP can break the information up into multiple packets.
The configuration of records on the perimeter DNS servers is no different than the first scenario. The same A and SRV records are implemented as shown earlier in Table 1.
Reviewing the query/response patterns in the different domain name example and referring to Figure 2:
-
Internal client queries for pool01.contoso.com and the internal DNS responds with the IP address for pool01.contoso.com.
Client queries for sip.litwareinc.com, a federated partner domain name on the Internet not directly known by the perimeter or internal DNS server. The internal DNS does not know about this domain, and knows to send all failed queries to the next most authoritative server which is located at the ISP.
Internal client queries for a server in the perimeter network (for example, the Web server) and the internal DNS uses the conditional forwarder to forward any query for contoso.com to the perimeter DNS. The response is the IP address of the Web server.
This query takes two steps to complete.- The external client queries the ISP DNS for sip.contoso.com.
-
The ISP DNS refers the query to the known most authoritative server (holder of the SOA record) which is the DNS server in the contoso.com perimeter. The response is the IP address of the Access Edge in the perimeter.
Summary
A common tenant for internal and perimeter network protection is to disassociate the services as much as possible from those in other trust zones. DNS services, as important as they are, do pose risks that have been well-documented in the history of the Internet. By separating the trust zones for which the DNS servers are responsible, much of the risk can be mitigated.
With Office Communications Server (and very similar to the DNS solutions presented here), the Edge Servers disassociate the pool servers from direct external contact by providing a strong separation that takes place in the perimeter by having the Edge Servers first receive the requests, and then pass on the requests to the internal servers.
Additional Information
To learn more, check out the following articles:
- DNS Namespace Planning, http://go.microsoft.com/fwlink/?LinkId=178258
- Deploying Domain Name System (DNS) (Windows Server 2003), http://go.microsoft.com/fwlink/?LinkId=178259
- Administering DNS Server (Windows Server 2008), http://go.microsoft.com/fwlink/?LinkId=178040
- Supporting ISA Firewall Networks Protecting Illegal Top-level Domains: You Need a Split DNS!, http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html
- You Need to Create a Split DNS!, http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
-
The Global DNS Security, Stability & Resiliency Symposium, http://www.gtisc.gatech.edu/pdf/DNS_SSR_Symposium_Summary_Report.pdf
Office Communications Server Resources
- Visit the Office Communications Server main page at http://go.microsoft.com/fwlink/?LinkId=132607 .
- View the complete Office Communications Server documentation library at http://go.microsoft.com/fwlink/?LinkId=132106 .
- Follow tweets from the Office Communications Server team at http://go.microsoft.com/fwlink/?LinkId=167909 .
- Download all the Office Communications Server content as a Word document at http://go.microsoft.com/fwlink/?LinkId=133609 .
- Download all the Office Communications Server content as a compiled help file at http://go.microsoft.com/fwlink/?LinkId=160355 . (Make sure you scroll down to the Additional Information section to download OCSDocumentation.chm.)