Determinar requisitios de DNS para Lync Server 2013

 

Tópico Última Modificação: 2013-02-22

Utilize o seguinte fluxograma para determinar os requisitos do Sistema de Nomes de Domínio (DNS). As alterações à Atualizações Cumulativa do Lync Server 2013: fevereiro de 2013 são indicadas onde se aplicam.

Importante

O Microsoft Lync Server 2013 suporta a utilização de endereçamento IPv6. Para utilizar endereços IPv6, também tem de fornecer suporte para registos DNS IPv6 e configurar o anfitrião DNS AAAA (conhecido como "quad-A"). Nas implementações em que o IPv4 e o IPv6 estão a ser utilizados, é melhor configurar e manter os registos A do anfitrião para IPv4 e o anfitrião AAAA para IPv6. Mesmo que a sua implementação tenha transitado totalmente para IPv6, os registos de anfitrião DNS IPv4 ainda poderão ser necessários quando os utilizadores externos ainda estiverem a utilizar o IPv4.

Determinar o Fluxograma de Requisitos de DNS

Importante

Por predefinição, o nome do computador de um computador que não está associado a um domínio é um nome de anfitrião e não um nome de domínio completamente qualificado (FQDN). O Topology Builder utiliza FQDNs, não nomes de anfitriões. Portanto, você deverá configurar um sufixo DNS no nome do computador a ser implantado no Servidor de Borda que não ingressou no domínio. Use apenas caracteres padrão (incluindo A–Z, a–z, 0–9 e hifens) ao atribuir FQDNs de seus Lync Servers, Servidores de Borda e pools. Não use caracteres Unicode ou sublinhados. Normalmente, caracteres não padrão no FQDN não são suportados por DNS externo e CAs públicas (ou seja, quando o FQDN deve ser atribuído ao SN no certificado). Para obter detalhes adicionais, veja Configurar registos de Anfitrião DNS para o Lync Server 2013

Como Os Clientes do Lync Localizam Serviços

O Microsoft Lync 2010, o Lync 2013 e o Lync Mobile são semelhantes na forma como o cliente localiza e acede aos serviços no Lync Server 2013. A exceção notável é a aplicação Lync da Loja Windows que utiliza um processo de localização de serviço diferente. Esta secção detalha dois cenários de como os clientes localizam os serviços, primeiro o método tradicional com uma série de registos de anfitrião SRV e A, em segundo lugar, utilizando apenas os registos do serviço de Deteção Automática. As atualizações cumulativas para os clientes de ambiente de trabalho alteram o processo de localização DNS do Lync Server 2010 Para todos os clientes, o processo de consulta DNS continua até ser devolvida uma consulta com êxito ou a lista de possíveis registos DNS está esgotada e o erro final é devolvido ao cliente.

Para todos os clientes , exceto para a aplicação Lync da Loja Windows Durante a pesquisa de DNS, os registos SRV são consultados e devolvidos ao cliente pela seguinte ordem:

1. lyncdiscoverinternal.<domínio> A (anfitrião) registo para o serviço de Deteção Automática nos serviços Web internos

2. lyncdiscover.<domínio> A (anfitrião) registo para o serviço de Deteção Automática nos serviços Web externos

3. _sipinternaltls._tcp.<registo SRV do domínio> (localizador de serviços) para ligações TLS internas

4. _sipinternal._tcp.<domínio> SRV (localizador de serviço) para ligações TCP internas (efetuada apenas se o TCP for permitido)

5. _sip._tls.<registo SRV do domínio> (localizador de serviços) para ligações TLS externas

6. sipinternal.<domain> A (host) record for the Front End pool or Director, resolvable only on the internal network

7. sip.<domain> A (host) record for the Front End pool or Director on the internal network, or the Access Edge service when the client is external

8. sipexternal.<domínio> Um registo (anfitrião) para o serviço Do Access Edge quando o cliente é externo

A aplicação Lync da Loja Windows altera completamente o processo porque utiliza dois registos:

1. lyncdiscoverinternal.<domínio> A (anfitrião) registo para o serviço de Deteção Automática nos serviços Web internos

2. lyncdiscover.<domínio> A (anfitrião) registo para o serviço de Deteção Automática nos serviços Web externos

Não existe nenhuma contingência para os outros tipos de registo.

A diferença entre os métodos utilizados para clientes mais recentes em comparação com clientes mais antigos é que o serviço de Deteção Automática está a tornar-se o método preferencial para localizar todos os serviços.

Quando uma ligação é efetuada com êxito, o Serviço de Deteção Automática devolve todos os URLs dos Serviços Web do conjunto doméstico do utilizador, incluindo o Serviço de Mobilidade (conhecido como Mcx pelo diretório virtual criado para o serviço no IIS), o Microsoft Lync Web App e os URLs do web scheduler. No entanto, tanto o URL interno do Serviço de Mobilidade como o URL do Serviço de Mobilidade externo estão associados ao FQDN dos Serviços Web externos. Por conseguinte, independentemente de um dispositivo móvel ser interno ou externo à rede, o dispositivo liga-se sempre ao Serviço de Mobilidade externamente através do proxy inverso.

Se a Atualizações Cumulativa do Lync Server 2013: fevereiro de 2013 tiver sido instalada, o Serviço de Deteção Automática também devolve referências para Internal/UCWA, External/UCWA e UCWA. Estas entradas referem-se ao componente Web da API Web de Comunicações Unificadas (UCWA). Atualmente, apenas a entrada UCWA é utilizada e fornece uma referência a um URL para o componente Web. A UCWA é utilizada por clientes Lync 2013 Mobile em vez do Mcx Mobility Service utilizado pelos clientes Lync 2010 Mobile.

Nota

Ao criar registos SRV, é importante lembrar que têm de apontar para um registo DNS A e AAAA (se estiver a utilizar endereçamento IPv6) no mesmo domínio em que o registo SRV DNS é criado. Por exemplo, se o registo SRV estiver no contoso.com, o registo A e AAAA (se estiver a utilizar endereçamento IPv6), significa que não pode estar no fabrikam.com.

Sugestão

A configuração predefinida é direcionar todo o tráfego de cliente móvel através do site externo. Pode modificar as definições para devolver apenas o URL interno, se for mais preferível para os seus requisitos. Com esta configuração, os utilizadores só podem utilizar aplicações móveis do Lync nos respetivos dispositivos móveis quando estiverem dentro da rede empresarial. Para definir esta configuração, utilize o cmdlet Set-CsMcxConfiguration .

Nota

Embora as aplicações móveis também possam ligar a outros serviços do Lync Server 2013, como o Serviço de Livro de Endereços, os pedidos Web de aplicações móveis internos vão para o FQDN Web externo apenas para o Serviço de Mobilidade. Outros pedidos de serviço, como pedidos do Livro de Endereços, não requerem esta configuração.

Os dispositivos móveis suportam a deteção manual de serviços. Neste caso, cada utilizador tem de configurar as definições do dispositivo móvel com os URIs completos do Serviço de Deteção Automática interna e externa, incluindo o protocolo e o caminho, da seguinte forma:

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

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

Recomendamos que utilize a deteção automática, em vez da deteção manual. No entanto, as definições manuais podem ser úteis para resolver problemas de conectividade de dispositivos móveis.

Configurar Split-Brain DNS com o Lync Server

O DNS split-brain é conhecido por vários nomes, por exemplo, DNS dividido ou DNS de horizonte dividido. Simplesmente, descreve uma configuração DNS em que existem duas zonas DNS com o mesmo espaço de nomes, mas um serviço de zona DNS apenas pede internamente e a outra zona DNS presta pedidos apenas externos. No entanto, muitos dos registos DNS SRV e A contidos no DNS interno não serão contidos no DNS externo e o inverso também é verdadeiro. Nos casos em que exista o mesmo registo DNS no DNS interno e externo (por exemplo, www.contoso.com), o endereço IP devolvido será diferente com base no local onde (interno ou externo) a consulta foi iniciada.

Importante

Atualmente, Split-Brain DNS não é suportado para a mobilidade ou, mais especificamente, para os registos DNS LyncDiscover e LyncDiscoverInternal. O LyncDiscover tem de ser definido num servidor DNS externo e o LyncDiscoverInternal tem de ser definido num servidor DNS interno.

Para efeitos destes tópicos, será utilizado o termo DNS split-brain.

Se estiver a configurar o DNS split-brain, a seguinte zona interna e externa contém um resumo dos tipos de registos DNS necessários em cada zona. Para obter detalhes, veja Cenários para acesso de utilizador externo no Lync Server 2013.

DNS interno:

• Contém uma zona DNS denominada contoso.com para a qual é autoritativa

• A zona de contoso.com interna contém:

  • DNS A e AAAA (se estiver a utilizar endereçamento IPv6) e registos SRV para a configuração automática de cliente do Lync Server 2013 interno (opcional)

  • DNS A e AAAA (se estiver a utilizar endereçamento IPv6) ou registos CNAME para deteção automática dos Serviços Web do Lync Server 2013 (opcional)

  • Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para o nome do conjunto de Front-End, o Nome do conjunto de diretórios ou diretórios e todos os servidores internos com o Lync Server 2013 na rede empresarial

  • Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para a interface interna do Edge de cada Lync Server 2013, Edge Server na rede de perímetro

  • Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para a interface interna de cada servidor proxy inverso na rede de perímetro (opcional para gestão do proxy inverso)

  • Todas as interfaces edge internas do Lync Server 2013 Edge Server na rede de perímetro utilizam a zona DNS interna para resolver consultas para contoso.com

  • Todos os servidores com o Lync Server 2013 e clientes com o Lync 2013 na rede empresarial apontam para os servidores DNS internos para resolver consultas para contoso.com ou a utilização do ficheiro HOSTS em cada servidor Edge e listar registos A e AAAA (se estiver a utilizar o endereçamento IPv6) para o servidor de salto seguinte, especificamente o Vip de Diretor ou Diretor, VIP do conjunto de Front-End ou servidor do Standard Edition

DNS externo:

• Contém uma zona DNS denominada contoso.com para a qual é autoritativa

• A zona de contoso.com externa contém:

  • DNS A e AAAA (se estiver a utilizar endereçamento IPv6) e registos SRV para a configuração automática do cliente do Lync Server 2013 (opcional)

  • DNS A e AAAA (se estiver a utilizar endereçamento IPv6) ou registos CNAME para deteção automática dos Serviços Web do Lync Server 2013 para utilização com mobilidade

  • DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) e registos SRV para a interface externa edge de cada Lync Server 2013, Edge Server ou IP virtual de balanceador de carga de hardware (VIP) na rede de perímetro

  • Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para a interface externa do servidor proxy inverso ou VIP para um conjunto de servidores proxy inversos na rede de perímetro

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

Com o DNS split-brain, um utilizador do Lync Server 2013 que inicia sessão internamente pode tirar partido da configuração automática se a zona DNS interna contiver um registo SRV _sipinternaltls._tcp para cada domínio SIP em utilização. No entanto, se não utilizar o DNS split-brain, a configuração automática interna dos clientes que executam o Lync não funcionará, a menos que uma das soluções descritas posteriormente nesta secção seja implementada. Isto deve-se ao facto de o Lync Server 2013 exigir que o URI SIP do utilizador corresponda ao domínio do conjunto de Front-End designado para configuração automática. Também foi o caso das versões anteriores do Communicator.

Por exemplo, se tiver dois domínios SIP em utilização, serão necessários os seguintes registos do serviço DNS (SRV):

• Se um utilizador iniciar sessão como bob@contoso.com o seguinte registo SRV funcionará para a configuração automática porque o domínio SIP (contoso.com) do utilizador corresponde ao domínio do conjunto de Front-End de configuração automática):

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

• Se um utilizador iniciar sessão como alice@fabrikam.com o seguinte registo SRV DNS 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 utilizador iniciar sessão como tim@litwareinc.com o seguinte registo SRV DNS não funcionará para a configuração automática, porque o domínio SIP (litwareinc.com) do cliente não corresponde ao domínio em que se encontra o conjunto (fabrikam.com):

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

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

• Política de Grupo Objetos Utilize objetos Política de Grupo (GPOs) para preencher os valores de servidor corretos.

  Nota

  Esta opção não ativa a configuração automática, mas automatiza o processo de configuração manual, pelo que, se esta abordagem for utilizada, os registos SRV associados à configuração automática não são necessários.

• Zona interna correspondente Crie uma zona no DNS interno que corresponda à zona DNS externa (por exemplo, contoso.com) e crie registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) correspondentes ao conjunto do Lync Server 2013 utilizado para a configuração automática. Por exemplo, se um utilizador estiver alojada no pool01.contoso.net mas iniciar sessão no Lync como bob@contoso.com, crie uma zona DNS interna denominada contoso.com e, dentro dela, crie um registo DNS A e AAAA (se for utilizado endereçamento IPv6) para pool01.contoso.com.

• Zona interna de pin-point Se estiver a criar uma zona inteira no DNS interno não for uma opção, pode criar zonas de pin-point (ou seja, dedicadas) que correspondam aos registos SRV necessários para a configuração automática e preencher essas zonas com dnscmd.exe. Dnscmd.exe é necessária porque a interface de utilizador DNS não suporta a criação de zonas de pin-point. Por exemplo, se o domínio SIP estiver contoso.com e tiver um conjunto de Front-End chamado pool01 que contenha dois Servidores front-end, precisará das seguintes zonas de pin-point e registos A no 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>
  

  Se o seu ambiente contiver um segundo domínio SIP (por exemplo, fabrikam.com), precisará das seguintes zonas de pin-point e registos A no 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>
  

Nota

O FQDN do conjunto de Front-End é apresentado duas vezes, mas com dois endereços IP diferentes. Isto deve-se ao facto de o balanceamento de carga DNS ser utilizado, mas se for utilizado o balanceamento de carga de hardware, existirá apenas uma única entrada do conjunto de Front-End. Além disso, os valores do FQDN do conjunto de Front-End mudam entre o exemplo de contoso.com e o exemplo de fabrikam.com, mas os endereços IP permanecem os mesmos. Isto deve-se ao facto de os utilizadores que iniciam sessão a partir de qualquer um dos domínios SIP utilizarem o mesmo conjunto de Front-End para configuração automática.

Para obter detalhes, veja o artigo do blogue DMTF, "Communicator Automatic Configuration and Split-Brain DNS", em https://go.microsoft.com/fwlink/p/?linkId=200707.

Nota

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

Configurar o sistema de nomes de domínio (DNS) para Recuperação Após Desastre

Para configurar o DNS para redirecionar o tráfego Web do Lync Server 2013 para os seus sites de recuperação após desastre e ativação pós-falha, tem de utilizar um fornecedor de DNS que suporte GeoDNS. Pode configurar os seus registos DNS para a Web para suportar a recuperação após desastre, para que as funcionalidades que utilizam serviços Web continuem mesmo que um conjunto de Front-End inteiro fique inativo. Esta funcionalidade de recuperação após desastre suporta os URLs simples de Deteção Automática (URL de Deteção de Lyncdiscover), Meet e Dial-In.

Pode definir e configurar registos de anfitrião DNS adicionais (A e AAAA se utilizar IPv6) para resolução interna e externa de serviços Web no seu fornecedor de GeoDNS. Os detalhes seguintes partem do princípio de que os conjuntos emparelhados, geograficamente dispersos e GeoDNS suportados pelo seu fornecedor com DNS round robin ou configurados para utilizar o Pool1 como primário e efetuam a ativação pós-falha para o Pool2 em caso de perda de comunicações ou falha de hardware.

Registo GeoDNS (exemplo)	Registos de conjuntos (exemplo)	Registos CNAME (exemplo)	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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma 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 Utilizar primário, ligar à secundária se ocorrer uma falha

DNS Load Balancing

O balanceamento de carga DNS é normalmente implementado ao nível da aplicação. A aplicação (por exemplo, um cliente com o Lync) tenta ligar-se a um servidor num conjunto ao ligar a um dos endereços IP devolvidos a partir da consulta de registo DNS A e AAAA (se for utilizado o endereçamento IPv6) para o nome de domínio completamente qualificado (FQDN) do conjunto.

Por exemplo, se existirem três servidores front-end num conjunto com o nome pool01.contoso.com, ocorrerá o seguinte:

• Clientes com o DNS de consulta do Lync para pool01.contoso.com. A consulta devolve três endereços IP e coloca-os em cache da seguinte forma (não necessariamente por esta 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 ligação TCP (Transmission Control Protocol) a um dos endereços IP. Se isso falhar, o cliente tentará o endereço IP seguinte na 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 tentar todas as entradas em cache sem uma ligação com êxito, o utilizador será notificado de que não existem servidores com o Lync Server 2013 disponíveis neste momento.

Nota

O balanceamento de carga baseado em DNS é diferente do round robin de DNS (RR de DNS), que normalmente se refere ao balanceamento de carga ao depender do DNS para fornecer uma ordem diferente de endereços IP correspondentes aos servidores num conjunto. Normalmente, o RR de DNS só permite a distribuição de carga, mas não ativa a ativação pós-falha. Por exemplo, se a ligação ao endereço IP devolvido pela consulta DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) falhar, a ligação falhará. Por conseguinte, o round robin de DNS por si só é menos fiável do que o balanceamento de carga baseado em DNS. Pode utilizar o round robin de DNS em conjunto com o balanceamento de carga DNS.

O balanceamento de carga DNS é utilizado para o seguinte:

• Balanceamento de carga de servidor para servidor SIP para os Servidores Edge

• Balanceamento de carga de aplicações do Unified Communications Application Services (UCAS), tais como Atendedor Automático de Conferências, Grupo de Resposta e Call Park

• Impedir novas ligações a aplicações UCAS (também conhecidas como "drenagem")

• Balanceamento de carga de todo o tráfego cliente a servidor entre clientes e Servidores Edge

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

• Tráfego Web cliente a servidor para Servidores de Diretório ou Front-end

Balanceamento de carga DNS e tráfego federado:

Se forem devolvidos vários registos DNS por uma consulta SRV DNS, o serviço Access Edge escolhe sempre o registo SRV DNS com a prioridade numérica mais baixa e o peso numérico mais elevado. O documento "A DNS RR for specifying the location of services (DNS SRV)" (Um RR DNS para especificar a localização dos serviços (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt especifica que, se existirem vários registos SRV DNS definidos, a prioridade é utilizada primeiro e, em seguida, a ponderação. Por exemplo, o registo SRV DNS A tem um peso de 20 e uma prioridade de 40 e o registo SRV DNS B tem um peso de 10 e uma prioridade de 50. Será selecionado o registo DNS SRV A com prioridade 40. As seguintes regras aplicam-se à seleção de registos SRV DNS:

• A prioridade é considerada em primeiro lugar. Um cliente TEM de tentar contactar o anfitrião de destino definido pelo registo SRV de DNS com a prioridade numerada mais baixa que pode alcançar. Os destinos com a mesma prioridade DEVEM ser experimentados numa ordem definida pelo campo de ponderação.

• O campo de peso especifica um peso relativo para entradas com a mesma prioridade. Os pesos maiores DEVEM ter uma probabilidade proporcionalmente maior de serem selecionados. Os administradores de DNS DEVEM utilizar a ponderação 0 quando não existe nenhuma seleção de servidor para fazer. Na presença de registos que contenham pesos superiores a 0, os registos com peso 0 devem ter uma hipótese muito pequena de serem selecionados.

Se forem devolvidos vários registos SRV DNS com igual prioridade e ponderação, o serviço Access Edge irá selecionar o registo SRV que foi recebido primeiro a partir do servidor DNS.