Melhor estratégia CNAME TTL para troca de fallover

Question

Recentemente, tenho pensado sobre o TTL do nosso DNS. Temos registros A para nossos servidores e, em seguida, registros CNAME para os nomes dos clientes. O CNAME de www.example.com aponta para o server-01.example.com, por exemplo. No caso de uma falha, temos o TTL definido em 15 minutos no registro CNAME e A.

No entanto, percebo que isso pode não ser o ideal. Certamente deve ser que um registro seja de 48 horas e o CNAME seja de 15 minutos. O CNAME apenas é apontado para server-02.example.com no caso de uma falha. O registro A (em teoria, deve ser armazenado em cache por muito tempo, porque usamos o CNAME como o alternador).

Olhando pela Internet, encontrei muitas pessoas com o CNAME longo e o registro A curto: CNAME e um registro têm diferentes TTLs. Qual deles será armazenado em cache?

Isso parece contrário ao que qualquer um iria querer. A questão é: o DNS funciona da maneira que espero que funcione, em que o TTL de solicitação CNAME é o mais importante para se eu precisasse trocar os servidores com pressa?

    

Answer 1

Supondo que o registro A apex para example.com. estava apontando para um endereço IP quebrado, a maioria das empresas que conheço mudaria o registro A e ignoraria a www totalmente:

• A maioria dos administradores prefere não ter o site quebrado para os usuários que digitarem o nome do site sem o prefixo www.
• Isso vale em dobro para os administradores que não confiam em seus desenvolvedores de aplicativos da web para usar de forma consistente www.example.com over example.com . (dica: a maioria de nós não)

Passando para o seu vinculado exemplo , você está comparando maçãs e laranjas. Os registros de DNS da Apex em cenários de hospedagem na web são uma dor enorme devido ao conhecido problema CNAME do apex . Existem apenas duas escolhas corretas nessa circunstância: ou o ápice Um registro é alterado conforme necessário para apontá-lo em um IP válido, ou você renuncia a ter um registro de apex inteiramente. Qualquer coisa entre os dois é meio cozido e inconsistente.

Tudo isso está um pouco além do ponto: se você está confiando em alterações de registro manuais para lidar com alta disponibilidade para seu serviço, você está fazendo algo errado . O endereço IP que o navegador da web acessa deve ser um balanceador de carga, um endereço anycast, um CDN ou um provedor de webhosting que possa fornecer essa alta disponibilidade, se seus próprios farms de servidores não puderem. Vários registros de endereço também podem funcionar se você tiver certeza de que os principais aplicativos que os consomem seguem as diretrizes RFC 6724 (ou seja, os mais populares navegadores da web), mas muitos aplicativos são preguiçosos e simplesmente usam o primeiro registro de endereço retornado.

Para o propósito do argumento, vamos examinar Cadeia CNAME do Google por seus próprios méritos, sem colocá-lo no contexto de seu problema original. Isso parecerá familiar, já que é o texto da minha resposta original:

O tipo de registro é irrelevante aqui. Se o registro precisar ser alterado com frequência, ele deverá ter um TTL muito baixo. Se não precisar ser alterado com frequência, é lógico que ele não precisa de um TTL baixo e você pode usar qualquer coisa com que se sinta à vontade.

Ninguém (além do Google) pode realmente comentar por que o Google quer que ghs.l.google.com IN A tenha um TTL menor do que os registros CNAME apontando para ele. Você não pode tirar nenhuma conclusão sem entender seu design maior, e o design é o que dita suas partes móveis.

    

Answer 2

Eu concordo.

Desde que os "servidores reais" tenham endereços IP estáveis, os registros A devem ter TTLs longos. Mantenha o TTL nos registros CNAME baixos para permitir a troca rápida para outro servidor real em caso de falha ou o que for.