Advanced DNS do servidor de borda planejando Skype para Business Server 2015

 

**Tópico modificado em:**2018-02-15

Resumo: analise cenários para as opções de implantação do Skype for Business Server 2015. Se você quiser um único servidor ou se preferir um pool de servidores com DNS ou HLB, este tópico deve ajudar.

Quando se trata do planejamento de DNS (Sistema de Nomes de Domínio) para o Skype for Business Server 2015, existem vários fatores que podem influenciar sua decisão. Se a estrutura de domínio de sua organização já estiver em vigor, pode ser só uma questão de analisar como continuar. Começaremos com os tópicos abaixo:

• 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

Os clientes Skype for Business são similares às versões anteriores dos clientes Lync na forma como encontram e acessam serviços no Skype for Business Server 2015. Esta seção detalha o processo de local do servidor.

1. lyncdiscoverinternal.<domain>

   Um registro de host do serviço de Descoberta Automática nos serviços Web internos.

2. lyncdiscover.<domain>

   Um registro de host do serviço de Descoberta Automática nos serviços Web externos.

3. _sipinternaltls._tcp.<domain>

   Um registro SRV para conexões TLS internas.

4. _sip._tls.<domain>

   Um registro SRV para conexões TLS externas.

5. sipinternal.<domain>

   This is an A host record for the Pool de Front-Ends or Diretor, resolvable only on the internal network.

6. sip.<domain>

   This is an A host record for the Pool de Front-Ends or Diretor, resolvable only on the internal network.

7. sipexternal.<domain>

   This is an A host record for the Serviço de Borda de Acesso, when the client is external.

O serviço de Descoberta Automática é sempre considerado o método preferencial para local do serviço, e os outros estão métodos de fallback.

Dica

Ao criar registros SRV, é importante lembrar que eles devem apontar para um DNS A (e AAAA, se você estiver usando endereçamento IPv6) no mesmo domínio em que o registro SRV do DNS for criado. Por exemplo, se o registro SRV estiver em contoso.com, o registro A (e AAAA) para o qual aponta não poderá estar em fabrikam.com.

Se você quiser, é possível definir seu dispositivo móvel para descoberta manual de serviços. Se for isso que você desejar fazer, cada usuário precisa definir as configurações de seus dispositivos móveis com os URIs completos, internos e externos, do serviço de Descoberta Automática, incluindo o protocolo e o caminho, da seguinte forma:

• Para acesso externo: https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root

• Para acesso interno: https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root

Recomendamos que você use a descoberta automática em oposição à descoberta manual. Mas, se você estiver solucionando problemas ou fazendo testes, as configurações manuais podem ser muito úteis.

DNS de dupla personalidade

Esta é uma configuração de DNS na qual você tem duas zonas DNS com o mesmo namespace. A primeira zona DNS lida com os pedidos internos, enquanto a segunda zona DNS lida com os pedidos externos.

Por que uma empresa faria isso? Pode haver a necessidade de usar o mesmo namespace internamente e externamente, mas isso levaria a muitos SRV e registros A de DNS exclusivos para uma ou outra zona e, onde houver duplicação, os endereços IP associados a esses registros seriam exclusivo.

Isso apresenta alguns desafios. O mais importante é que o DNS de dupla personalidade não é suportado no Mobilidade. Isso ocorre por causa dos registros de DNS LyncDiscover e LyncDiscoverInternal (LyncDiscover deve ser definido no servidor DNS externo, enquanto que LyncDiscoverInternal deve ser definido em seu servidor DNS interno).

Listaremos os registros DNS das zonas internos e externos aqui, mas você pode encontrar exemplos detalhados na seção de requisitos de ambiente do Servidor de Borda.

DNS Interno

• Contém uma zona DNS chamada (por exemplo) contoso.com, para a qual é autoritativo.

• Essa zona interna contoso.com contém:

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) para nome de seu Pool de Front-Ends, Pool de diretores ou nome de Pool de diretores, e todos os servidores internos executando o Skype for Business Server 2015 na rede de sua organização.

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) para seu Interface interna de borda para cada Skype for Business Server 2015Servidor de Borda em seu rede de perímetro.

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) de DNS para a interface interna de cada servidor de proxy reverso em sua rede de perímetro ( opcional para gerenciamento de proxy reverso).

  • Registros A e AAAA de DNS (se você estiver usando endereçamento IPv6) e SRV para configuração automática do cliente do Skype for Business Server 2015 interno ( opcional ).

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) de DNS ou CNAME para descoberta automática de serviços Web do Skype for Business Server 2015 ( opcional ).

• Todas as Interfaces de borda internas do seu Skype for Business Server 2015 em sua rede de perímetro usam esta zona DNS interna para resolver consultas para contoso.com.

• Todos os servidores executando Skype for Business Server 2015 e clientes executando Skype for Business Server 2015 no ponto de rede corporativa para servidores DNS internos para resolver consultas para contoso.com, ou usar arquivos de Host para cada Servidor de Borda e listar registros A e AAAA (se você estiver usando endereçamento IPv6) para o servidor de próximo salto (especificamente o Diretor ou VIP Pool de diretores, VIP do Pool de Front-Ends ou Servidor Standard Edition).

DNS Externo

• Contém uma zona DNS chamada (por exemplo) contoso.com, para a qual é autoritativo

• Essa zona externa contoso.com contém:

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) de DNS ou CNAME para descoberta automática dos serviços Web do Skype for Business Server 2015 para usar com mobilidade.

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) e SRV para a Interface externa de borda de cada Skype for Business Server 2015, Servidor de Borda ou VIP com balanceamento de carga de hardware (HLB) no rede de perímetro.

  • Registros A e AAAA (se você estiver usando endereçamento IPv6) de DNS para a interface externa do servidor de Proxy reverso ou VIP de um pool de servidores de Proxy reverso na rede de perímetro.

  • Registros A e AAAA de DNS (se você estiver usando endereçamento IPv6) e SRV para configuração automática do cliente do Skype for Business Server 2015 ( opcional ).

Configuração automática sem DNS de dupla personalidade

Se você não usar DNS de dupla personalidade, a configuração automática interna de clientes executando o Skype for Business não funcionará, a menos que você esteja usando uma das soluções alternativas mostradas aqui. Por que não? Porque o Skype for Business Server 2015 exige que a URI SIP do usuário corresponda ao domínio do Pool de Front-Ends designado para configuração automática. Isso não mudou de versões anteriores do Servidor Lync.

Portanto, se você tiver dois domínios SIP em uso, você precisará desses registros SRV de DNS:

• _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 de Front-Ends (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 de Front-Ends for that domain.

Para aprofundar mais o exemplo, isso não funcionaria:

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

  O logon de usuário tim@litwareinc.com não funcionará para a configuração automática, porque seu domínio SIP (litwareinc.com) não corresponde ao domínio do pool (fabrikam.com).

Agora que já sabemos tudo isso, se você precisar de requisito automático para seus clientes Skype for Business sem DNS de dupla personalidade, você tem estas opções:

• Objetos de Política de Grupo

  Você pode usar Objetos de Política de Grupo (GPOs) para popular os valores de servidor corretos.

  Dica

  Essa opção não habilita a configuração automática, mas automatiza a configuração manual. Se essa abordagem for utilizada, os registros SRV associados à configuração automática não serão necessários.

• Zona interna correspondente

  Você precisará criar uma zona no DNS interno que corresponda à zona do DNS externo (por exemplo, contoso.com) e crie registros A (e AAAA, se você estiver usando endereçamento IPv6) de DNS correspondentes ao pool do Skype for Business Server 2015 usado para a configuração automática.

  Por exemplo, se um usuário seu estiver hospedado em pool01.contoso.net, mas entrar no Skype for Business como bob@contoso.com, crie uma zona do DNS interno chamada contoso.com e, dentro dela, você deverá criar um registro A (e AAAA, se você estiver usando endereçamento IPv6) de DNS para pool01.contoso.com.

• Zona interna exata

  Se criar uma zona inteira no DNS interno não for uma opção, você poderá criar zonas exatas (dedicadas) que correspondam aos registros SRV necessários para a configuração automática e popular estas zonas usando o dnscmd.exe. O dnscmd.exe é necessário porque a interface do usuário do DNS não é compatível com a criação de zonas exatas.

  Por exemplo, se o domínio SIP for contoso.com e você tiver um Pool de Front-Ends chamado pool01 que contém dois Servidores Front-End, serão necessárias as seguintes zonas exatas e registros A em seu DNS interno:

  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>
  

  Você pode ter um segundo domínio SIP em seu ambiente. Nesse caso, você precisará das seguintes zonas exatas e registros A em seu DNS interno:

  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>
  

Dica

Você verá que o FQDN do Pool de Front-Ends aparece duas vezes, mas com dois endereços IP diferentes. Isso ocorre porque o balanceamento de carga DNS é usado. Se o HLB for usado, haverá apenas uma entrada no Pool de Front-Ends.
Além disso, os valores de FQDN do Pool de Front-Ends mudam entre os exemplos contoso.com e fabrikam.com, mas os endereços IP permanecem os mesmos. Isso ocorre porque os usuários que estiverem entrando a partir de cada domínio SIP usarão o mesmo Pool de Front-Ends para a configuração automática.

Recuperação de desastres de DNS

Para configurar o DNS para redirecionar o tráfego da Web do Skype for Business Server 2015 para seus sites de recuperação de desastres (DR) e failover, é necessário usar um provedor de DNS que suporte GeoDNS. Você pode definir seus registros DNS para suportar recuperação de desastres, de forma que os recursos que usam os serviços da Web prosseguirão mesmo se um Pool de Front-Ends inteiro cair. Esse recurso de DR suporta URLs simples de Descoberta Automática, de reunião e discado.

Você define e configura registros adicionais de host de DNS A (AAAA, se estiver usando IPv6) para resolução de serviços da Web internos e externos em seu provedor GeoDNS. As informações a seguir supõem pools emparelhados e geograficamente dispersos, GeoDNS suportado por seu provedor com DNS round robin ou configurado para usar o Pool1 como primário e failover para o Pool2, em caso de perda de comunicações ou falha de energia.

Todos os registros DNS nesta tabela são exemplos.

Registro GeoDNS	Registros de Pool	Registros CNAME	Registros DNS (selecione uma opção)
Meet-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Alias Meet.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Meet.contoso.com para Pool2InternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Meet-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Alias Meet.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Meet.contoso.com para Pool2ExternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Dialin-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Alias Dialin.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Dialin.contoso.com para Pool2InternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Dialin-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Alias Dialin.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Dialin.contoso.com para Pool2ExternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Lyncdiscoverint-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Alias Lyncdiscoverinternal.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Lyncdiscoverinternal.contoso.com para Pool2InternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Lyncdiscover-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Alias Lyncdiscover.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Lyncdiscover.contoso.com para Pool2ExternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Scheduler-int.geolb.contoso.com	Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com	Alias Scheduler.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Scheduler.contoso.com para Pool2InternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha
Scheduler-ext.geolb.contoso.com	Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com	Alias Scheduler.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Scheduler.contoso.com para Pool2ExternalWebFQDN.contoso.com	Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha

Balanceamento de carga DNS

O balanceamento de carga do DNS normalmente é implantado no nível dos aplicativos. O aplicativo (por exemplo, um cliente que executa o Skype for Business), tenta se conectar a um servidor em um pool estabelecendo conexão com um dos endereços IP resultantes da consulta do registro A e AAAA (se o endereçamento IPv6 estiver sendo usado) de DNS para o FQDN do pool.

Por exemplo, se houver três Servidores Front-End em um pool chamado pool01.contoso.com, acontecerá o seguinte:

• Clientes que executam o DNS de consulta do Skype for Business para pool01.contoso.com. A consulta retorna três endereços de IP e os armazena em cache da seguinte maneira (em qualquer ordem):

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

• O cliente tenta estabelecer uma conexão TCP com um dos endereços IP. Em caso de falha, o cliente tenta o próximo endereço IP em cache.

• Se a conexão TCP for bem -sucedida, o cliente negocia o TLS para se conectar ao Registrador Avançado primário em pool01.contoso.com.

• Se o cliente experimenta todas as entradas em cache e não consegue estabelecer uma conexão com êxito, o usuário recebe uma notificação de que não há nenhum servidor que execute o Skype for Business Server 2015 disponível no momento.

Dica

O balanceamento de carga com base em DNS é diferente do round robin de DNS (DNS RR), que normalmente faz referência ao balanceamento de carga confiando no DNS para fornecer uma ordem diferente de endereços IP dos servidores de seu pool. Normalmente, o DNS RR habilita a distribuição de carga, mas não habilita o failover. Por exemplo, se a conexão com um endereço IP retornado pela consulta DNS A (ou AAAA, se estiver usando o endereçamento IPv6) falhar, a conexão falha. Portanto, o round robin de DNS é menos confiável do que o balanceamento de carga com base em DNS. O round robin de DNS ainda pode ser usado em conjunto com o balanceamento de carga DNS.

O balanceamento de carga DNS é usado para:

• Balanceamento de carga SIP entre servidores para os Servidores de Borda.

• Balanceamento de carga de aplicativos de Serviços de Aplicativos de Comunicações Unificadas (UCAS), como o Atendedor Automático de Conferências, Grupo de Resposta e Estacionamento de Chamada.

• Evitar novas conexões a aplicativos UCAS (também conhecido como drenagem).

• Balanceamento de carga de todo o tráfego do cliente para o servidor entre clientes e Servidores de Borda.

O balanceamento de carga DNS não pode ser usado para:

• Tráfego da Web de cliente para servidor para seus Servidores Front-End ou uma Diretor.

Para se aprofundar um pouco sobre a forma como um registro SRV de DNS é selecionado quando vários registros DNS são retornados por uma consulta, o Serviço de Borda de Acesso sempre escolhe o registro com prioridade numérica mais baixa e, se um desempate for necessário, o peso numérico mais alto. Isso é consistente com a documentação do Internet Engineering Task Force.

Assim, por exemplo, se seu primeiro registro SRV de DNS tem um peso 20 e uma prioridade 40 e seu segundo registro SRV de DNS tem um peso 10 e uma prioridade 50, o primeiro registro vai ser escolhido, pois tem a prioridade menor de 40. A Prioridade é sempre considerada primeiro, e esse é o primeiro host de destino de um cliente. E se dois destinos tiverem a mesma prioridade?

Nesse caso, o peso é considerado. Pesos maiores devem ter maior probabilidade, nessas circunstâncias, de serem escolhidos. Os administradores DNS devem usar peso 0 quando não houver nenhuma seleção de servidor para fazer. Na presença de registros contendo pesos maiores que 0, os registros com peso 0 devem ter uma chance muito pequena de serem selecionados.

Então, o que acontece se vários registros SRV de DNS com prioridade e peso iguais forem retornados? Nesta situação, o Serviço de Borda de Acesso escolherá o registro SRV recebido primeiro do servidor DNS.