Advanced DNS planning for Skype for Business Server 2015

 

마지막으로 수정된 항목: 2016-12-20

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 서버 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 clients locating services

  • Split-brain DNS

  • Automatic configuration without split-brain DNS

  • DNS disaster recovery

  • DNS load balancing

Walkthrough of 비즈니스용 Skype clients locating services

비즈니스용 Skype clients are similar to previous versions of Lync clients in how they find and access services in 비즈니스용 Skype 서버 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 프런트 엔드 풀 or 디렉터, resolvable only on the internal network.

  6. sip.<domain>

    This is an A host record for the 프런트 엔드 풀 or 디렉터, 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.

참고

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 모바일. 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 에지 서버 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 프런트 엔드 풀, 디렉터 풀 or 디렉터 풀 name, and all internal servers running 비즈니스용 Skype 서버 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 서버 2015 에지 서버 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 서버 2015 client autoconfiguration (which is optional).

    • DNS A and AAAA (if you're using IPv6 addressing) or CNAME records for automatic discovery of 비즈니스용 Skype 서버 2015 Web Services (which is optional).

  • All your 비즈니스용 Skype 서버 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 서버 2015, and clients running 비즈니스용 Skype 서버 2015 in the corporate network, point to internal DNS servers for resolving queries to contoso.com, or they use the Host file on each 에지 서버 and list A and AAAA (if you're using IPv6 addressing) records for the next hop server (specifically for the 디렉터 or 디렉터 풀 VIP, 프런트 엔드 풀 VIP, or 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 서버 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 서버 2015 에지 서버 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 역방향 프록시 server or (VIP for a pool of 역방향 프록시 servers), in the UNRESOLVED_TOKEN_VAL(nm_perinet).

    • DNS A and AAAA (if you're using IPv6 addressing) and SRV records for 비즈니스용 Skype 서버 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 won't work unless you're using one of the workarounds we have here. Why not? Because 비즈니스용 Skype 서버 2015 requires the user's SIP URI to match the domain of the 프런트 엔드 풀 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 프런트 엔드 풀 (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 프런트 엔드 풀 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 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.

    참고

    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 서버 2015 pool used for automatic configuration.

    For example, if you have a user homed on pool01.contoso.net, but signs into 비즈니스용 Skype 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 프런트 엔드 풀 called pool01 that contains two 프런트 엔드 서버, 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>
    

참고

You'll see the 프런트 엔드 풀 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 프런트 엔드 풀 entry.
Also, the 프런트 엔드 풀 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 프런트 엔드 풀 for automatic configuration.

DNS disaster recovery

To configure DNS to redirect 비즈니스용 Skype 서버 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 프런트 엔드 풀 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), 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 프런트 엔드 서버 in a pool named pool01.contoso.com, the following would happen:

  • Clients running 비즈니스용 Skype 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 서버 2015 are available at the moment.

참고

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 에지 서버.

  • 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 에지 서버.

You can't use DNS load balancing for:

  • Client-to-server web traffic to your 프런트 엔드 서버 or a 디렉터.

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.