Advanced DNS planning for Skype for Business Server 2015

 

Ultima modifica dell'argomento: 2015-08-17

Summary: Review scenarios for Skype for Business Server 2015 deployment options. Whether you want a single server or prefer a server pool with DNS or HLB, this topic should help.

When it comes to Domain Name System (DNS) planning for Skype for Business Server 2015, there are a lot of factors that may play into your decision. If your organization's domain structure's already in place, this may be a matter of reviewing how you're going to proceed. We'll begin with the topics found below:

• Walkthrough of Skype for Business clients locating services

• Split-brain DNS

• Automatic configuration without split-brain DNS

• DNS disaster recovery

• DNS load balancing

Walkthrough of Skype for Business clients locating services

Skype for Business clients are similar to previous versions of Lync clients in how they find and access services in Skype for Business Server 2015. This section details the server location process.

1. lyncdiscoverinternal.<domain>

   This is an A host record for the Autodiscover service on the internal web services.

2. lyncdiscover.<domain>

   This is an A host record for the Autodiscover service on the external web services.

3. _sipinternaltls._tcp.<domain>

   This is a SRV record for internal TLS connections.

4. _sip._tls.<domain>

   This is a SRV record for external TLS connections.

5. sipinternal.<domain>

   This is an A host record for the pool Front End or Server Director, resolvable only on the internal network.

6. sip.<domain>

   This is an A host record for the pool Front End or Server Director, resolvable only on the internal network.

7. sipexternal.<domain>

   This is an A host record for the UNRESOLVED_TOKEN_VAL(nm_AccessEdgeService), when the client is external.

The Autodiscover service is always favored as that's the preferred method for service location, and the others are fallback methods.

Nota

When you're creating SRV records, it's important to remember that they need to point to a DNS A (and AAAA if you're using IPv6 addressing) in the same domain in which the DNS SRV record's being created. For example, if they SRV record's in contoso.com, the A (and AAAA) record it points to can't be in fabrikam.com.

If you're inclined to do it, you can set your mobile device up for manual discovery of services. If that's what you're looking to do, each user needs to configure their mobile device settings with the full internal and external Autodiscover service URIs, including the protocol and path, as follows:

• For external access: https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

• For internal access: https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

We do recommend you use automatic discovery as opposed to manual discovery. But if you're doing some troubleshooting or testing, manual settings can be very helpful.

Split-brain DNS

This is a DNS configuration where you have two DNS zones with the same namespace. The first DNS zone handles internal requests, while the second DNS zone handles external requests.

Why would a company do this? They may have a requirement to use the same namespace internally and externally, but of course this will lead to many DNS SRV and A records being unique to one zone or another, and where there is duplication, the IP addresses associated with these records would be unique.

This presents some challenges. The most important is that split-brain DNS is not supported for Mobilità. This is because of the LyncDiscover and LyncDiscoverInternal DNS records (LyncDiscover has to be defined on you external DNS server, while LyncDiscoverInternal has to be defined on your internal DNS server).

We'll list the DNS records for the internal and external zones here, but you can find detailed examples on the server perimetrale environmental requirements section.

Internal DNS

• Contains a DNS zone called (for example) contoso.com, for which it's authoritative.

• This internal contoso.com contains:

  • DNS A and AAAA (if you're using IPv6 addressing) records for your pool Front End, pool di server Director or pool di server Director name, and all internal servers running Skype for Business Server 2015 in your organization's network.

  • DNS A and AAAA (if you're using IPv6 addressing) records for your UNRESOLVED_TOKEN_VAL(nm_EdgeIntInterface) for each Skype for Business Server 2015 server perimetrale in your UNRESOLVED_TOKEN_VAL(nm_perinet).

  • DNS A and AAAA (if you're using IPv6 addressing) records for the internal interface of each reverse proxy server in your UNRESOLVED_TOKEN_VAL(nm_perinet) (which is optional for management of a reverse proxy).

  • DNS A and AAAA (if you're using IPv6 addressing) and SRV records for internal Skype for Business Server 2015 client autoconfiguration (which is optional).

  • DNS A and AAAA (if you're using IPv6 addressing) or CNAME records for automatic discovery of Skype for Business Server 2015 Web Services (which is optional).

• All your Skype for Business Server 2015 internal UNRESOLVED_TOKEN_VAL(nv_edgeinterfaceplr) in your UNRESOLVED_TOKEN_VAL(nm_perinet) use this internal DNS zone for resolving queries to contoso.com.

• All servers running Skype for Business Server 2015, and clients running Skype for Business Server 2015 in the corporate network, point to internal DNS servers for resolving queries to contoso.com, or they use the Host file on each server perimetrale and list A and AAAA (if you're using IPv6 addressing) records for the next hop server (specifically for the Server Director or pool di server Director VIP, pool Front End VIP, or Server Standard Edition).

External DNS

• Contains a DNS zone called (for example) contoso.com, for which it's authoritative.

• This external contoso.com contains:

  • DNS A and AAAA (if you're using IPv6 addressing), or CNAME records, for automatic discovery of Skype for Business Server 2015 web services. This is for use with mobility.

  • DNS A and AAAA (if you're using IPv6 addressing) and SRV records for the UNRESOLVED_TOKEN_VAL(nv_edgeextinterface) of each Skype for Business Server 2015 server perimetrale or hardware load balanced (HLB) VIP in the UNRESOLVED_TOKEN_VAL(nm_perinet).

  • DNS A and AAAA (if you're using IPv6 addressing) and SRV records for the external interface of the Proxy inverso server or (VIP for a pool of Proxy inverso servers), in the UNRESOLVED_TOKEN_VAL(nm_perinet).

  • DNS A and AAAA (if you're using IPv6 addressing) and SRV records for Skype for Business Server 2015 client autoconfiguration (optional).

Automatic configuration without split-brain DNS

If you don't use split-brain DNS, internal automatic configuration of clients running Skype for Business won't work unless you're using one of the workarounds we have here. Why not? Because Skype for Business Server 2015 requires the user's SIP URI to match the domain of the pool Front End designated for automatic configuration. This hasn't changed from earlier versions of Lync Server.

So, if you have two SIP domains in use, you'd need these DNS SRV records:

• _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

  If a user signs in as bob@contoso.com, this record would work for automatic configuration, as the user's SIP domain matches the domain of the pool Front End (contoso.com).

• _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

  If a user signs in as alice@fabrikam.com, this record would work for automatic configuration of the second domain, again because the SIP domain matches the pool Front End for that domain.

To take the example further, this would not work:

• _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

  A user signing in as tim@litwareinc.com won't work for automatic configuration, because his SIP domain (litwareinc.com) doesn't match the domain in the pool (fabrikam.com).

So now that we know all that, if you need automatic requirement for your Skype for Business clients without split-brain DNS, you have these options:

• Group Policy Objects

  You can use Group Policy Objects (GPOs) to populate the correct server values.

  Nota

  This option doesn't enable automatic configuration, but it does automate manual configuration. If this approach is used, the SRV records associated with automatic configuration aren't required.

• Matching internal zone

  You'll need to create a zone in your internal DNS that matches your external DNS zone (for example, contoso.com), and then create DNS A (and AAAA if you're using IPv6 addressing) records that correspond to the Skype for Business Server 2015 pool used for automatic configuration.

  For example, if you have a user homed on pool01.contoso.net, but signs into Skype for Business as bob@contoso.com, create an internal DNS zone called contoso.com, and inside it you need to create a DNS A (and AAAA if IPv6 addressing's being used) record for pool01.contoso.com.

• Pin-point internal zone

  If creating an entire zone in your internal DNS isn't an option for you, you can create pin-point (dedicated) zones that correspond to the SRV records required for automatic configuration, and populate those zones using dnscmd.exe. Dnscmd.exe is required because the DNS user interface won't support the creation of pin-point zones.

  For example, if your SIP domain is contoso.com, and you have a pool Front End called pool01 that contains two Front End Server, you'll need the following pin-point zones and A records in your internal DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
  dnscmd . /zoneadd pool01.contoso.com. /dsprimary
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

  You may have a second SIP domain in your environment. In that case, you'll need the following pin-point zones and A records in your internal DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
  dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
  dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
  

Nota

You'll see the pool Front End FQDN appears twice, but with two different IP addresses. That's because DNS load balancing is used. If HLB is used, there'd only be a single pool Front End entry.
Also, the pool Front End FQDN values change between the contoso.com and fabrikam.com examples, but the IP addresses remain the same. That's because users who're signing in from either SIP domain will be using the same pool Front End for automatic configuration.

DNS disaster recovery

To configure DNS to redirect Skype for Business Server 2015 web traffic to your disaster recover (DR) and failover sites, you need to use a DNS provider that supports GeoDNS. You can set up your DNS records to support disaster recover, so that features that use web services continue even if one entire pool Front End goes down. This DR feature supports the Autodiscover, Meet and Dial-in simple URLs.

You define and configure additional DNS host A (AAAA if using IPv6) records for internal and external resolution of web services at your GeoDNS provider. The following details assume paired pools, geographically dispersed, and that the GeoDNS supported by your provider either has round-robin DNS or is configured to use Pool1 as primary and fails over to Pool2 in the event of any communications loss or power failure.

All the DNS records in this table are examples.

GeoDNS record	Pool records	CNAME records	DNS settings (select one option)
Meet-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Meet.contoso.com alias to Pool1InternalWebFQDN.contoso.com Meet.contoso.com alias to Pool2InternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Meet-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Meet.contoso.com alias to Pool1ExternalWebFQDN.contoso.com Meet.contoso.com alias to Pool2ExternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Dialin-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Dialin.contoso.com alias to Pool1InternalWebFQDN.contoso.com Dialin.contoso.com alias to Pool2InternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Dialin-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Dialin.contoso.com alias to Pool1ExternalWebFQDN.contoso.com Dialin.contoso.com alias to Pool2ExternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Lyncdiscoverint-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Lyncdiscoverinternal.contoso.com alias to Pool1InternalWebFQDN.contoso.com Lyncdiscoverinternal.contoso.com alias to Pool2InternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Lyncdiscover-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Lyncdiscover.contoso.com alias to Pool1ExternalWebFQDN.contoso.com Lyncdiscover.contoso.com alias to Pool2ExternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Scheduler-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Scheduler.contoso.com alias to Pool1InternalWebFQDN.contoso.com Scheduler.contoso.com alias to Pool2InternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure
Scheduler-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Scheduler.contoso.com alias to Pool1ExternalWebFQDN.contoso.com Scheduler.contoso.com alias to Pool2ExternalWebFQDN.contoso.com	Round Robin between pools OR Use primary, connect to secondary if there's a failure

DNS load balancing

DNS load balancing is usually implemented at the application level. The application (for example, a client running Skype for Business), tries to connect to a server in a pool by connecting to one of the IP addresses returned from the DNS A and AAAA (if IPv6 addressing is used) record query for the pool FQDN.

For example, if there are three Front End Server in a pool named pool01.contoso.com, the following would happen:

• Clients running Skype for Business query DNS for pool01.contoso.com. The query returns three IP addresses and caches them as follows (in some order):

  pool01.contoso.com	192.168.10.90
  pool01.contoso.com	192.168.10.91
  pool01.contoso.com	192.168.10.92

• The client tries to establish a TCP connection to one of the IP addresses. If that fails, it'll try the next IP address it's cached from that list.

• If the TCP connection succeeds, the client negotiates TLS to connect to the primary registrar on pool01.contoso.com.

• If the client tries all cached entries without a successful connection, the user receives a notification that no servers running Skype for Business Server 2015 are available at the moment.

Nota

DNS-based load balancing is different from DNS round robin (DNS RR), which typically refers to load balancing by relying on DNS to give a different order of IP addresses for the servers in your pool. Typically, DNS RR enables load distribution, but it won't allow you to enable failover. For example, if the connection to the one IP address returned by your DNS A (or AAAA in an IPv6 scenario) query fails, that connection will fail. That makes DNS RR less reliable than DNS-based load balancing. You can still use DNS RR in conjunction with DNS-based load balancing if you need to do that.

You use DNS load balancing to:

• Load balance server-to-server SIP to the server perimetrali.

• Load balance Unified Communication Application Services (UCAS) applications, such as Conferencing Auto Attendant, Response Group, and Call Park.

• Prevent new connections to UCAS applications (also known as draining).

• Load balance all client-to-server traffic between clients and server perimetrali.

You can't use DNS load balancing for:

• Client-to-server web traffic to your Front End Server or a Server Director.

To go a little more in-depth on how a DNS SRV record's selected when mutiple DNS records are returned by a query, the UNRESOLVED_TOKEN_VAL(nm_AccessEdgeService) always picks the record with the lowest numeric priority and, if a tie-breaker is needed, the highest numeric weight. This is consistent with Internet Engineering Task Force documentation.

So, for example, if your first DNS SRV record has a weight of 20 and a priority of 40, and your second DNS SRV record has a weight of 10 and a priority of 50, the first record's going to be chosen because it has the lower priority of 40. Priority always goes first, and that's the host that a client will target first. What if there are two targets with the same priority?

In that case, weight comes into consideration. Larger weights should be given a high probability, in this circumstance, of being selected. DNS administrators should use weight 0 when there isn't any server selection to do. In the presence of records containing weights greater than 0, records with weight 0 have a very small chance of bring selected.

So, then, what happens if multiple DNS SRV records with equal priority and weight as returned? In this situation the UNRESOLVED_TOKEN_VAL(nm_AccessEdgeService) will choose the SRV record that it got from the DNS server first.