subdomínios, A NAME, segurança e roteamento

Question

NOTA: Eu sou consultor de estratégia de marketing e não consultor de tecnologia, então:

Tenho um cliente para quem estamos usando a solução de hospedagem em nuvem de terceiros para criar sites pequenos (de página única) para seus clientes. No setor de clientes finais, será muito difícil para todos os clientes obter seu próprio nome MyWebSite.com, que é um fator pelo qual meu cliente deseja usar subdomínios para esses sites: XYZ.MyClient.com. Os clientes finais estão bem com esta solução do que vimos.

A empresa de hospedagem de nuvem de terceiros que estamos usando diz que devemos usar apenas um caractere curinga A NAME (por exemplo, * .MyClient.com), e isso encaminhará todo o tráfego de subdomínios por meio de sua plataforma e para o site correto sem afetar o domínio principal em tudo (www.MyClient.com).

A empresa terceirizada de TI do meu cliente afirma que não, essa solução curinga de fato encaminhará todo o tráfego do www.MyClient.com para a empresa de hospedagem antes de chegar ao site certo. Eles afirmam que a melhor solução é criar um registro A NAME para cada subdomínio e gerenciar aqueles que estão avançando para centenas de sites.

Eu só preciso de respostas para facilitar a discussão entre todas as partes - eu realmente não me importo com a resposta. Eu só quero que meu cliente tenha uma solução segura, gerenciável e econômica. Minhas perguntas então são:

1. O uso de uma abordagem de caractere curinga A NAME, de fato, roteará o núcleo www.MyClient.com por meio da empresa de hospedagem de terceiros?
   2. Se sim, por que isso é um problema? Demora? Segurança? Outro?
   3. Eu li em outro lugar (tho era um post de 5 anos de idade) que seria bom ter um certificado de segurança separado para a configuração do subdomínio. É assim mesmo? Se assim for, alguém pode me indicar uma boa referência sobre isso?
   4. Gerenciar centenas de registros A NAME para subdomínios me parece criar muito trabalho que se presta a erros e retrabalho. É verdade ou não?
   5. Estou sentindo falta de algo?

Obrigado

    

Answer 1

Will using an A NAME wildcard approach in fact route the core www.MyClient.com through the 3rd party hosting firm?

Não. Os nomes específicos existentes sempre têm prioridade sobre as correspondências com curingas. (Consulte "Regras de existência" na RFC 4592 anterior vinculada).

If so, why is that a problem? Delay? Security? Other?

Atraso e impondo um pouco do requisito de largura de banda para o provedor terceirizado, já que ele precisa retransmitir todo o tráfego para seu servidor da Web real. (Estou disposto a apostar que eles simplesmente não farão isso.)

E, claro, o provedor terceirizado obtém controle total sobre o conteúdo do site principal. Isso é indesejável mesmo que você já confie neles com as páginas da Web de seus clientes.

I have read elsewhere (tho it was a 5 year old post) that it would be good to have a separate security certificate for the sub-domain setup.

Eu não sei muito sobre isso, mas basicamente você tem três opções:

• Emita um novo certificado para cada subdomínio. Bastante possível hoje em dia com o Let's Encrypt, e o provedor terceirizado pode fazer isso sozinho.
• Emita alguns certificados com cada um válido para algumas dezenas de subdomínios de uma só vez. Isso costumava ser feito no passado (antes de LE), mas é provavelmente o mais difícil de manter em comparação.
• Emita um certificado curinga para *.myclient.com . Embora seja mais fácil de gerenciar, custa mais e, teoricamente, torna mais fácil para o host de terceiros personificar de alguma forma o subdomínio www . (É um argumento um pouco esticado, porém, os mesmos problemas existem com o LE.)

Managing hundreds of A NAME records for subdomains strikes me as creating a lot of work that will lend itself to errors and rework. True, or not?

O maior problema que posso ver com os registros A / AAAA diretos é que seria bastante irritante atualizar todos eles se o endereço IP do servidor fosse alterado. Ter todos esses subdomínios como CNAME s (aliases) facilitaria as coisas, já que apenas um único domínio (o destino CNAME) precisaria ser atualizado.

Mas a quantidade de subdomínios, em geral, não parece um problema - desde que sua criação e exclusão sejam claramente definidas como parte do procedimento de configuração de um novo cliente. (Isto é, se o seu sistema não puder automatizar completamente ao abrir uma nova página da Web do cliente ...)

Ainda assim, um curinga seria ainda mais fácil.