O que é um registro DNS curinga (wildcard)? Usos e riscos

Um registro DNS curinga usa um rótulo com asterisco para fornecer respostas a nomes que não têm um registro mais específico em uma zona. Ele pode ser útil quando uma aplicação aceita muitos subdomínios de clientes (tenants) ou quando um serviço trata intencionalmente um conjunto amplo de nomes de host. Um curinga não é uma regra universal que substitui todos os registros explícitos, e seu comportamento depende da existência do nome no DNS e do tipo de registro solicitado. Ele também pode causar resultados surpreendentes ao fazer com que subdomínios digitados errado ou não intencionais resolvam para algum lugar em vez de falhar de forma clara. Use-o apenas quando a aplicação e o modelo de segurança forem projetados para essa abrangência.

Como funciona a correspondência de curingas

Um rótulo curinga é escrito como um asterisco em determinado nível de nome, geralmente *.example.com. Ele pode fornecer dados para certos nomes abaixo desse ponto quando não existem dados correspondentes mais próximos. Isso não significa que todo descendente, em qualquer profundidade, seja criado automaticamente do modo que um curinga de sistema de arquivos poderia sugerir. Nomes existentes, delegações e nós intermediários vazios afetam o resultado. O tipo de registro também importa: um registro A curinga não cria automaticamente todos os registros MX, TXT ou AAAA possíveis para cada subdomínio. Teste os nomes e os tipos de registro que sua aplicação espera, em vez de presumir que um curinga cobre todo o comportamento do DNS.

Um caso de uso comum é a hospedagem multi-tenant, em que cada cliente recebe um subdomínio e todos esses nomes são roteados para a mesma borda da aplicação. A aplicação então inspeciona o nome de host e determina qual cliente ou site deve ser servido. O DNS apenas leva a requisição até um endpoint; ele não valida se o cliente solicitado existe nem se quem fez a requisição pode acessá-lo. A aplicação deve aplicar suas próprias regras de roteamento e autorização. Se subdomínios desconhecidos caem em um site padrão, garanta que esse padrão não exponha ferramentas administrativas, conteúdo de depuração ou dados de outro cliente.

Considerações operacionais e de segurança

Curingas podem esconder erros de digitação durante os testes, porque um nome digitado errado ainda pode resolver. Eles também podem fazer a automação de certificados solicitar nomes que você não pretendia publicar. Curingas relacionados a e-mail exigem cuidado especial: um registro de endereço curinga não deve ser confundido com uma política de e-mail deliberada, e o comportamento de catch-all pertence ao sistema de e-mail, não sendo criado apenas pelo DNS. Faça um inventário dos nomes explícitos e dos subdomínios delegados antes de introduzir um curinga. Documente quem é o responsável pelo comportamento e o que a aplicação receptora faz com nomes de host inesperados.

• Use registros curinga apenas para nomes que sua aplicação está preparada para tratar.
• Mantenha registros explícitos para serviços que precisam de roteamento ou política distintos.
• Teste subdomínios desconhecidos e malformados, não apenas os nomes de clientes esperados.
• Não trate o DNS curinga como controle de acesso ou autorização de clientes.
• Revise as implicações para certificados, e-mail e monitoramento antes da implantação.

Diagnosticando uma resposta curinga

Quando um subdomínio inesperado resolve, inspecione a zona em busca de um curinga no nível relevante e verifique se existe um registro mais específico ou uma delegação. Consulte o nome e o tipo de registro exatos e compare com o destino do curinga. Se um curinga parece não se aplicar, examine se um nó existente altera a síntese do curinga para aquele ramo da árvore DNS. As interfaces dos provedores podem abstrair esses detalhes, então confirme como o serviço implementa registros curinga. Depois de remover ou alterar um curinga, aguarde a expiração dos caches e teste tanto os nomes antes esperados quanto os nomes que agora devem falhar.

Curingas são uma ferramenta específica, não um atalho para evitar o inventário de nomes de host. Funcionam melhor quando um produto serve intencionalmente um espaço de nomes variável e a aplicação faz um roteamento de host seguro e explícito. Para contexto básico, veja tipos de registro DNS explicados e o que um CNAME faz. Uma consulta DNS pública pode confirmar o que um resolvedor retorna para um nome escolhido, enquanto os testes da aplicação confirmam que o endpoint trata esse nome corretamente.

Teste nomes esperados e inesperados

Uma implantação de curinga deve ser testada com mais de um nome de cliente sabidamente correto. Verifique um nome que deve ser tratado, um nome que deve ter uma sobreposição explícita e um nome aleatório que não deveria existir. Depois, inspecione tanto as respostas DNS quanto a resposta da aplicação. Um curinga pode rotear um rótulo desconhecido para o serviço, mas a aplicação deve retornar uma resposta segura de não encontrado, em vez de criar uma conta padrão acidental ou vazar configurações. Repita os testes depois de adicionar registros explícitos e delegações, pois a estrutura da árvore DNS pode mudar quais dados de curinga se aplicam. Documente o padrão de nome pretendido para que os futuros operadores saibam se um subdomínio que passou a resolver é esperado ou uma surpresa de configuração.