Determinar requisitios de DNS para Lync Server 2013

  • Artigo

 

Tópico última modificação: 22-02-2013

Use o fluxograma a seguir para determinar os requisitos do DNS (Sistema de Nomes de Domínio). As alterações do Atualizações cumulativo para o Lync Server 2013: fevereiro de 2013 são notadas onde elas se aplicam.

Importante

O Microsoft Lync Server 2013 dá suporte ao uso de endereçamento IPv6. Para usar endereços IPv6, você também deve fornecer suporte para DNS IPv6 e configurar registros AAAA do host DNS (conhecidos como registros "quad-A"). Em implantações em que IPv4 e IPv6 estão sendo usados, é melhor configurar e manter ambos os registros de host A para IPv4 e hospedar AAAA para IPv6. Mesmo que sua implantação tenha feito a transição completa para IPv6, os registros de host DNS IPv4 ainda poderão ser necessários quando usuários externos ainda usarem IPv4.

Determinando o fluxograma de requisitos de DNS

175782ac-363e-408a-912f-8991bf152970

Importante

Por padrão, o nome do computador de um computador que não está associado a um domínio é um nome de host, não um FQDN (nome de domínio totalmente qualificado). O Construtor de Topologias usa FQDNs, não nomes de host. 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, consulte Configurar registros de host 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 em como o cliente localiza e acessa serviços no Lync Server 2013. A exceção importante é o aplicativo Lync da Windows Store que usa um processo de local de serviço diferente. Esta seção detalha dois cenários de como os clientes localizam serviços, primeiro o método tradicional usando uma série de registros de host SRV e A, em segundo lugar usando apenas os registros de serviço de Descoberta Automática. As atualizações cumulativas para os clientes da área de trabalho alteram o processo de localização DNS do Lync Server 2010 Para todos os clientes, o processo de consulta DNS continua até que uma consulta bem-sucedida seja retornada ou a lista de possíveis registros DNS seja esgotada e o erro final seja retornado ao cliente.

Para todos os clientes, exceto para o aplicativo Lync da Windows Store durante a pesquisa de DNS, os registros SRV são consultados e retornados ao cliente na seguinte ordem:

  1. lyncdiscoverinternal.< registro> de domínio A (host) para o serviço de Descoberta Automática nos serviços Web internos

  2. lyncdiscover.< registro> de domínio A (host) para o serviço de Descoberta Automática nos serviços Web externos

  3. _sipinternaltls._tcp.< registro> SRV de domínio (localizador de serviço) para conexões TLS internas

  4. _sipinternal._tcp.< registro> SRV de domínio (localizador de serviço) para conexões TCP internas (executadas somente se o TCP for permitido)

  5. _sip._tls.< registro> SRV de domínio (localizador de serviço) para conexões TLS externas

  6. sipinternal.< registro> de domínio A (host) para o pool de Front-Ends ou Diretor, que pode ser resolvido somente na rede interna

  7. Sip.< registro> de domínio A (host) para o pool de Front-Ends ou Diretor na rede interna ou o serviço de Borda de Acesso quando o cliente é externo

  8. sipexternal.< registro> de domínio A (host) para o serviço do Access Edge quando o cliente é externo

O aplicativo Lync da Windows Store altera completamente o processo porque usa dois registros:

  1. lyncdiscoverinternal.< registro> de domínio A (host) para o serviço de Descoberta Automática nos serviços Web internos

  2. lyncdiscover.< registro> de domínio A (host) para o serviço de Descoberta Automática nos serviços Web externos

Não há nenhum fallback para os outros tipos de registro.

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

Quando uma conexão é bem-sucedida, o Serviço de Descoberta Automática retorna todas as URLs dos Serviços Web para o pool inicial do usuário, 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 urLs do agendador da Web. No entanto, a URL interna do Serviço de Mobilidade e a URL externa do Serviço de Mobilidade estão associadas ao FQDN externo dos Serviços Web. Portanto, independentemente de um dispositivo móvel ser interno ou externo à rede, o dispositivo sempre se conecta ao Serviço de Mobilidade externamente por meio do proxy reverso.

Se o Atualizações cumulativo do Lync Server 2013: fevereiro de 2013 tiver sido instalado, o Serviço de Descoberta Automática também retornará referências a Internal/UCWA, External/UCWA e UCWA. Essas entradas referem-se ao componente Web UCWA (Unified Communications Web API). Atualmente, somente a entrada UCWA é usada e fornece uma referência a uma URL para o componente Web. O UCWA é usado por clientes do Lync 2013 Mobile em vez do Mcx Mobility Service usado pelos clientes do Lync 2010 Mobile.

Nota

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

Ponta

A configuração padrão é direcionar todo o tráfego do cliente móvel por meio do site externo. Você pode modificar as configurações para retornar apenas a URL interna, se isso for mais preferível para seus requisitos. Com essa configuração, os usuários podem usar aplicativos móveis do Lync em seus dispositivos móveis somente quando estiverem dentro da rede corporativa. Para definir essa configuração, use o cmdlet Set-CsMcxConfiguration .

Nota

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

Os dispositivos móveis dão suporte à descoberta manual de serviços. Nesse caso, cada usuário deve definir as configurações de dispositivo móvel com os URIs completos do Serviço de Descoberta Automática interna e externa, incluindo o protocolo e o caminho, da seguinte maneira:

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

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

Recomendamos que você use a descoberta automática, em vez de a descoberta manual. No entanto, as configurações manuais podem ser úteis para solucionar problemas de conectividade de dispositivo móvel.

Configurando Split-Brain DNS com o Lync Server

O DNS de dupla personalidade é conhecido por vários nomes, por exemplo, DNS dividido ou DNS de horizonte dividido. Simplesmente, ele descreve uma configuração de DNS em que há duas zonas DNS com o mesmo namespace , mas uma zona DNS serviços apenas solicitações internas e as outras solicitações somente externas de serviços de zona DNS. No entanto, muitos dos registros DNS SRV e A contidos no DNS interno não estarão contidos no DNS externo e o inverso também será verdadeiro. Nos casos em que o mesmo registro DNS existir no DNS interno e externo (por exemplo, www.contoso.com), o endereço IP retornado será diferente com base em onde (interno ou externo) a consulta foi iniciada.

Importante

Atualmente, Split-Brain DNS não tem suporte para a mobilidade ou, mais especificamente, os registros DNS LyncDiscover e LyncDiscoverInternal. O LyncDiscover deve ser definido em um servidor DNS externo e o LyncDiscoverInternal deve ser definido em um servidor DNS interno.

Para os fins desses tópicos, o termo DNS de dupla personalidade será usado.

Se você estiver configurando o DNS de dupla personalidade, a zona interna e externa a seguir conterá um resumo dos tipos de registros DNS necessários em cada zona. Para obter detalhes, consulte Cenários para acesso de usuário externo no Lync Server 2013.

DNS interno:

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

  • A zona contoso.com interna contém:

    • DNS A e AAAA (se você estiver usando endereçamento IPv6) e registros SRV para configuração automática do cliente Lync Server 2013 interno (opcional)

    • Registros DNS A e AAAA (se você estiver usando endereçamento IPv6) ou registros CNAME para descoberta automática de Serviços Web do Lync Server 2013 (opcional)

    • Registros DNS A e AAAA (se você estiver usando endereçamento IPv6) para nome do pool de Front-End, nome do pool de Diretor ou Diretor e todos os servidores internos que executam o Lync Server 2013 na rede corporativa

    • Registros DNS A e AAAA (se você estiver usando endereçamento IPv6) para a interface interna do Edge de cada Lync Server 2013, Servidor de Borda na rede de perímetro

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

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

    • Todos os servidores que executam o Lync Server 2013 e os clientes que executam o Lync 2013 na rede corporativa apontam para os servidores DNS internos para resolver consultas para o contoso.com ou usar o arquivo HOSTS em cada servidor de borda e listar registros A e AAAA (se você estiver usando endereçamento IPv6) para o servidor do próximo salto, especificamente o VIP diretor ou diretor, VIP do pool de front-end ou servidor Standard Edition

DNS externo:

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

  • A zona contoso.com externa contém:

    • Registros DNS A e AAAA (se você estiver usando endereçamento IPv6) e registros SRV para configuração automática de cliente do Lync Server 2013 (opcional)

    • Registros DNS A e AAAA (se você estiver usando endereçamento IPv6) ou registros CNAME para descoberta automática de Serviços Web do Lync Server 2013 para uso com mobilidade

    • DNS A e AAAA (se você estiver usando endereçamento IPv6) e registros SRV para a interface externa de borda de cada Lync Server 2013, Servidor de Borda ou IP virtual (VIP) do balanceador de carga de hardware na rede de perímetro

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

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

Usando o DNS de dupla personalidade, um usuário do Lync Server 2013 que entra internamente poderá aproveitar a configuração automática se a zona DNS interna contiver um registro SRV _sipinternaltls._tcp para cada domínio SIP em uso. No entanto, se você não usar o DNS de dupla personalidade, a configuração automática interna de clientes que executam o Lync não funcionará, a menos que uma das soluções alternativas descritas mais adiante nesta seção seja implementada. Isso ocorre porque o Lync Server 2013 exige que o URI SIP do usuário corresponda ao domínio do pool de Front-Ends designado para configuração automática. Esse também foi o caso com versões anteriores do Communicator.

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

  • Se um usuário bob@contoso.com entrar como o seguinte registro SRV 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-Ends de configuração automática):

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

  • Se um usuário entrar como o seguinte alice@fabrikam.com registro 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, tim@litwareinc.com se um usuário entrar como o seguinte registro SRV DNS 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 que executam o Lync, selecione uma das seguintes opções:

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

    Nota

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

  • Zona interna correspondente Crie uma zona no DNS interno que corresponda à zona DNS externa (por exemplo, contoso.com) e crie registros DNS A e AAAA (se você estiver usando endereçamento IPv6) correspondentes ao pool do Lync Server 2013 usado para configuração automática. Por exemplo, se um usuário estiver hospedado no pool01.contoso.net, mas entrar no Lync bob@contoso.comcomo , crie uma zona DNS interna chamada contoso.com e, dentro dela, crie um registro DNS A e AAAA (se o endereçamento IPv6 for usado) para pool01.contoso.com.

  • Zona interna do ponto de fixação Se você estiver criando uma zona inteira no DNS interno não for uma opção, poderá criar zonas de ponto de pino (ou seja, dedicadas) que correspondam aos registros SRV necessários para a configuração automática e preencher essas zonas usando dnscmd.exe. Dnscmd.exe é necessário porque a interface do usuário DNS não dá suporte à criação de zonas de ponto de pino. Por exemplo, se o domínio SIP for contoso.com e você tiver um pool de Front-Ends chamado pool01 que contenha dois Servidores Front-End, você precisará das seguintes zonas de ponto de pino 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>

    Se seu ambiente contiver um segundo domínio SIP (por exemplo, fabrikam.com), você precisará das seguintes zonas de ponto de pino 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>

Nota

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, mas se o balanceamento de carga de hardware for usado, haverá apenas uma única entrada de pool de Front-End. Além disso, os valores de FQDN do pool de front-end mudam entre o exemplo de contoso.com e o fabrikam.com, mas os endereços IP permanecem os mesmos. Isso ocorre porque os usuários que estão entrando de um dos domínios SIP usam o mesmo pool de Front-Ends para configuração automática.

Para obter detalhes, consulte o artigo do blog 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.

Configurando o DNS (sistema de nomes de domínio) para recuperação de desastre

Para configurar o DNS para redirecionar o tráfego da Web do Lync Server 2013 para seus sites de recuperação de desastre e failover, você deve estar usando um provedor DNS que dê suporte a GeoDNS. Você pode configurar seus registros DNS para a Web para dar suporte à recuperação de desastre, para que os recursos que usam serviços Web continuem mesmo se um pool de Front-End inteiro ficar inativo. Esse recurso de recuperação de desastre dá suporte à DESCOBERTA Automática (URL do Lyncdiscover), ÀS URLs simples de Reunião e Discagem.

Você define e configura registros adicionais de host DNS (A e AAAA se estiver usando IPv6) para resolução interna e externa de serviços Web em seu provedor GeoDNS. Os detalhes a seguir pressupõem pools emparelhados, geograficamente dispersos e GeoDNS compatíveis com seu provedor com DNS round robin ou configurados para usar Pool1 como primário e failover para Pool2 em caso de perda de comunicações ou falha de hardware.

Registro GeoDNS (exemplo) Registros de pool (exemplo) Registros 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

Use 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

Use 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

Use 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

Use 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

Use 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

Use 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

Use 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

Use primário, conecte-se ao secundário em caso de falha

DNS Load Balancing

O balanceamento de carga DNS normalmente é implementado no nível do aplicativo. O aplicativo (por exemplo, um cliente que executa o Lync) tenta se conectar a um servidor em um pool conectando-se a um dos endereços IP retornados da consulta de registro DNS A e AAAA (se o endereçamento IPv6 for usado) para o FQDN (nome de domínio totalmente qualificado) do pool.

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

  • Clientes que executam o DNS de consulta do Lync para pool01.contoso.com. A consulta retorna três endereços IP e os armazena em cache da seguinte maneira (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

  • O cliente tenta estabelecer uma conexão TCP (Protocolo de Controle de Transmissão) com um dos endereços IP. Se isso falhar, o cliente tentará o próximo endereço IP no 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 armazenadas em cache sem uma conexão bem-sucedida, o usuário será notificado de que nenhum servidor executando o Lync Server 2013 está disponível no momento.

Nota

O balanceamento de carga baseado em DNS é diferente do DNS RR (round robin), que normalmente se refere ao balanceamento de carga, contando com o 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 e AAAA (se você estiver usando endereçamento IPv6) falhar, a conexão falhará. Portanto, o round robin de DNS por si só é menos confiável do que o balanceamento de carga baseado em DNS. Você pode usar o round robin dns em conjunto com o balanceamento de carga dns.

O balanceamento de carga DNS é usado para o seguinte:

  • SIP de balanceamento de carga de servidor para servidor para os Servidores de Borda

  • Aplicativos UCAS (Unified Communications Application Services) de balanceamento de carga, como Atendedor Automático de Conferência, Grupo de Resposta e Estacionamento de Chamada

  • Impedir novas conexões com aplicativos UCAS (também conhecido como "esvaziamento")

  • Balanceamento de carga de todo o tráfego de cliente para servidor entre clientes e servidores de borda

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

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

Balanceamento de carga DNS e tráfego federado:

Se vários registros DNS forem retornados por uma consulta DNS SRV, o serviço do Access Edge sempre escolherá o registro DNS SRV com a prioridade numérica mais baixa e o maior peso numérico. O documento "Um RR dns para especificar o local dos serviços (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt especifica que, se houver vários registros SRV DNS definidos, a prioridade será usada primeiro e, em seguida, a espessura. Por exemplo, o registro SRV dns A tem um peso de 20 e uma prioridade de 40 e o registro SRV dns B tem um peso de 10 e prioridade de 50. O registro SRV dns A com prioridade 40 será selecionado. As regras a seguir se aplicam à seleção de registro SRV dns:

  • A prioridade é considerada primeiro. Um cliente DEVE tentar contatar o host de destino definido pelo registro SRV dns com a prioridade numerada mais baixa que ele pode alcançar. Os destinos com a mesma prioridade DEVEM ser tentados em uma ordem definida pelo campo de peso.

  • O campo de peso especifica um peso relativo para entradas com a mesma prioridade. Pesos maiores DEVEM receber uma probabilidade proporcionalmente maior de ser selecionado. Os administradores DNS DEVEM usar o Peso 0 quando não há nenhuma seleção de servidor a ser executada. Na presença de registros contendo pesos maiores que 0, os registros com peso 0 devem ter uma chance muito pequena de serem selecionados.

Se vários registros SRV DNS com prioridade e peso iguais forem retornados, o serviço de Borda do Access selecionará o registro SRV que foi recebido primeiro do servidor DNS.