Hospedagem robusta e flexível de registros do DNS A

Question

Atualmente, estou trabalhando em uma plataforma da web que será usada para gerar muitos sites pequenos. Todos os sites estarão hospedados nesta plataforma, seja em uma configuração dedicada ou VPS. Eu não quero fornecer um serviço de hospedagem DNS completo, assumindo a responsabilidade de roteamento de e-mails, etc, eu só quero a responsabilidade pela parte 'site' dos domínios.

A solução óbvia para isso é apontar os registros 'www' A dos domínios para o IP do meu servidor, o que teria o efeito desejado. No entanto, e se meu servidor morrer e eu precisar alternar todos os sites para um backup em um servidor diferente com um IP diferente? Eu preciso entrar em contato com todos os provedores de DNS para todos os domínios diferentes e levá-los a re-apontar seus registros A. Isso não é desejável.

Então ... a questão é, existe uma abordagem sensata para lidar com algo assim, ou é melhor eu apenas morder a bala e oferecer serviços completos de DNS através de um serviço dedicado como Cloudfare ou DYN?

Obrigado por qualquer conselho / solução.

    

Answer 1

Não tenho certeza se descreveria isso como robusto . Isso envolveria vários servidores de back-end, um par de failover de balanceadores de carga no front-end, um site de backup com uma versão não HA do mesmo e o uso de endereços IP que você poderia alternar entre os sites se um desastre suficientemente grande ocorrer .

Mas estipulando que você deseja fornecer hospedagem na web sem tudo isso, sem controlar o DNS de seus clientes, mas mantendo a capacidade de reorientar operações para um segundo site, se necessário, sem entrar em contato com todos os seus clientes para que eles atualizem seu DNS, Uma maneira de fazer isso é com CNAME s. Para esclarecimento, digamos que seu servidor esteja no endereço IP apontado pelo A record server.example.com . Digamos que você tenha dois clientes, cujos nomes de domínio são example.org e example.net .

Cada cliente publica um registro CNAME para seu nome de host www, apontando para seu servidor:

www.example.org.      IN     CNAME     server.example.com.
www.example.net       IN     CNAME     server.example.com.

Se você precisar alterar o endereço IP do seu servidor, altere o registro A para server.example.com , que está sob o seu controle, e após um intervalo adequado para a expiração do cACEhing do DNS, www.example.{org,net} começará a resolver para o novo endereço.

O problema aqui é com domínios nus. Como está bem estabelecido essas partes , você não pode CNAME a raiz de um domínio. Portanto, contanto que os clientes fiquem satisfeitos em ter seu servidor da Web exclusivamente em www.example.org , você está OK. Porém, assim que alguém solicitar um serviço da Web em example.org , você tem um problema.

No entanto, Michael Hampton ressalta que alguns grandes provedores de DNS (ele explicitamente lista Namecheap e GoDaddy, embora isso não deva ser tomado como endosso de nenhum deles) também fornecerão um serviço de redirecionamento da web, onde um registro A no nu O domínio aponta para o servidor da Web do provedor de DNS , cuja única função é receber solicitações de navegador do cliente para http://example.org/foo e redirecioná-las via HTTP 301 -redirecionamento para http://www.example.org/foo , ponto no qual o mecanismo já foi descrito assume e a solicitação é satisfeita pelo seu servidor. Os clientes que insistem em serviço em suas raízes podem ser informados de que precisam obter seu DNS de um provedor que ofereça esse recurso.

Isso ainda não funcionará para clientes que também desejam o serviço HTTPS em suas raízes (por exemplo, https://example.org/bar ); Não conheço nenhuma maneira de ter esse trabalho sem uma infraestrutura significativamente maior. Mas você deve estar bem para atender todos os outros, conforme descrito acima.