Resumo

  • A regra FCFS da RFC 9665 protege um nome com a primeira chave SIG(0) aceita; ela não comprova identidade empresarial nem concede direito sobre todo o namespace.
  • A implantação segura começa pela escolha de uma zona dedicada e só termina depois de verificar publicação autoritativa, resolução, autenticação do endpoint e transação de aplicação.

Imagine que o SRP tenha sido ativado diretamente em example.com. Um equipamento automático registra mail antes de qualquer bloqueio. A atualização é bem formada, a chave é nova, a assinatura confere e o nome está livre. Pela lógica FCFS, a reivindicação é consistente.

Pela lógica da organização, ela é inadmissível. O problema não está na criptografia: está na superfície de autoridade entregue ao primeiro dispositivo que chegou.

RFC 9665 recomenda não oferecer SRP na zona de nível organizacional. Uma subzona de descoberta — por exemplo, dnssd.example.com — contém o efeito do primeiro a chegar. Uma lista de nomes proibidos protege rótulos operacionais ou ofensivos. O nome da zona de descoberta não precisa parecer importante; quanto menos ele se confundir com a identidade pública da empresa, melhor.

O que a primeira chave realmente possui

SRP foi desenhado para registros automáticos sem segredo compartilhado previamente com cada dispositivo. O requester gera um par de chaves exclusivo, inclui a KEY no DNS Update e assina com SIG(0). Se host e instância de serviço ainda não pertencem a outra chave ativa, o registrador aceita a reivindicação. Atualizações futuras devem demonstrar a mesma chave privada.

Essa continuidade prova posse criptográfica, não identidade institucional. Ela não informa se o dispositivo pertence à empresa, se o usuário tinha autorização, se o firmware é confiável, se o serviço é o esperado ou se o nome escolhido respeita o inventário corporativo.

A chave deve permanecer em armazenamento estável. Uma restauração de fábrica ou transferência de propriedade pode apagá-la, mas a nova chave não recebe o nome antigo automaticamente. Enquanto o KEY-LEASE anterior estiver ativo, haverá conflito; o equipamento escolhe outro nome ou espera. Portanto, redefinir credenciais também redefine a estratégia de nomes.

Um único pacote reduz conversa, não reduz as camadas

Uma atualização SRP contém exatamente uma descrição de host e pode agregar descrições e anúncios de vários serviços. Em vez de enviar precondições explícitas de RFC 2136, o requester se submete às regras implícitas do registrador: grafo de registros coerente, mesma chave, SIG(0) válida, Update Lease presente e nenhum dono conflitante. A operação é atômica.

Aceitação atômica não é publicação. O registrador pode ser um hidden primary. Outros servidores assinam e respondem às consultas. Entre NoError e a tela do usuário há journal, replicação, servidores secundários, caches e filtros de endereço. O recibo precisa consultar quem realmente serve a zona.

Mesmo a resposta DNS correta é apenas convite para testar. SRV informa alvo e porta; TXT fornece metadados; A e AAAA dão endereços. O cliente ainda precisa autenticar o endpoint conforme o protocolo e concluir uma operação de aplicação. Uma chave SRP não assina a saúde do processo.

Dois leases e um TTL

Os registros que anunciam o serviço costumam ter LEASE em torno de duas horas. A KEY pode conservar o nome por cerca de catorze dias. Assim, o serviço de um aparelho desligado desaparece, mas seu nome não fica imediatamente livre para outro equipamento.

O estado “nome reservado, serviço ausente” é deliberado. Painéis devem mostrar os dois prazos e a impressão digital da chave. O TTL é um terceiro relógio: depois que o lease expira, o autoritativo para de responder com o RR, mas uma cópia já armazenada por um resolver pode sobreviver até o fim do TTL restante.

Quem pode chegar ao registrador

As atualizações SRP não têm autorização organizacional além do FCFS. O registrador deve rejeitar fontes de fora do domínio administrativo. Em TCP, o handshake ajuda contra falsificação fora de caminho, desde que payload de TCP Fast Open não seja aceito sem validação equivalente. Em UDP para redes restritas, filtros de origem e de interface são parte da decisão.

DNS-over-TLS resolve apenas parte do caminho. Registradores precisam oferecê-lo e requesters capazes devem usá-lo, mas a RFC não define um método automático de autenticar a chave do servidor. Sem validação, é privacidade oportunista, não identidade comprovada do registrador.

Outro risco aparece quando SRP divide a zona com DNS Update tradicional. Uma credencial diferente pode sobrescrever registros que o registrador prometeu à chave FCFS. Os dois caminhos devem operar sobre objetos separados ou ter precedência e auditoria explícitas.

O nome local não é selo global

Dispositivos restritos usam default.service.arpa. e recebem do ambiente a lista de registradores. O registrador pode reescrever o nome para um escopo maior. Essa tradução muda quem consegue ver o serviço e deve ser tratada como política.

service.arpa. é servido localmente. Um host que usa resolver externo pode não obter a visão correta. Aplicações não devem tratá-lo como nome globalmente autenticado nem como base para certificado PKI. A autenticação da aplicação continua separada. Também convém avaliar se expor a KEY cria um identificador durável para rastreamento.

Recibo operacional

Registrar ingresso na rede, interface de origem, domínio de registro, método de descoberta do registrador, transporte e validação TLS. Guardar bytes da atualização, relações entre host e serviços, fingerprint da KEY, algoritmo, verificação SIG(0), conflito, leases pedidos e concedidos e resposta.

Depois, unir journal do primário, publicação por cada autoridade, visão recursiva e TTL a uma conexão com o endpoint e uma transação inofensiva. O mesmo identificador liga as etapas; nenhuma substitui a outra.

Fontes