De acordo com os RFC 1035 , os registros CNAME não podem ser usados em um apex de zona porque um registro CNAME não pode existir ao lado registros como SOA.
Com frequência, isso é motivo de frustração para quem tenta projetar aplicativos SaaS para oferecer suporte a domínios personalizados e, ao mesmo tempo, estar altamente disponível e escalonável.
As opções são basicamente:
- Live com um conjunto fixo de endereços IP
- Usuários de insista usam seus servidores DNS para que você possa atualizar os registros
- Insista em que todos usem www. com um CNAME e permitir que os usuários descubram como redirecionar seu domínio nu
Após o levantamento de vários produtos SaaS grandes, parece que a maioria suporta a opção 1, embora essa pareça ser a opção mais difícil ao prever um crescimento rápido e alcançar alta disponibilidade.
Por exemplo:
-
GitHub : Dois IPs para registros A
-
SquareSpace : quatro IPs para registros A , embora eu pense que até recentemente este era apenas um
-
BigCommerce : recomendado para usar o DNS, mas cada loja tem um IP especificado sujeito a alteração
-
Shopify : Um único IP para registros A
-
WordPress.com : deve usar o DNS
Geralmente, ter um conjunto fixo de IPs apresenta os seguintes desafios:
- Você não pode remover facilmente um endereço IP quando um dos seus balanceadores de carga falha
- Você não pode adicionar IPs à medida que a demanda cresce e você precisa distribuir seu tráfego entre mais balanceadores de carga
- Você não pode fazer failover para uma infraestrutura geograficamente isolada com um conjunto totalmente diferente de IPs
Minha pergunta é, especificamente, como os provedores que oferecem um conjunto fixo de registros A superam essas limitações ? Especialmente aqueles que oferecem apenas um registro A?
Eles:
- Tenha um balanceador de carga por IP fornecido, espere que eles nunca excedam a capacidade dos maiores servidores que eles podem executar nessa função e, no caso de um failover, apenas mova o IP para um servidor diferente?
- Balanceadores de carga de hardware do usuário, presumivelmente mais confiáveis e com capacidade suficiente para que seja improvável que seja um gargalo?
- Use algo como IP anycast, onde um número arbitrário de balanceadores de carga pode receber pacotes para um determinado IP?
- Uma mistura dos itens acima?
Eu estou supondo que aqueles rodando em nuvens públicas (por exemplo, AWS, Azure, etc) seriam os primeiros, e aqueles que têm sua própria infra-estrutura seriam principalmente os segundos?