Registro de serviço

Um registro SRV ou serviço de registro é uma categoria de dados DNS da Internet , que visa identificar quais serviços estão disponíveis. Esse tipo de registro é definido na RFC 2782. Protocolos mais recentes (por exemplo, SIP e XMPP ) geralmente exigem suporte ao cliente para registros SRV. Além disso, as implementações do lado do cliente de protocolos mais antigos, como LDAP , SMTP também podem ter suporte para registros SRV adicionados.

Formato de gravação

Um registro SRV contém as seguintes informações:

Serviço : o nome simbólico (geralmente começando com um sublinhado) do serviço relevante (por exemplo, _sip ).
Protocolo : geralmente é "_tcp" para TCP ou "_udp" para UDP .
Nome de domínio : o domínio de validade do registro (totalmente qualificado no formato FQDN ou local para a zona DNS sendo definida para a mesma autoridade de origem).
TTL : campo DNS padrão que indica o período de validade ( Time-To-Live ) da resposta (em segundos).
Classe : campo DNS padrão que indica a classe de endereçamento (é sempre IN para a Internet).
Tipo : o identificador do tipo de registro DNS (sempre SRV aqui para um registro de serviço)
Prioridade : a prioridade do servidor de destino (valor inteiro não negativo, quanto menor for, mais este servidor será usado se estiver disponível). Se houver vários registros com prioridades diferentes para o mesmo serviço e o mesmo protocolo, um único registro para cada uma das prioridades será retornado aos clientes DNS (espera-se que os clientes tentem se conectar primeiro ao servidor retornado com o valor de prioridade mais baixo entre os registros retornados, mas se isso falhar, eles podem usar o próximo servidor de maior prioridade na lista de servidores retornados). Diferentes prioridades tornam possível configurar serviços de emergência (possivelmente distintos no seu conteúdo e mais limitados nas possibilidades, por exemplo, um ou mais servidores alternativos operando em modo somente leitura sem suporte para certas modificações pelo serviço).
Peso : peso relativo para registros de mesma prioridade (valor inteiro de 0 a 65535, permite que o servidor DNS retorne aleatoriamente um dos servidores de destino com a mesma prioridade, com uma distribuição correspondente ao peso indicado, em relação ao peso total de os demais registros de mesma prioridade). O peso indicado não tem efeito se houver apenas um servidor de destino com a mesma prioridade para o mesmo serviço e o mesmo protocolo (este parâmetro permite uma distribuição de carga bastante básica entre vários servidores para os serviços muito frequentados por muitos clientes fazendo consultas DNS separadas, mas não terá efeito se esses clientes fizerem suas consultas DNS por meio do mesmo servidor DNS de cache proxy).
Porta : o número da porta (TCP ou UDP de acordo com o protocolo acima) onde o serviço está disponível.
Destino : o nome do servidor que fornece o serviço em questão (deve ser resolvido para um endereço IPv4 ou IPv6 por outras consultas DNS nos registros A ou AAAA do nome do serviço de destino) com o protocolo e na porta indicada.

Por exemplo, os registros SRV podem ter a seguinte aparência:

_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip1.example.com. _sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip2.example.com. _sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip3.example.com. _sip._tcp.example.com. 86400 IN SRV 10 100 5060 serveursip-offline.example.com.

Eles apontam para três servidores chamados ipservers {1,2,3} .example.com que esperam por conexões SIP na porta TCP número 5060. Aqui, a prioridade indicada é 0 (prioridade padrão por padrão), e o peso desses servidores é 33 (o servidor DNS irá retornar aleatoriamente um dos 3 servidores para os clientes DNS, mas razoavelmente). O período de validade indicado (86400 segundos ou um dia inteiro) permite que os clientes DNS mantenham esta informação em seu cache local por um dia inteiro antes de ter que consultar novamente o servidor DNS.

O servidor também retornará os clientes a um segundo servidor para suas consultas, apontando para serversip-offline.example.com que fornecerá serviço SIP (possivelmente limitado) se os clientes não conseguirem se conectar a um dos três primeiros servidores (este servidor de backup com um prioridade indicada em 10 em vez de 0, não se destina ao uso permanente por clientes, mas pode ser usado para o tempo de uma operação de manutenção em um dos 3 servidores SIP básicos, seu peso especificado em 100 não tem efeito se for o único servidor em espera).

Compartilhamento de carga com SRV

O campo Priority é semelhante ao campo de mesmo nome nos registros MX . Os clientes começam com o registro SRV de menor prioridade e recorrem a outros registros apenas se a conexão falhar. Assim, um serviço pode ter um servidor designado como servidor standby, que só será utilizado em caso de falha do servidor primário: basta inserir um registo SRV com prioridade superior ao do servidor primário.

Quando um serviço tem vários registros SRV com a mesma prioridade, os clientes usam o campo de peso para decidir qual servidor usar. O peso só faz sentido quando colocado em relação ao peso dos demais registros de mesma prioridade (sempre para um determinado serviço).

No exemplo abaixo, os campos de prioridade e peso são usados , a fim de fornecer simultaneamente o balanceamento de carga e serviço de backup.

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 gros-serveur.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur1.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur2.example.com. _sip._tcp.example.com. 86400 IN SRV 20 100 5060 serveur-de-secours.example.com.

Todos os três primeiros registros têm uma prioridade de 10. Os clientes, portanto, terão que usar o campo de peso para determinar qual servidor entrar em contato. Para este campo, a soma dos três valores é 100, então big-server.example.com será usado 60% do tempo, e cada um dos outros dois ( small-server1 e small-server2 ) será usado 20% do tempo. Se, por acaso, um grande servidor ficasse indisponível, os dois "pequenos servidores", sozinhos na pista, iriam então partilhar a carga, com peso idêntico.

Além disso, se todos os três desses servidores de prioridade 10 ficarem indisponíveis, o próximo registro de prioridade mais alta será escolhido, neste caso emergência-server.example.com . Pode ser uma máquina geograficamente distante das outras três, portanto, a priori, não afetada pela causa de sua indisponibilidade.

O balanceamento de carga fornecido pelos registros SRV é necessariamente limitado, uma vez que as informações são essencialmente estáticas. A carga real do servidor não é levada em consideração.

usar

Os registros SRV costumam ser usados por clientes Microsoft Windows 2000 para localizar o controlador de domínio de um determinado serviço.

Além disso, os registros SRV são comumente usados em conjunto com os protocolos padrão abaixo:

Comandos úteis

Para verificar a presença de um registro SRV em um domínio, os comandos nslookup e dig podem ser usados.

Por exemplo :

dig SRV _sip._tcp.example.com. +short

Exemplo real:

% dig SRV _sip._tcp.jabber.com. +short 10 33 5060 cjv-sbc-trunk-2.global.jabber.com. 10 33 5060 cjv-sbc-trunk-1.global.jabber.com. 10 34 5060 cjv-sbc-trunk-3.global.jabber.com.

ou :

nslookup -q=SRV _sip._tcp.example.com.

Exemplo real:

% nslookup -q=SRV _sip._tcp.jabber.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: _sip._tcp.jabber.com service = 10 33 5060 cjv-sbc-trunk-1.global.jabber.com. _sip._tcp.jabber.com service = 10 33 5060 cjv-sbc-trunk-2.global.jabber.com. _sip._tcp.jabber.com service = 10 34 5060 cjv-sbc-trunk-3.global.jabber.com. Authoritative answers can be found from:

Veja também

links externos

RFC 2782 [ 1 ] , definindo registros SRV
Glossário DNS Masculino e Ratos - Registro SRV
Artigos de Rick van Rein sobre SRV Resource Records
Lista exaustiva de tipos de serviço SRV definidos
VPF SRV Registry - VoIP peering usando registros SRV

(en) Request for comments n o 2.782 .