Registos DNS wildcard: como funciona *.example.com

Intermédio⏱ 4 min de leituraAtualizado em 13 de outubro de 2026

Um registo chamado *.example.com responde por cada subdomínio que nunca criou: blog, test, qualquer-coisa. Isso torna um subdomínio por cliente ou ambientes de pré-visualização numa só linha. Também faz com que erros de escrita resolvam, convida email para hosts que não existem e pode entregar um subdomínio esquecido a outra pessoa. As regras do que o asterisco abrange são mais rígidas do que a maioria pensa.

Como responde um wildcard

Um resolver pergunta por um nome. Se a zona não o tem, o servidor procura um registo * no nome existente mais próximo e responde como se o registo tivesse sido escrito para o nome perguntado (RFC 4592). Veja esta zona:

; zone example.com
example.com.        3600 IN A      203.0.113.10
www.example.com.    3600 IN CNAME  example.com.
shop.example.com.   3600 IN A      203.0.113.20
*.example.com.      3600 IN A      203.0.113.80

Com *.example.com na zona: um nome existente mantém o seu registo, um nome em falta recebe o wildcard e um nome sob um existente não recebe nada.

Consulta	Resposta	Porquê
`example.com` `A`	`203.0.113.10`	O apex nunca é abrangido por `*.example.com`.
`shop.example.com` `A`	`203.0.113.20`	O nome existe, por isso o wildcard é ignorado.
`blog.example.com` `A`	`203.0.113.80`	O nome não existe: a resposta é feita a partir de `*`.
`a.b.example.com` `A`	`203.0.113.80`	Não existem `b` nem `a.b`, por isso continua abrangido, com qualquer número de etiquetas.
`shop.example.com` `MX`	Sem registos (NODATA)	O nome existe. O wildcard nunca acrescenta tipos que faltem a um nome real.
`x.shop.example.com` `A`	NXDOMAIN	O nome existente mais próximo é `shop`, e não há `*.shop.example.com`.

As regras que apanham as pessoas

Os nomes existentes são intocáveis. Se www só tem um CNAME, uma consulta TXT para www não recebe nada de *, mesmo que o wildcard tenha um registo TXT.
Um nome «existe» mesmo sem registos próprios quando há algo abaixo dele. Crie api.dev.example.com e dev.example.com passa a existir: test.dev.example.com deixa de chegar a *.example.com.
O asterisco só funciona como etiqueta inteira mais à esquerda. *.example.com é um wildcard; www.*.example.com, *-dev.example.com e *abc.example.com são nomes comuns, literais.
Um CNAME wildcard é permitido, mas, como qualquer CNAME, não pode partilhar o nome com outros registos: *.example.com CNAME mais *.example.com MX é inválido.
As respostas levam o nome perguntado, não *. O cliente não distingue uma resposta do wildcard de um registo real; só a comparação com um nome aleatório a denuncia.

Nota: Um certificado TLS wildcard é outra coisa, com outra regra: um certificado para *.example.com cobre blog.example.com, mas não a.b.example.com nem o próprio example.com. Um wildcard DNS resolver nomes profundos não faz o certificado cobri-los.

Quando um wildcard é a ferramenta certa

SaaS com um subdomínio por cliente (acme.app.example): os novos clientes funcionam de imediato e a aplicação escolhe pelo cabeçalho Host que cliente mostrar.
Ambientes de pré-visualização e de branch criados e destruídos automaticamente, todos atrás do mesmo balanceador de carga.
Um redirecionamento geral que envia qualquer subdomínio mal escrito para o site principal — se aceitar os efeitos secundários abaixo.

Os riscos

Os erros de escrita parecem funcionar. ww.example.com ou mial.example.com resolvem e chegam a um servidor que pode mostrar uma página confusa em vez de um erro claro.
Email. Um MX wildcard torna cada subdomínio inventado num destino de email válido, e os spammers reparam; um A wildcard sem nenhum MX faz o mesmo através do recurso ao registo A. Se o wildcard existe só para a web, publique nele um null MX e um SPF rigoroso.
Tomada de subdomínio. Um CNAME wildcard para um serviço na nuvem (*.example.com → example.azurewebsites.net) entrega cada subdomínio por reclamar a quem registar esse destino depois de deixar o serviço.
Erros escondidos. Um registo apagado continua a «funcionar» graças ao wildcard, por isso uma migração falhada pode passar despercebida — até o wildcard ser removido.

; keep a web wildcard from inviting mail to every subdomain
*.example.com.  3600 IN MX   0 .              ; RFC 7505 "null MX"
*.example.com.  3600 IN TXT  "v=spf1 -all"

Atenção: Antes de acrescentar um wildcard a um domínio que envia email ou serve para iniciar sessão, anote os subdomínios que não podem resolver e teste-os depois da alteração.

Como verificar se um domínio tem wildcard

Pergunte por um nome que ninguém criaria. Se resolver, há um wildcard (ou uma CDN ou fornecedor de DNS que sintetiza respostas). Depois compare com um subdomínio real:

# a label that surely does not exist — answered by the wildcard?
dig +short pixdns-test-7f3a.example.com A
# compare with a name that does exist
dig +short shop.example.com A

Dica: Cole o nome aleatório na consulta DNS do PixDNS para ver o tipo de registo e o TTL que o wildcard devolve. As ferramentas de enumeração de subdomínios filtram as respostas do wildcard da mesma forma: primeiro resolvem uma etiqueta aleatória e descartam tudo o que lhe corresponda.

Consultar um subdomínio aleatório →A seguir: registos CNAME →

Perguntas frequentes

*.example.com cobre example.com?

Não. O wildcard abrange nomes abaixo do domínio, nunca o próprio domínio. Mantenha um registo separado para o apex.

*.example.com cobre a.b.example.com?

No DNS, sim — desde que b.example.com não exista. Um certificado TLS wildcard, pelo contrário, só cobre um nível.

Porque não funciona o meu wildcard para um subdomínio?

Porque esse nome, ou um nome abaixo dele, existe na zona. Um nome existente nunca recebe respostas do wildcard, nem para tipos que não tem.

Posso usar um wildcard para MX ou TXT?

Sim, qualquer tipo de registo pode ser wildcard. Um MX wildcard raramente é boa ideia; um null MX wildcard e v=spf1 -all são uma proteção comum.

Experimente no seu domínio

Veja a teoria na prática — execute Consulta DNS para o seu próprio domínio.

Atualizado em 13 de outubro de 2026

Fontes