Recentemente, estive pensando no TTL do nosso DNS. Temos registros A para nossos servidores e, em seguida, registros CNAME para os nomes voltados para o cliente. O CNAME www.example.com aponta para server-01.example.com, por exemplo. Em caso de falha, temos o TTL definido em 15 minutos no CNAME e no registro A.
No entanto, me ocorre que isso pode não ser o ideal. Certamente deve ser que o registro A seja de 48 horas e o CNAME seja de 15 minutos. O CNAME apenas aponta para server-02.example.com em caso de falha. O registro A (em teoria, deve ser armazenado em cache por um longo tempo, porque usamos o CNAME como o switcher).
Procurando na Internet, encontrei muitas pessoas com CNAME longo e registro A curto: CNAME e registro A têm TTLs diferentes. Qual deles será armazenado em cache?
Isso parece contrário ao que qualquer um gostaria. A questão é: o DNS funciona da maneira que espero que funcione, no sentido de que a solicitação CNAME TTL é importante para se eu precisar trocar de servidor com pressa?
Supondo que o registro A do ápice
example.com.apontasse para um endereço IP corrompido, a maioria das empresas que conheço alteraria o registro A e ignorariawwwtotalmente a alteração:www.example.commais deexample.com. (dica: a maioria de nós não)Passando para o exemplo vinculado , você está comparando maçãs e laranjas. Os registros Apex DNS em cenários de hospedagem na web são uma dor enorme devido ao conhecido problema apex CNAME . Existem apenas duas escolhas corretas nesta circunstância: ou o registro apex A é alterado conforme necessário para apontá-lo para um IP válido ou você renuncia totalmente a ter um registro apex. Qualquer coisa entre os dois é incompleto e inconsistente.
No entanto, tudo isso não vem ao caso: se você está contando com alterações manuais de registro para lidar com a alta disponibilidade do seu serviço, está fazendo algo errado . O endereço IP que o navegador da web atinge deve ser um balanceador de carga, um endereço anycast, um CDN ou um provedor de hospedagem na web 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 aplicativos principais que os consomem seguem as diretrizes RFC 6724 (ou seja, os navegadores da Web mais populares), mas muitos aplicativos são preguiçosos e simplesmente usam o primeiro registro de endereço retornado.
Para fins de argumentação, vamos examinar a cadeia CNAME do Google por seus próprios méritos, sem colocá-la no contexto de seu problema original. Isso parecerá familiar, pois é 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 trocado com frequência, é lógico que não precisa de um TTL baixo e você pode usar o que quiser.
Ninguém (além do Google) pode realmente comentar sobre por que o Google deseja
ghs.l.google.com IN Ater 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 determina suas partes móveis.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 baixo para permitir a troca rápida para outro servidor real em caso de falha ou qualquer outra coisa.