Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
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:
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.
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.
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:
While either of these could be used for Office Communications Server, some technical and security-based issues to consider are the following:
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.
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.
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.
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:
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
Defines the IP address of the Web server hosted in the perimeter
Access edge of Edge Server
Defines the IP address of the SIP service of the Edge Server
Web conferencing edge of the Edge Server
Defines the IP address of the Web Conferencing service of the Edge Server
Audio/Video edge on the Edge Server
Defines the IP address of the Audio/Video Conferencing service
Internal interface of Edge Server
Defines the IP address of the internal facing interface of the Edge Server
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
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
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.
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:
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.
To learn more, check out the following articles:
The Global DNS Security, Stability & Resiliency Symposium, http://www.gtisc.gatech.edu/pdf/DNS_SSR_Symposium_Summary_Report.pdf