Resumo

  • O DNS SRV permitiu que um domínio publicasse, para um serviço e transporte específicos, vários destinos, portas, camadas principais e de reserva e uma preferência estatística entre hosts da mesma camada.
  • Priority e Weight têm funções diferentes. O cliente tenta primeiro a menor prioridade numérica alcançável; só dentro dessa camada cria uma ordem aleatória ponderada.
  • O registro não prova saúde ou identidade. Ainda cabe ao cliente resolver o destino canônico, conectar ao transporte e porta publicados e validar a aplicação que respondeu.

Quando o cliente carregava a localização do serviço

O DNS inicial ligava um nome de host a um endereço. O aplicativo completava a descoberta com uma convenção: porta conhecida, tabela /etc/services ou nome exato de uma máquina divulgado pelo operador. Nome público, host, porta e contingência formavam uma suposição só.

O RFC 2052 propôs em outubro de 1996 um registro experimental para outra pergunta: onde fica um serviço dentro deste domínio? A resposta podia listar destinos com prioridade, peso e porta.

Em fevereiro de 2000, o RFC 2782 substituiu o texto como Proposed Standard. O objetivo era mover serviços entre hosts com menos atrito, usar vários servidores e separar principais de reservas. A IANA ainda registra SRV como tipo DNS 33, Server Selection.

O nome da consulta separou três decisões

Para achar LDAP sobre TCP em example.com, um cliente consulta _ldap._tcp.example.com. Os rótulos da esquerda declaram serviço e transporte; o restante delimita o domínio administrativo. O RFC 2782 acrescentou os sublinhados para reduzir colisão com nomes DNS comuns e esclareceu o algoritmo de pesos.

Depois veio disciplina de registro. O RFC 6335 unificou nomes de serviço e portas. Um nome registrado pode ser usado por SRV mesmo sem porta atribuída. Registrar coordena a cadeia, mas não endossa produto nem tráfego.

O RFC 8552 criou em 2019 o registro de nomes DNS globais com sublinhado. O RFC 8553 adaptou especificações que usam SRV a esse modelo, preservando implantações existentes. Uma convenção contra colisão virou um limite auditável.

Prioridade não é peso

Os dados SRV contêm Priority, Weight, Port e Target.

Priority cria camadas de failover. O cliente deve tentar um destino alcançável com o menor número. Uma camada superior não é um par que recebe menos carga; ela entra quando a preferida deixa de servir.

Weight vale apenas entre registros com a mesma Priority. O cliente soma pesos, sorteia um número uniforme, escolhe contra a soma acumulada, remove o destino e repete. A zona publica uma inclinação relativa; cada cliente produz sua ordem. Peso zero também não é proibição absoluta quando existem pesos positivos: o algoritmo deixa chance muito pequena.

No exemplo do RFC 2782, dois hosts de prioridade zero têm pesos um e três. Em muitas primeiras escolhas independentes, o segundo tende a cerca de três quartos. Dois hosts na prioridade um só aparecem se o par preferido falhar. Uma consulta não recebe promessa de proporção exata.

Weight não é telemetria de carga. CPU, fila e latência mudam mais rápido que um cache DNS. Persegui-las com TTLs curtos aumentaria a carga do DNS e reduziria a confiabilidade. O campo expressa capacidade estática relativa.

Port transfere outro conhecimento ao domínio. Pode coincidir com a porta registrada, mas não precisa. O serviço pode mudar de porta sem atualizar uma tabela em cada cliente.

Target deve ter endereços e não pode ser alias. O cliente usa A/AAAA da seção Additional ou consulta separadamente. A descoberta termina num host canônico; não esconde outra cadeia CNAME ou DNAME.

Não encontrar e declarar indisponibilidade são fatos diferentes

Um único Target . declara que o domínio decididamente não oferece aquele serviço. Não apaga o domínio nem outros serviços.

Sem SRV utilizável, o procedimento original consultava o endereço do domínio e tentava a convenção antiga. O RFC 2782 reconhecia que todos os clientes não seriam atualizados juntos. Recomendava endereços razoáveis para os antigos, mas não expor ali um host exclusivamente de backup se ele seria tratado como principal.

Compatibilidade virou escolha operacional. Mantê-la preserva acesso e pode contornar prioridade e porta. Retirá-la alinha a política, mas pode isolar software legado.

Publicar candidatos não prova o serviço

O cliente analisa todo o RRset, agrupa por prioridade, ordena por peso, resolve endereços e tenta transporte, endereço e porta. Uma resposta DNS autêntica prova o que a autoridade publicou. Não prova processo saudável, identidade da aplicação, consentimento do host ou propriedade comum.

A expressividade amplia o efeito de informação falsa. Um falsificador pode fornecer porta errada além de host e endereço. Um domínio pode apontar para terceiro e enviar tráfego indesejado. Portas finas complicam filtros e aproximam operações DNS e de rede.

O uso também depende da especificação da aplicação: ela deve autorizar SRV, definir o nome simbólico e tratar segurança. O protocolo dá significado; o domínio publica; o cliente executa; o destino ainda prova o serviço.

Fontes e limites

A reconstrução usa apenas RFC 2052, RFC 2782, RFC 6335, RFC 8552, RFC 8553 e os parâmetros DNS da IANA. Eles provam contrato e evolução, não adoção atual, ganho de latência, conformidade de produtos ou saúde de serviço vivo.

O SRV deixou o serviço sobreviver a um host e porta sem dar ao DNS poder para substituir conexão e autenticação da aplicação.