Um dos servidores SIP do provedor cai numa madrugada e, de manhã, metade dos troncos não registra. Os que continuaram funcionando têm uma coisa em comum: apontavam para um domínio, e não para o IP fixo de um servidor, e deixavam o DNS dizer qual servidor, qual porta e qual transporte usar.
Esta é a Parte 4 da série. Na Parte 1 vimos os registros básicos e citamos o SRV de passagem; na Parte 2 e na Parte 3, PTR e e-mail. Agora chegamos ao assunto que liga o DNS ao dia a dia de quem trabalha com VoIP: como um telefone ou um PBX descobre o servidor SIP com NAPTR e SRV, e o que acontece quando o DNS derruba a chamada antes do primeiro INVITE.
O problema: um endereço SIP não diz onde está o servidor
Um endereço como sip:1000@example.com diz quem você quer alcançar, mas não diz para qual servidor mandar a mensagem, em qual porta, nem se é por UDP, TCP ou TLS. A RFC 3263 resolve isso com três consultas de DNS em sequência:
NAPTR: quais transportes o domínio oferece e em que ordem.
SRV: para cada transporte, quais servidores, em quais portas, com qual prioridade.
A ou AAAA: o IP de cada servidor.
Só depois disso sai o INVITE (ou o REGISTER). Se você já usou o nosso analisador de mensagens SIP, tudo isto acontece antes da primeira linha que aparece no trace.
NAPTR: quais transportes o domínio oferece
O NAPTR (RFC 3403) é o primeiro passo. Os registros reais do sip.linphone.org, consultados em 11/11/2026:
sip.linphone.org. IN NAPTR 10 100 "s" "SIPS+D2T" "" _sips._tcp.sip.linphone.org.
sip.linphone.org. IN NAPTR 20 100 "s" "SIP+D2T" "" _sip._tcp.sip.linphone.org.
sip.linphone.org. IN NAPTR 30 100 "s" "SIP+D2U" "" _sip._udp.sip.linphone.org.Lendo da esquerda para a direita:
Ordem (10, 20, 30): o menor número é tentado primeiro. Aqui o domínio prefere TLS.
Preferência (100): desempata registros com a mesma ordem.
Flag
s: a próxima consulta é um SRV.Serviço:
SIPS+D2Té SIP sobre TLS em TCP,SIP+D2Té SIP em TCP eSIP+D2Ué SIP em UDP.Substituição: o nome do SRV que deve ser consultado em seguida.
O cliente descarta os transportes que não suporta e segue o primeiro que sobra. Um telefone sem TLS, por exemplo, pula a linha 10 e vai para _sip._tcp.
SRV: servidores, portas, prioridade e peso
O SRV (RFC 2782) tem nome no formato _serviço._protocolo.domínio, como _sip._udp, _sip._tcp e _sips._tcp, e quatro campos: prioridade, peso, porta e destino. Os registros reais de TLS do mesmo domínio:
_sips._tcp.sip.linphone.org. IN SRV 0 100 5061 sip11.linphone.org.
_sips._tcp.sip.linphone.org. IN SRV 10 100 5061 sip12.linphone.org.
_sips._tcp.sip.linphone.org. IN SRV 20 100 443 sip11.linphone.org.Prioridade: a menor é tentada primeiro. O
sip12só recebe tráfego se osip11não responder; a terceira linha é um último recurso na porta 443.Peso: divide a carga entre destinos com a mesma prioridade, em proporção. Com pesos 60 e 40, cerca de 60% dos clientes escolhem o primeiro.
Porta: vem do DNS. É assim que um provedor usa uma porta diferente de 5060 sem que ninguém precise configurar nada.
Destino: precisa ter registro A ou AAAA e não pode ser um CNAME. Um destino
.(ponto) quer dizer “serviço não disponível neste domínio”.
Failover sem mexer em nada
A RFC 3263 manda o cliente tentar o próximo destino quando o atual não responde (timeout) ou devolve 503 Service Unavailable. O timeout padrão de uma transação SIP é de 32 segundos (64 vezes o T1 de 500 ms, RFC 3261): o failover é automático, mas uma chamada que “demora meio minuto para completar” costuma ser exatamente isso. Foi esse failover que salvou os troncos do exemplo do começo: quem apontava para o domínio passou a falar com o servidor de prioridade seguinte sem intervenção. Quem tinha o IP do servidor que caiu fixo no PBX ficou parado até alguém editar a configuração.
Quando não há NAPTR ou SRV
Nem todo domínio publica os três registros, e a RFC 3263 prevê os atalhos:
IP numérico no URI (
sip:1000@192.0.2.10): não há consulta de DNS nenhuma.Porta explícita (
sip:1000@example.com:5080): o cliente pula NAPTR e SRV e consulta só o A/AAAA.Transporte explícito (
;transport=tcp): o cliente pula o NAPTR e vai direto ao SRV daquele transporte.Sem NAPTR: o cliente consulta o SRV de cada transporte que suporta, como
_sip._udpe_sip._tcp.Sem NAPTR e sem SRV: usa UDP para
sip:e TLS sobre TCP parasips:, com o A/AAAA do domínio e a porta padrão: 5060, ou 5061 para TLS. Se o nome tiver vários endereços, o cliente tenta o próximo quando um falha.
Esse último caso explica uma confusão comum: o domínio “funciona” mesmo sem SRV, só que sem prioridade, sem peso e sempre na porta padrão; o failover fica limitado aos vários A/AAAA do nome, se houver. A consulta às portas e aos transportes de cada protocolo está na nossa tabela de portas de VoIP e redes.
Quando o DNS derruba a chamada
Alguns problemas que aparecem como “o SIP não registra” e são DNS:
Resolução lenta ou falhando. O INVITE só sai depois das consultas. Um resolvedor lento soma segundos ao início de cada chamada; um resolvedor fora do ar faz o PBX não achar ninguém. O sintoma no trace é o silêncio: nenhuma mensagem SIP sai.
SRV apontando para um nome sem A. O SRV está certo, mas o destino não resolve (erro de digitação, servidor desativado). O cliente desiste daquele destino e, se não houver outro, da chamada.
TTL alto atrasando a troca. O failover entre destinos do SRV é imediato, mas mudar o registro não é: um TTL de 86400 segundos faz os clientes usarem o valor antigo por até um dia. Antes de uma migração, baixe o TTL com antecedência, como vimos na Parte 1.
Certificado TLS que não confere. Pela RFC 5922, o cliente confere o certificado contra o domínio SIP do URI (
example.com), e não contra o nome que veio do SRV (sip11.example.com). Um certificado emitido só para o nome do servidor faz a conexão TLS cair, mesmo com o DNS perfeito.Registro só em UDP. O NAPTR prefere TCP ou TLS, mas o firewall libera só UDP 5060. O cliente obedece ao DNS e não conecta.
Diagnóstico na prática
Siga a mesma cadeia que o telefone segue:
dig NAPTR example.com +short
dig SRV _sips._tcp.example.com +short
dig SRV _sip._udp.example.com +short
dig A sip11.example.com +shortSe uma etapa volta vazia, você sabe exatamente em qual degrau a cadeia quebrou. No Wireshark, o filtro dns || sip mostra as consultas e as respostas logo antes do INVITE, com o tempo de cada uma. Para documentar o fluxo que você encontrou, o gerador de diagrama SIP monta a escada a partir de texto.
Checklist rápido
Configure o tronco pelo domínio que a operadora informou, não pelo IP.
Confira NAPTR e SRV com
dige veja se o transporte preferido passa pelo seu firewall.Todo destino de SRV resolve em A ou AAAA, sem CNAME.
TTL baixo antes de migrar e de volta ao normal depois.
Certificado com o domínio SIP quando o transporte for TLS.
Resumindo
O URI SIP diz quem, e o DNS diz onde: NAPTR, depois SRV, depois A/AAAA, e só então o INVITE (RFC 3263).
O NAPTR escolhe o transporte pela ordem; o SRV escolhe o servidor pela prioridade e divide a carga pelo peso.
Timeout ou 503 levam o cliente ao próximo destino: failover sem tocar no PBX.
Sem NAPTR e SRV, sobra o A/AAAA na porta 5060 ou 5061, sem prioridade nem peso.
DNS lento, destino sem A, TTL alto e certificado errado derrubam chamadas antes do primeiro INVITE.
Na Parte 5, o assunto é troubleshooting: como ler a resposta do dig e provar em poucos minutos se o problema é ou não é DNS. Para ir além no protocolo, conheça os nossos cursos de SIP e redes.