Informe aos navegadores que eles devem atualizar seu cache DNS?

Question

Temos uma configuração de failover para o nosso servidor da Web, em que espelhamos nosso servidor da Web ao vivo em caso de algum tipo de falha de hardware ou conectividade. No momento, o processo exige que atualizemos o DNS, que obviamente está à mercê de propagação e armazenamento em cache. A propagação atualmente é bem rápida, mas parece que o armazenamento em cache está se tornando mais difícil.

Não nos incomodamos em ir para uma solução de balanceamento de carga mais complicada porque não houve nenhum motivo para fazer uma mudança inesperada de vivo para failover nos quase cinco anos desde que implementamos a configuração. O hardware do servidor live é de alta especificação e robusto, usando RAID para armazenamento, e é co-localizado em um grande datacenter com enormes geradores a diesel e vários canais de internet grandes e pesados. Mesmo a grande queda de energia em todo o estado que tivemos no ano passado não afetou nossos servidores e sites.

Mas usamos o failover para interrupções planejadas, como realizar atualizações do site que ocorrem uma vez a cada seis meses. Fazemos a troca em nosso DNS e, em seguida, temos que esperar o tráfego parar no servidor ativo para não interrompermos demais os nossos usuários durante a atualização.

Portanto, existe uma maneira de o Apache HTTPD (algum tipo de cabeçalho HTTP) informar aos navegadores dos usuários que eles devem liberar o cache DNS de nosso domínio?

    

Answer 1

O problema com a sua pergunta é a suposição falsa de que os navegadores clientes têm algo a ver com a resolução do DNS. Em quase todos os casos, eles não. Eles permitem que o resolvedor de DNS do SO subjacente manipule a resolução de nomes e a mecânica de armazenamento em cache.

Se a sua estratégia de failover estiver vinculada a uma alteração de registro de DNS, sua única opção para uma reviravolta mais rápida do cliente é diminuir o TTL no registro em questão. O TTL é o que determina por quanto tempo um cliente armazena em cache o resultado dessa consulta de registro. Observação: também é possível reduzir o TTL em uma zona DNS inteira. Mas não é provável que você queira ou precise aqui.

A migração para um balanceador de carga mais tradicional contorna seu problema colocando um endereço IP virtual / flutuante na frente do IP do servidor real, para que você não precise fazer nenhuma alteração de DNS e seus failovers podem ser mais ou menos instantâneos.

    

Answer 2

Eu não acredito que pedir às pessoas para limpar o cache do DNS seja prático. A maioria das pessoas comuns não sabe o que é DNS, não sabe o que é um cache e não seria capaz de liberar seu cache de DNS, mesmo se você fornecesse suporte técnico baseado em telefone. Pense em ter que liberar um cache DNS em um roteador - existem centenas de modelos de roteadores. Se seus clientes são todos altamente técnicos, talvez seja um pouco mais prático, mas os consumidores, não.

Acho que você precisa de uma solução técnica que possa controlar.

Provavelmente, é melhor usar um serviço DNS projetado para isso, como o AWS Route 53. O R53 pode ser usado com qualquer servidor, em qualquer lugar, não apenas com servidores / serviços da AWS. O R53 pode funcionar como um balanceador de carga, há vários tipos de roteamento - failover , ponderada, latência, etc. Você pode usar o roteamento de failover para rotear automaticamente para o servidor de backup se o principal ficar inativo.

Outra opção, que tenho certeza que não funcionará, é usar vários registros A. A questão aqui é qual registro os navegadores usarão? Pelo que eu li, minha impressão é que os navegadores devem usar os registros A aleatoriamente, mas eles não usam o primeiro - embora eu não saiba como "primeiro" é definido. Os serviços que distribuem carga usando o DNS tendem a randomizar a ordem dos endereços IP retornados.

Outra opção, mencionada nos comentários, é um proxy reverso. Eu não incluí isso originalmente porque isso significaria mais hardware. Se você colocar um proxy reverso ou um balanceador de carga na frente do servidor / serviço, ele poderá redirecionar o tráfego para onde ele precisar. Minha sugestão acima de usar o Route53 executaria uma função semelhante, não tão bem, mas provavelmente um pouco melhor que o DNS padrão.

Um redirecionamento temporário 302 poderia ser usado, mas você precisaria de um servidor que pudesse enviar consistentemente esses redirecionamentos enquanto o servidor principal estivesse inativo. Isso exigiria hardware adicional, embora não muito hardware.

    

Answer 3

Is there a way for Apache HTTPD (some kind of HTTP header) to tell users' browsers that they should flush their DNS cache.

Nenhum mecanismo desse tipo existe, todos os navegadores da Web modernos e o código executado executam uma caixa de proteção na qual não devem poder alterar as configurações do sistema operacional.

    

Answer 4

O cache DNS local não é gerenciado pelos navegadores dos usuários. É gerenciado no nível do sistema operacional. A alteração do cache DNS local é uma atividade do administrador. Por motivos de segurança, os navegadores não são projetados para executar funções administrativas em sua máquina host.

O que você precisa é de uma solução do lado do servidor. Uma solução comum para esse tipo de problema é usar um proxy reverso , como nginx , ou apache .

Para fazer isso de uma maneira que permita que os servidores principal e de backup tenham tempo de inatividade, você pode executar o proxy reverso em uma máquina virtual que tenha um ou mais endereços IP dedicados. Dessa forma, você (ou seu provedor de nuvem) só precisa manter a VM; o hardware que o suporta pode flutuar.

Sua configuração seria:

• VM voltada para o público: www.seudominio.com.br
• servidor principal de back-end: < endereço IP para main >
• Servidor de backup de back-end: < endereço IP para backup >
• O DNS do seu site aponta para a VM www.yourdomain.com

Se você usar o nginx, os sites públicos a serem intermediados por proxy serão armazenados como definições de arquivo no diretório disponível para sites e ativados pela vinculação sym-os ao diretório habilitado para sites. Você poderia ter uma definição de site por servidor backend e trocá-las alterando o link simbólico ou você poderia ter uma definição de site com uma diretiva proxy_pass para cada máquina de backend, mas com uma dessas diretivas comentadas.

Qualquer que seja a maneira de configurá-lo, para alternar os back-ends, basta alterar o arquivo do site e informar ao nginx para recarregar sua configuração: service nginx reload .

Veja um arquivo de site de exemplo com uma diretiva proxy_pass para cada back-end e um deles comentou:

server {
    listen       80;
    listen       [::]:80;
    server_name  yourdomain.com www.yourdomain.com;

    location / {
            proxy_pass         http://<ip address of main>:80;
            # proxy_pass         http://<ip address of backup>:80;
            proxy_redirect     off;

            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

Você pode fazer muito mais do que isso, incluindo armazenamento em cache de conteúdo estático no proxy reverso, mas isso deve começar.