Artigo
08/09/2014

Determinando os requisitos de DNS

Tópico modificado em: 2012-10-16

Use o fluxograma a seguir para determinar os requisitos do Sistema de Nomes de Domínio (DNS).

Fluxograma - Como determinar os requisitos do DNS

Requisitos de DNS para acesso de usuário externo

Importante:
O nome especificado deve ser idêntico ao nome do computador configurado no servidor. Por padrão, o nome de um computador que não está vinculado a um domínio é curto, não um nome de domínio totalmente qualificado (FQDN). O Construtor de Topologias usa FQDNs, não nomes curtos. Assim, você deve configurar um sufixo DNS no nome do computador a ser implantado como um Servidor de Borda que não está vinculado a um domínio. Use somente caracteres padrão (incluindo A–Z, a–z, 0–9 e hífens) ao atribuir FQDNs dos seus Lync Servers, Servidores de Borda e pools. Não use caracteres Unicode ou sublinhados. Caracteres que não são padrão em um FQDN geralmente não são suportados por DNSs externos e CAs públicos (ou seja, quando o FQDN deve ser atribuído ao SN no certificado). Para detalhes sobre como adicionar um sufixo DNS a um nome de computador, consulte Configurar registros DNS para suporte de borda.

O nome especificado deve ser idêntico ao nome do computador configurado no servidor. Por padrão, o nome de um computador que não está vinculado a um domínio é curto, não um nome de domínio totalmente qualificado (FQDN). O Construtor de Topologias usa FQDNs, não nomes curtos. Assim, você deve configurar um sufixo DNS no nome do computador a ser implantado como um Servidor de Borda que não está vinculado a um domínio. Use somente caracteres padrão (incluindo A–Z, a–z, 0–9 e hífens) ao atribuir FQDNs dos seus Lync Servers, Servidores de Borda e pools. Não use caracteres Unicode ou sublinhados. Caracteres que não são padrão em um FQDN geralmente não são suportados por DNSs externos e CAs públicos (ou seja, quando o FQDN deve ser atribuído ao SN no certificado). Para detalhes sobre como adicionar um sufixo DNS a um nome de computador, consulte Configurar registros DNS para suporte de borda.

Como configurar Split-Brain DNS com o Lync Server 2010

Assim como a conversão de endereços de rede (NAT), o termo split-brain DNS é definido de várias formas diferentes. Para este documento, este termo significa que a zona do DNS para um determinado namespace é a mesma no DNS interno e no DNS externo. No entanto, muitos dos registros SRV do DNS e DNS A contidos no DNS interno não estarão no DNS externo e o contrário também é verdadeiro. E, em casos em que o mesmo registro DNS existe em ambos os DNSs interno e externo (por exemplo, www.contoso.com), o endereço IP retornado será diferente, dependendo de onde a consulta do DNS é feita.

Se você estiver configurando um split-brain DNS, as zonas interna e externa contêm um resumo dos tipos de registros DNS necessários em cada zona. Para detalhes, consulte Arquitetura de referência.

DNA Interno:

Contém uma zona do DNS chamada contoso.com, para a qual é autoritativo
A zona contoso.com interna contém:
- Registros DNS A e SRV para a configuração automática do cliente do Microsoft Lync Server 2010 (opcional)
- Registros DNS A ou CNAME para descoberta automática do Lync Server Web Services.
- Registros DNS A e SRV para todos os servidores internos que estiverem executando o Lync Server 2010 na rede corporativa.
- Registros DNS A e SRV para a interface interna da Borda de cada Lync Server 2010, Servidor de Borda na rede de perímetro
- Registros DNS A para a interface interna do proxy reverso de cada servidor de proxy reverso na rede de perímetro
- Todos os Servidores de Borda do Lync Server 2010 na rede de perímetro apontam para os servidores DNS internos para resolver consultas em contoso.com
- Todos os servidores executando o Lync Server 2010 e clientes executando o Lync 2010 na rede corporativa apontam para os servidores DNS internos para resolver consultas em contoso.com

DNS Externo:

Contém uma zona de DNS chamada contoso.com, para a qual é autoritativo
A zona contoso.com externa contém:
- Registros DNS A e SRV para a configuração automática do cliente do Lync Server 2010 (opcional)
- Registros DNS A ou CNAME para descoberta automática do Lync Server Web Services.
- Registros DNS A e SRV para a interface externa da Borda de cada Lync Server 2010, Servidor de Borda ou IP virtual (VIP) do balanceador de carga do hardware na rede de perímetro
- Registros DNS A para a interface externa do proxy reverso de cada servidor de proxy reverso na rede de perímetro

Como os clientes executando o Microsoft Lync 2010 localizam serviços

Durante a pesquisa de DNS, registros SRV são consultados em paralelo e retornados na seguinte ordem para o cliente (se configurados e disponíveis):

_sipinternaltls._tcp.<domínio> - para conexões TLS internas
_sipinternal._tcp. <domínio> - para conexões TCP internas (executadas apenas se houver permissão para TCP)
_sip._tls. <domínio> - para conexões TLS externas
_sip._tcp. <domínio> - para conexões TCP externas (executadas somente se houver permissão para TCP)

Onde <domínio> é o domínio SIP usado por seus clientes internos. As duas últimas consultas são para clientes que estão se conectando de fora da sua rede interna. Ao criar registros SRV, é importante lembrar que eles devem apontar para um registro DNS A no mesmo domínio em que o registro SRV do DNS for criado. Por exemplo, se o registro SRV está em contoso.com, o registro A para o qual aponta não pode estar em fabrikam.com, também deve estar em contoso.com.

Quando você entra pela primeira vez, o cliente executando o Lync tenta se conectar a um pool de Front End usando cada um dos três registros SRV em ordem, independente de ter entrado de dentro ou de fora da sua rede. Depois que o cliente que está executando o Lync estabelece uma conexão com sucesso, ele armazena em cache a entrada DNS e continua a usá-la até que não seja mais bem sucedida. Se o cliente que está executando o Lync não puder usar o valor armazenado em cache, solicita ao DNS os registros SRV novamente e realimenta seu cache. Por exemplo, este processo é seguido se você entrar na rede interna durante o dia, levar seu laptop para casa e entrar externamente.

Depois que o registro SRV é retornado, uma consulta é executada para o registro DNS A (pelo FQDN) do servidor ou pool de Front End associado ao registro SRV. Se nenhum registro for encontrado durante a consulta ao servidor DNS, o cliente do Lync executa uma pesquisa explícita do sipinternal.<domínio>. Se a pesquisa explícita não produzir resultados, o cliente do Lync executa uma pesquisa por sip.<domínio>.

Configuração automática sem Split-Brain DNS

Se o split-brain DNS for utilizado, um usuário do Lync Server 2010 que entrar internamente pode tirar vantagem da configuração automática se a zona do DNS interno contiver um registro SRV _sipinternaltls._tcp para cada domínio SIP em uso. No entanto, se você não usa split-brain DNS, a configuração automática interna de clientes executando o Lync não funcionará, a menos que uma das soluções alternativas descritas posteriormente neste seção seja implementada. Isso acontece porque o Lync Server 2010 exige que o URI do SIP do usuário corresponda ao domínio do pool de Front End designado para a configuração automática. Este também era o caso com versões anteriores do Communicator.

Por exemplo, se você tem dois domínios SIP em uso, os registros de serviço (SRV) do DNS a seguir serão necessários:

Se um usuário entrar como lstest01@contoso.com, o registro SRV a seguir funcionará para a configuração automática, porque o domínio SIP do usuário (contoso.com) corresponde ao domínio do pool de Front End da configuração automática:

_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
Se um usuário entrar como lstest01@fabrikam.com, o registro SRV do DNS a seguir funcionará para a configuração automática do segundo domínio SIP.

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

Para comparação, se um usuário entrar como lstest01@litwareinc.com, o registro SRV do DNS a seguir não funcionará para a configuração automática, porque o domínio SIP do cliente (litwareinc.com) não corresponde ao domínio em que o pool está (fabrikam.com):

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

Se a configuração automática for necessária para clientes executando o Lync, selecione uma das seguintes opções:

Objetos de Política de Grupo Use objetos de Política de Grupo (GPOs) para popular os valores de servidor corretos.

Observação:
Esta opção não habilita a configuração automática, mas automatiza o processo de configuração manual; assim, se esta abordagem for utilizada, os registros SRV associados à configuração automática não são necessários.

Comparação da zona interna Crie uma zona no DNS interno que corresponda à zona do DNS externo (por exemplo, contoso.com) e crie registros DNS A correspondentes ao pool do Lync Server 2010 usado para a configuração automática. Por exemplo, se um usuário está hospedado em pool01.contoso.net mas entra no Lync como lstest01@contoso.com, crie uma zona do DNS interno chamada contoso.com e, dentro dela, crie um registro DNS A para pool01.contoso.com.
Zona interna exata Se criar uma zona inteira no DNS interno não for uma opção, você pode criar zonas exatas (ou seja, 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 End 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. @ A 192.168.10.91
```
Se seu ambiente possui um segundo domínio SIP (por exemplo, fabrikam.com), as seguintes zonas exatas e registros A são necessários 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.fabrikam.com. @ A 192.168.10.91
```

Observação:
O FQDN do pool de Front End aparece duas vezes, mas com dois endereços IP diferentes. Isso acontece porque o balanceamento de carga do DNS é usado, mas se o balanceamento de carga do hardware for utilizado, existirá apenas uma única entrada do pool de Front End. Além disso, os valores do FQDN do pool de Front End mudam entre os exemplos contoso.com e fabrikam.com, mas os endereços IP permanecem os mesmos. Isso acontece porque usuários entrando a partir do domínio SIP usam o mesmo pool de Front End para a configuração automática.

O FQDN do pool de Front End aparece duas vezes, mas com dois endereços IP diferentes. Isso acontece porque o balanceamento de carga do DNS é usado, mas se o balanceamento de carga do hardware for utilizado, existirá apenas uma única entrada do pool de Front End. Além disso, os valores do FQDN do pool de Front End mudam entre os exemplos contoso.com e fabrikam.com, mas os endereços IP permanecem os mesmos. Isso acontece porque usuários entrando a partir do domínio SIP usam o mesmo pool de Front End para a configuração automática.

Para detalhes, consulte o artigo do blog DMTF, "Configuração Automática do Communicator e Split-Brain DNS," em https://go.microsoft.com/fwlink/?linkid=200707&clcid=0x416.

Observação:
O conteúdo de cada blog e sua URL estão sujeitos a alterações sem aviso prévio.

Como clientes de dispositivos móveis executando o Lync 2010 localizam serviços

Clientes de dispositivos móveis executando o Lync 2010 usam registros DNS A ou CNAME da descoberta automática para localizar serviços de mobilidade. Durante a pesquisa de DNS, primeiro tentam uma conexão com o nome totalmente qualificado (FQDN) que está associado ao registro do DNS interno (ou seja, lyncdiscoverinternal. <sipdomain>). Se uma conexão não puder ser estabelecida com a URL interna, os clientes tentam uma conexão com o FQDN que está associado ao registro do DNS externo (ou seja, lyncdiscover. <sipdomain>). A prioridade é sempre dada para a URL interna. Se uma conexão com a URL interna for bem sucedida, o cliente usa a rede Wi-Fi corporativa. Caso contrário e uma conexão com a URL externa for bem sucedida, a solicitação do cliente passa por um proxy reverso e é roteada para o Servidor Front End ou Diretor.

Quando uma conexão é bem sucedida, o Serviço de Descoberta Automática retorna todas as URLs dos Serviços Web para o pool base do usuário, incluindo as URLs do Serviço de Mobilidade. No entanto, ambas, a URL do Serviço de Mobilidade interna e externa, são associadas ao FQDN dos Serviços Web externos. Portanto, independente de o dispositivo móvel ser interno ou externo à rede, sempre se conectará ao Serviço de Mobilidade externamente através do proxy reverso.

Dica:
Embora a configuração padrão permita que o tráfego do cliente móvel passe pelo site externo, é possível modificar as configurações para retornar apenas a URL interna. Com esta configuração, os usuários podem usar aplicativos móveis do Lync em seus dispositivos móveis apenas quando estiverem dentro da rede corporativa. Para suportar esta configuração, é necessário executar o cmdlet Set-CsMcxConfiguration. Também é necessário configurar os IPs virtuais (VIPs) dos Serviços Web internos em seu Servidor Front End e nos balanceadores de carga do hardware do Diretor para persistência baseada em cookies. Para detalhes sobre os requisitos do balanceador de carga de hardware, consulte a seção "Requisitos do balanceador de carga de hardware para o proxy reverso" em Balanceadores de carga de hardware. Para detalhes sobre como utilizar o Set-CsMcxConfiguration para restringir o tráfego do cliente móvel na rede interna, consulte Instalando os serviços de descoberta automática e mobilidade.

Embora a configuração padrão permita que o tráfego do cliente móvel passe pelo site externo, é possível modificar as configurações para retornar apenas a URL interna. Com esta configuração, os usuários podem usar aplicativos móveis do Lync em seus dispositivos móveis apenas quando estiverem dentro da rede corporativa. Para suportar esta configuração, é necessário executar o cmdlet Set-CsMcxConfiguration. Também é necessário configurar os IPs virtuais (VIPs) dos Serviços Web internos em seu Servidor Front End e nos balanceadores de carga do hardware do Diretor para persistência baseada em cookies. Para detalhes sobre os requisitos do balanceador de carga de hardware, consulte a seção "Requisitos do balanceador de carga de hardware para o proxy reverso" em Balanceadores de carga de hardware. Para detalhes sobre como utilizar o Set-CsMcxConfiguration para restringir o tráfego do cliente móvel na rede interna, consulte Instalando os serviços de descoberta automática e mobilidade.

Observação:
Embora aplicativos móveis também possam se conectar a outros serviços do Lync Server 2010, como o Serviço de Catálogo de Endereços, solicitações web de aplicativos móveis internos vão para o FQDN externo da web somente para o Serviço de Mobilidade. Outras solicitações de serviços, como solicitações do Catálogo de Endereços, não exigem esta configuração.

O Lync 2010 para dispositivos móveis também é compatível com a descoberta manual de serviços. Neste caso, cada usuário deve configurar as definições do dispositivo móvel com as URIs do Serviço de Descoberta Automática interna e externa completas, incluindo o protocolo e o caminho, da seguinte forma:

https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Raiz do acesso externo
https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Raiz do acesso interno

Utilizar a descoberta automática, em vez da descoberta manual, é altamente recomendado. No entanto, usar configurações manuais é útil para solucionar problemas de conectividade dos dispositivos móveis. Para detalhes sobre os registros DNS usados para o Serviço de Descoberta Automática, consulte Requisitos técnicos para mobilidade. Para detalhes sobre o planejamento da mobilidade, consulte Planejamento de mobilidade.

Balanceamento de carga do DNS

O balanceamento de carga do DNS normalmente é implementado no nível do aplicativo. O aplicativo (por exemplo, um cliente executando o Lync 2010), tenta se conectar a um servidor em um pool estabelecendo conexão com um dos três endereços IP resultantes da consulta DNS A pelo nome totalmente qualificado (FQDN) do pool.

Por exemplo, se houver três servidores front end em um pool chamado pool01.contoso.com, acontecerá o seguinte:

Clientes executando o Lync 2010 consultarão o DNS por pool01.contoso.com, receberão como retorno três endereços IP e os armazenarão em cache da seguinte forma (não necessariamente nesta ordem):

pool01.contoso.com      192.168.10.90

pool01.contoso.com      192.168.10.91

pool01.contoso.com      192.168.10.92
Então, 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 Servidor Front End.
Se chegar ao final sem uma conexão bem sucedida, o usuário é notificado de que nenhum servidor executando o Lync Server 2010 está disponível no momento.

Observação:
O balanceamento de carga baseado 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 correspondentes aos servidores em um pool. Normalmente o DNS RR só 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 falhar, a conexão falha. Portanto, o round robin de DNS por si só é menos confiável do que o balanceamento de carga baseado em DNS. O round robin de DNS pode ser usado em conjunto com o balanceamento de carga do DNS.

O balanceamento de carga baseado 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 correspondentes aos servidores em um pool. Normalmente o DNS RR só 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 falhar, a conexão falha. Portanto, o round robin de DNS por si só é menos confiável do que o balanceamento de carga baseado em DNS. O round robin de DNS pode ser usado em conjunto com o balanceamento de carga do DNS.

O balanceamento de carga do DNS é usado para:

Balanceamento de carga do tráfego SIP e HTTP de servidor-para-servidor
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 cliente-para-servidor entre clientes e Servidores de Borda

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

Tráfego web cliente-para-servidor

Balanceamento de carga do DNS e tráfego federado:

Se uma consulta ao servidor DNS retornar vários registros, o serviço de Borda de Acesso sempre escolhe o registro SRV de DNS com a prioridade numérica mais baixa e peso numérico mais alto. Se vários registros SRV de DNS com prioridade e peso iguais forem retornados, o serviço de Borda de Acesso escolherá o primeiro registro SRV que vier do servidor DNS.

Compartilhar via