Um registro DNS curinga é uma má prática?

Pedi ao meu hoster para adicionar três subdomínios, todos apontando para o IP do registro A. Parece que ele simplesmente adicionou um registro DNS curinga porque qualquer subdomínio aleatório resolve agora o meu IP. Isso é bom para mim do ponto de vista técnico, pois não há subdomínios apontando para nenhum outro lugar. Então, novamente, eu não gosto que ele não faça o que eu pedi. E então eu me pergunto se há outras razões para dizer a ele para mudar isso. Há alguns?

O único aspecto negativo que encontrei é que alguém poderia criar um link para o meu site usando http://i.dont.like.your.website.mywebsite.tld.

Se você colocar um computador nesse domínio, obterá falhas estranhas de DNS. Quando você tenta visitar algum site aleatório na Internet, chega ao seu.

Considere: Você é o proprietário do domínio example.com. Você configura sua estação de trabalho e nomeia-a. ... digamos yukon.example.com. Agora você notará na sua /etc/resolv.conflinha:

search example.com

Isso é conveniente porque significa que você pode pesquisar por nome de host, por exemplo, o wwwque procurará www.example.comautomaticamente por você. Mas tem um lado sombrio: se você visitar, digamos, o Google, ele procurará www.google.com.example.com, e se você tiver DNS curinga, isso será resolvido para o seu site e, em vez de chegar ao Google, você terminará em seu próprio site.

Isso se aplica igualmente ao servidor no qual você está executando seu site! Se alguma vez precisar chamar serviços externos, as pesquisas de nome de host poderão falhar da mesma maneira. Então, api.twitter.compor exemplo, de repente api.twitter.com.example.com, torna-se , direciona diretamente para o seu site e, é claro, falha.

É por isso que nunca uso DNS curinga.

Um registro DNS curinga é uma má prática?

Pessoalmente, eu não gosto disso. Especialmente quando existem máquinas nesse domínio. Os erros de digitação não são verificados, os erros são menos óbvios ... mas não há nada de fundamentalmente errado com isso.

O único aspecto negativo que achei foi que alguém poderia criar um link para o meu site usando http: //i.dont.like.your.website.mywebsite.tld .

Faça com que o servidor http redirecione todas essas solicitações para os endereços canônicos apropriados ou não responda. Para o nginx, seria algo como :

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

e depois o regular

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }

É tudo uma questão de opinião. Para mim, não é uma prática ruim.

Estou criando um aplicativo multilocatário que usa um banco de dados por inquilino. Em seguida, ele seleciona o banco de dados a ser usado com base no subdomínio.

Por exemplo milkman.example.com, usará o tenant_milkmanbanco de dados.

Assim eu separei tabelas para cada inquilino, como, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, que na minha opinião é um enorme muito mais fácil de manter para este aplicativo específico, em vez de ter todos os usuários de todas as empresas na mesma tabela.

[edit - Michael Hampton has a good point]

Dito isto, se você não tiver um motivo específico para aceitar qualquer subdomínio (variável), como eu, não deverá aceitá-los.

Outra questão aqui é o SEO: se todos *.example.commostrarem o mesmo conteúdo, seu site será mal referenciado, pelo menos pelo Google ( https://support.google.com/webmasters/answer/66359 ).

Essa é realmente uma péssima idéia, suponha que se você deseja hospedar um subdomínio a.company.com em um servidor da Web e b.company.com em outro servidor da Web, pode ser outro ISP. O que você vai fazer ?. Portanto, o DNS curinga não é uma opção, deve ser preciso, criar um registro para cada subdomínio e apontar para o IP relevante. Existem chances de mover o servidor da Web de um ISP para outro ISP; nesse caso, o que você fará?

Sei que essa é uma pergunta antiga, mas gostaria de compartilhar um exemplo do mundo real de onde o uso de domínios curinga pode causar problemas. No entanto, vou alterar o nome do domínio e também ocultar o registro completo do SPF para economizar vergonha.

Eu estava ajudando alguém que estava tendo problemas com o DMARC. Como parte das verificações, eu sempre procuro o registro do DMARC com o DIG.

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

Eu também obtive o mesmo resultado ao procurar o registro DKIM.

Consequentemente, os emails enviados deste domínio sofrerão uma falha no DKIM, pois o módulo DKIM tentará analisar o registro SPF de uma chave DKIM e falhará e também obterá um Permerror para DMARC pelo mesmo motivo.

Os domínios curinga podem parecer uma boa ideia, mas configurados incorretamente, podem causar todos os tipos de problemas.

Um registro DNS curinga é uma má prática?

Não, e ao contrário de outros, acredito que seja uma boa prática.

A maioria dos usuários da Internet digita um nome DNS em algum momento. Eles digitarão ww.mycompany.comou o wwe.mycompany.com que você prefere que aconteça, "oops, não conseguimos encontrar esse site" ou para que eles acessem sua página inicial principal? É mais frequente fazê-los acessar sua página inicial principal. É o que MUITAS pessoas fazem.

Mesmo se alguém colocar um link para i.dont.like.your.website.whatever.comele, você ainda acessará sua página inicial, que é realmente o que você deseja. Afinal, eles não podem fazer com que o i.dont....site vá para o servidor deles, você ainda controla o roteamento de DNS para que ele vá para o seu.

Acho que o melhor motivo para não ter um registro DNS curinga em primeiro lugar é evitar dar o endereço IP do servidor a um invasor em potencial e reduzir a exposição a ataques DDOS. Isso também é recomendado pela Cloudflare: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/