Lync Server DNS Pinpoint zones

Edited 10.29.2012 1535 PST – thanks to Jeremy!

Scenario

I recently did a project where the client wanted to use their email address domain for their SIP domain – fairly common – but they did not have an internal DNS zone for that domain.  Their internal AD structure was domain.local – not something we can publish for external or federation access.  Furthermore, the client did not want to establish split-DNS – which is the common solution for this type of environment.  But, the client also wanted external users, mobility, and federation. 

What the client was doing was using an external DNS provider to resolve their SMTP domain lookups.  When the external name resolution directed an internal client to an external IP that was NAT to an internal resource, the firewall did an automagic redirect to the proper internal target.

Clearly, this will not work for Lync – even if mobility needs to always achieve the same connection regardless of location, using the firewall to execute fancy footwork won’t work due to how an Edge server works, or how TMG works.  TMG would see those packets as spoofed and simply drop them.  Edge will work, after a fashion, but when the client starts connecting internally and externally at the same time, the combination is guaranteed to produce inconsistent user experience and outright failures.

Remember that Lync 2010 does an automatic lookup for _sipinternaltls._tcp.<domain.name> where <domain.name> is the SIP domain that provisioned for the user who is logging in with a SIP enabled AD account.  Therefore, in our test case, we want the Lync 2010 Client to find _sipinternaltls._tcp.domain.com.

What to do?

The answer is to create “pinpoint” DNS zones.  This type of DNS zone is a single record that is represented by the zone itself.  For instance, if you need/want to have SIP.domain.com, but you don’t want to have to double manage a lengthy list of A records in two places (split DNS) then you can create a pointpoint zone that looks like this:

When the client goes looking for SIP.domain.com, it can certainly find it, yes?  But name resolution for anything else in domain.com other than that specific name (SIP.domain.com) will need to go somewhere else for resolution.

Let’s take a look at how to create a pinpoint DNS zone record.

Start with your DNS Manager…Right-click the “Forward Lookup Zones” and choose “New Zone.”

Click NEXT in the “Welcome to the New Zone Wizard” and then choose Primary Zone.
 

Choose the Zone Replication Scope option that makes sense for your environment…

 

And then name your zone.  We want SIP.domain.com. I always only allow secure dynamic updates

 

Select Finish, and you have created the new zone.

After you get your new zone, you need to add a host record so your DNS server can reply to DNS queries with an IP address.  To do that, right-click your zone and choose “New Host (A or AAAA)…”  Leave the NAME blank, input the IP, and I always adjust internal A records downwards.  In this case, I used a five minute TTL because I am forever whipping my Lync lab into some different configuration and I want the client connection points to be updated quickly.

 

Voila!  Now we look like the first picture. 

Pretty slick.  But, perhaps you know that the Lync 2010 client looks for SRV records by default?  How to construct an SRV record using this pinpoint technique? 

Get yourself to a command prompt…You will have a seriously hard time doing this in the GUI as this action is not supported in the DNS Manager GUI.  See this reference.

and enter the following:

dnscmd . /zoneadd _sipinternaltls._tcp.domain.com. /dsprimary

(creates the actual pinpoint zone)

&

dnscmd . /recordadd _sipinternaltls._tcp.domain.com. @ SRV 0 0 5061 sip.domain.com

(adds the SRV record to that zone)

Here is the final client lookup flow. We resolve to an SRV record that the Lync 2010 client looks for (_sipinternaltls._tcp.domain.com) and pointed that to another pinpoint zone (sipinternal.domain.com) with the FE pool having a cert that included that name in the SAN.  We did this to get around the strict DNS naming issue that would have caused login issues  due to the difference between the FQDN (tsoorad.net) and the SIP domain name (domain.com).

Remember to add the SIP domain to the Lync Front End Server (or servers) as shown.

YMMV!