Resumo

  • Um curinga DNS não faz busca por padrão. Ele é um RRset em um proprietário iniciado pelo rótulo *, considerado apenas quando a correspondência exata sai da árvore autoritativa.
  • O RFC 4592 manda localizar o ancestral existente mais próximo e testar somente *.<ancestral>; não existe procura por outro curinga caso esse candidato falhe.
  • DNSSEC autentica os dados e a ausência de uma correspondência exata ou mais próxima que teria prioridade, sem garantir segurança ou intenção do destino sintetizado.

A zona respondeu por um proprietário que não guardava

Uma zona pode conter endereço em *.example e nenhum azul.example. Mesmo assim, a consulta pelo segundo nome recebe um registro cujo proprietário visível é azul.example; valor e TTL vêm do curinga. O servidor constrói a forma concreta para a pergunta, sem criar um proprietário permanente na zona.

O RFC 1034 descreveu curingas, em 1987, como instruções de síntese. Um uso inicial era dar destino comum de correio a nomes desconhecidos. A regra não reservava infinitos nomes nem transformava * em expressão regular. Ela autorizava uma ação condicional da autoridade da zona.

Por isso, resposta positiva não equivale a provisionamento individual. DNS comprova que a regra permitia montar aquele RR. Não comprova quem desejou a grafia nem que a aplicação deva confiar no serviço encontrado.

A existência exata recusa o empréstimo

Primeiro o servidor percorre rótulos exatos. Se o nome existe, o curinga não fornece um tipo ausente. Um proprietário com AAAA e sem MX continua sem MX; não toma o MX de *.example.

Existência inclui terminais vazios. Um nome intermediário pode não possuir RRset, mas existe porque há descendente abaixo dele. Esse nó silencioso altera a busca. Criar um registro profundo pode, portanto, interromper resposta curinga usada por outro nome.

Ao remover o último descendente, o terminal vazio pode desaparecer e devolver alcance a um curinga amplo. O RRset com asterisco ficou igual; mudou a estrutura que lhe concedia ou negava atuação.

Um ancestral mais próximo, uma fonte possível

Experiência de implementação e DNSSEC exigiram linguagem precisa. O RFC 4592 definiu closest encloser como o nó existente que compartilha com a consulta a sequência mais longa de rótulos a partir da raiz.

Quando a correspondência cai fora da árvore, forma-se um único candidato logo abaixo: *.<closest-encloser>. Se existir, será a fonte de síntese. Se não existir, a síntese termina.

O servidor não sobe procurando outro asterisco. Se a fonte existe, mas não tem o tipo solicitado, a resposta é ausência de dados sob curinga; um padrão distante não preenche a lacuna. Há, assim, no máximo uma fonte para cada consulta.

Isso torna curingas aninhados determinísticos e derruba a frase “cobre tudo abaixo”. Um nó mais próximo, até vazio, recalcula o candidato. Alcance é resultado da árvore presente e da pergunta, não território permanente do asterisco.

O asterisco continua sendo um rótulo

Somente o primeiro rótulo exatamente igual a * cria um nome curinga. Asterisco em outra posição não tem efeito especial. Incluí-lo literalmente na consulta não pede correspondência de vários nomes; o DNS o trata como rótulo comum e pode alcançar o próprio proprietário curinga.

Depois da síntese, valem as regras normais do tipo. Um CNAME curinga pode ser sintetizado e seguir o processamento usual de alias. Isso não faz do DNS um redirecionador de aplicação, política de certificados ou mecanismo de correspondência parcial.

Delegar encerra o padrão do pai

O RFC 1034 já limitava o padrão à zona. Ao chegar a uma delegação, o pai encaminha o resolvedor à autoridade filha, sem aplicar seu curinga sob o corte. A filha pode publicar outro, mas como decisão própria.

É uma fronteira de controle. Quem entrega a subárvore não mantém uma resposta reserva para todas as ausências nela. Quem recebe a delegação também não herda automaticamente a conveniência configurada no pai.

Provar a ausência que deu passagem

Uma resposta curinga pressupõe que nada mais específico tinha prioridade. O RFC 4035 tornou essa premissa verificável. Em zona assinada, a resposta leva o RRset expandido e sua assinatura, além de prova NSEC autenticada de que não havia correspondência exata ou mais próxima.

A contagem de rótulos em RRSIG permite reconstruir o proprietário curinga assinado, apesar do nome concreto exibido. O validador confirma a origem e o vazio estrutural que autorizou seu uso.

Essa autenticação não atesta segurança, intenção humana ou direito da aplicação de conceder identidade. DNSSEC confirma a declaração da zona e a ordem definida na árvore.

Fontes e limites

O conjunto fechado reúne RFC 1034, RFC 4592 e RFC 4035. Ele define mecanismo, precedência e prova DNSSEC, não uso atual, consultas, abuso, participação de resolvedores ou produtos.