Resumo

  • ENUM transforma um número E.164 em uma chave DNS e processa regras NAPTR até obter um URI; o resultado é um contato possível, não uma sessão de comunicação concluída.
  • Um registro confiável une, sem confundir, a validação do direito sobre o número, o estado DNSSEC, o NAPTR escolhido, o URI, a autenticação do par, a sinalização e a mídia bidirecional observada.

Um painel recebe um número E.164 e exibe sucesso. O sistema retirou a pontuação, inverteu os dígitos para construir um nome em e164.arpa, recebeu um RRSet NAPTR com DNSSEC válido e gerou um URI SIP. Depois disso, o destino ainda pode estar desatualizado, o provedor pode recusar o convite, o terminal pode nunca tocar ou a sinalização pode terminar sem áudio nos dois sentidos.

A resposta ENUM não precisa estar errada. Errado é chamar de “conectado” um estado que só comprovou “resolvido”.

Patrik Fältström e Michael Mealling assinaram a RFC 3761, publicada em 2004 na trilha de padrões. Em 2011, a RFC 6116, de Scott Bradner, Lawrence Conroy e Kazunori Fujiwara, tornou-a obsoleta. O documento novo declara atualizar o texto editado por Fältström e Mealling. ENUM é um trabalho coletivo e revisado; não é propriedade nem decisão operacional de uma pessoa.

A contribuição arquitetônica é precisa: uma aplicação pode partir de um telefone e descobrir um URI com DNS. Isso não transforma DNS em central telefônica, autoridade de numeração ou testemunha de conversa.

A chave está certa; o titular ainda precisa de prova

A RFC 6116 define primeiro a Application Unique String. O número E.164 perde espaços, parênteses e hífens, preservando o sinal de mais inicial. A primeira regra conhecida remove esse sinal, inverte os dígitos, insere pontos e acrescenta .e164.arpa.. Surge uma chave exata para o banco de regras ENUM.

Essa transformação demonstra como o cliente perguntou. Não autentica quem iniciou a consulta nem mostra quem conserva o direito de usar o número. Portabilidade recente, atraso de revalidação e origem não autorizada do dado pertencem a outros sistemas. Sintaxe correta não cria procedência institucional.

A chave solicita registros NAPTR. Uma regra terminal pode produzir a saída; uma regra não terminal cria outro nome e outra consulta. A última volta do DDDS entrega um URI absoluto. O limite de ENUM é uma expressão de endereço, não um evento no estado da chamada.

A RFC 3403 separa os campos. ORDER define a ordem principal; PREFERENCE organiza candidatos elegíveis no mesmo nível; FLAGS, SERVICES, REGEXP e REPLACEMENT controlam interpretação e reescrita. Conservar apenas o URI apaga o motivo da escolha.

Uma regra retornada ainda deixa escolhas

“O algoritmo ENUM sempre retorna uma única regra” descreve a saída do algoritmo, não o resultado da telefonia. Uma aplicação pode aceitar alguns Enumservices e não outros, descartar registros privados ou inválidos, apresentar vários URLs ao usuário e aplicar conhecimento local antes de agir.

O cliente ordena o RRSet por ORDER e PREFERENCE. Em caso de empate, a sequência de chegada no pacote DNS não representa preferência estável. Dois resolvedores podem devolver o mesmo conjunto em ordens diferentes sem adulteração.

A preferência do registrante também não é comando. A RFC recomenda publicar somente contatos que se pretende sustentar, pois até o item menos preferido pode ser escolhido por um usuário. Isso não garante disponibilidade naquele instante, suporte do esquema pelo cliente nem admissão pelo próximo provedor.

O registro operacional precisa do RRSet inteiro, TTL, ordem, preferência, serviço, flags, regra de reescrita e capacidades do cliente. Também explica por que cada candidato foi aceito, ignorado ou rejeitado. Um URI sem esse denominador não permite saber se houve política correta, empate, cache antigo ou falta de alternativa compatível.

O direito sobre o número é validado antes

Um domínio ENUM acompanha uma atribuição E.164. A RFC 4725 distingue quem atribui o número, o assignee que tem direito de uso, o registrante ENUM, a entidade de validação, registro, registrador, operador DNS e provedor de aplicação.

A entidade de validação verifica se o registrante é o assignee ou está autorizado a agir por ele. A validação inicial não cobre toda a vida da delegação: mudanças de atribuição ou direito exigem revalidação, e a delegação deve ser revogada quando as condições deixam de existir.

Essa prova não está embutida em toda resposta NAPTR. Um resolvedor pode autenticar o dado publicado e não conhecer a portabilidade mais recente, o método de validação ou a decisão local de autorização. “O nome existe” e “o registrante controla o número agora” são afirmações diferentes.

Um registro antigo tampouco prova fraude. TTL ainda válido, relógios de atualização distintos e atraso de revogação podem explicar o intervalo. A investigação junta versão da atribuição, horário e método de validação, validade, mudança de delegação e os dados efetivamente vistos pelo cliente.

DNSSEC autentica dados, não o serviço final

A RFC 6116 recomenda DNSSEC para autenticar dados DNS e reduzir ataques. Ao mesmo tempo, diz que um endereço obtido em consulta ENUM validada não garante que a entidade naquele endereço seja o par pretendido.

O serviço deve autenticar esse par durante sua própria fase de estabelecimento. Endereço ou identidade descobertos fora do serviço não substituem a verificação. DNSSEC responde se o dado pertence à cadeia assinada, não quem atenderá no protocolo seguinte.

O cache amplia a distância. No exemplo SIP da RFC, o URI ENUM provoca outras consultas NAPTR, depois SRV e endereço de host; só então o agente tenta iniciar a sessão. Zonas e TTLs mudam em ritmos diferentes. Registros autênticos podem formar uma rota temporariamente incoerente.

Guarde a validação DNSSEC, vigência da assinatura, resolvedor, idade do cache, respostas negativas e toda a resolução posterior. Em seguida, vincule a tentativa de sinalização ao par realmente autenticado.

O URI de voz abre outro protocolo

A RFC 4415 registrou o Enumservice voice:tel. O tel: URI gerado pode ser usado para iniciar uma chamada de voz interativa. Um discador usa o número em conexão PSTN ou PLMN, diretamente ou por provedor IP e gateway.

“Iniciar” marca o limite. O cliente precisa suportar tipo e subtipo. O provedor pode autenticar, autorizar, rotear, aceitar ou recusar. O terminal distante pode tocar, redirecionar, expirar ou responder. A mídia ainda precisa negociar e percorrer seu próprio caminho.

Quando a saída é SIP, a RFC 3261 assume o controle. SIP é outro protocolo para localizar participantes e criar, alterar e encerrar sessões. Tem autenticação, autorização, convites, respostas provisórias e finais, confirmações e estado de diálogo. ENUM fornece o URI de entrada; não executa previamente essa máquina de estados.

Nem “SIP aceito” prova conversa. Áudio bidirecional, presença humana, duração útil e cobrança coerente dependem de observações de mídia e aplicação, com limites de privacidade.

O comprovante completo tem sequência

A primeira parte conserva o número original, normalização, chave DNS, resolvedor, horário, DNSSEC, RRSet, TTLs e cada reescrita não terminal. Depois vêm Enumservices suportados, candidatos, justificativa de seleção e URI final.

A segunda parte começa fora de ENUM: resolução posterior, par autenticado, autorização do provedor, pedido de sinalização, identificador da transação, respostas, confirmação e causa de encerramento. Somente depois se observam endpoints de mídia, pacotes nos dois sentidos e janela de uso.

Cada etapa pode ter sucesso antes de a próxima falhar. Essa separação distingue delegação vencida de cache antigo, serviço incompatível de host inalcançável, par errado de chamador recusado e sinalização aceita de áudio unilateral.

Fontes