Fenix por Takeda11
Muitas pessoas ficam confusas sobre como atualizar os registros DNS quando alteram o endereço IP de seus sites. Por que esses registros estão sendo atualizados lentamente? Você realmente precisa esperar dois dias para que tudo seja atualizado? Por que alguns visitantes veem o novo IP, enquanto outros veem o antigo?
A equipe Mail.ru Cloud Solutions traduziu um artigo da desenvolvedora e autora dos artigos Julia Evans, onde ela responde a essas perguntas e geralmente conta o que acontece durante uma atualização de DNS de uma perspectiva de front-end.
Aqui está uma rápida exploração do que acontece nos bastidores quando você atualiza um registro DNS.
Como funciona o DNS: servidores DNS recursivos e autorizados
Primeiro, precisamos explicar um pouco sobre o sistema DNS. Existem dois tipos de servidores DNS: autoritativos e recursivos . Os servidores DNS
autorizados (também conhecidos como servidores de nomes ) mantêm um banco de dados de endereços IP para cada domínio pelo qual são responsáveis. Por exemplo, agora o servidor DNS autorizado para github.com é
ns-421.awsdns-52.com. Você pode pedir a ele o endereço IP github.com com esta solicitação:
dig @ns-421.awsdns-52.com github.com
Os próprios servidores DNS recursivos não sabem nada sobre quem possui cada endereço IP. Eles calculam o endereço IP de um domínio consultando-o nos servidores DNS autorizados e, em seguida, armazenam em cache esse endereço IP caso sejam solicitados novamente. Portanto, 8.8.8.8 é um servidor DNS recursivo.
Quando as pessoas visitam o seu site, provavelmente estão fazendo pesquisas DNS em um servidor DNS recursivo. Então, como funcionam os servidores DNS recursivos? Vamos dar uma olhada!
Como um servidor DNS recursivo consulta o endereço IP de github.com
Vejamos um exemplo do que um servidor DNS recursivo (por exemplo, 8.8.8.8) faz quando você pede o endereço IP (registro A) para github.com. Primeiro, se já tiver um resultado armazenado em cache, ele o emitirá. Mas e se todos os caches expirarem? Aqui está o que está acontecendo.
Etapa 1 : os endereços IP dos servidores DNS raiz são codificados permanentemente em seu código-fonte. Você pode ver isso no código-fonte não acoplado . Digamos que ele selecione 198.41.0.4 para começar. Aqui está a fonte oficial desses endereços IP codificados, também conhecidos como "arquivo de dicas de raiz".
Etapa 2 : pergunte aos servidores de nomes raiz sobre github.com.
Podemos reproduzir aproximadamente o que está acontecendo com o comando
dig... Isso nos dá um novo servidor de nomes autorizado para solicitar: um servidor de nomes para .comcom um endereço IP de 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Os detalhes da resposta DNS são um pouco mais complicados - neste caso, há uma seção de autoridade com alguns registros NS e uma seção adicional com registros A, então você não precisa fazer uma pesquisa extra para obter os endereços IP desses servidores de nomes.
Na prática, 99,99% do tempo, já haverá um endereço de servidor de nomes em cache
.com, mas fingimos que estamos realmente começando do zero.
Etapa 3 : pergunte aos servidores de nomes
.comsobre github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
Temos um novo endereço IP para enviar a solicitação! Este é um dos servidores de nomes de github.com.
Etapa 4 : peça aos servidores de nomes github.com o endereço github.com.
Estamos quase terminando!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Portanto, temos um registro A para github.com. O servidor recursivo agora tem o IP github.com e pode devolvê-lo a você. E ele foi capaz de passar por todo o processo, começando com apenas alguns endereços IP codificados: os endereços dos servidores de nomes raiz.
Como ver todas as etapas de um servidor DNS recursivo: dig + trace
Para ver o que o servidor DNS recursivo fará para resolver o domínio, você pode executar:
$ dig @8.8.8.8 +trace github.com
Esse comando mostra todos os registros DNS que o servidor recursivo solicita, começando com os servidores DNS raiz, que são as quatro etapas que acabamos de seguir.
Atualizar registros DNS
Agora que sabemos o básico de como o DNS funciona, vamos atualizar alguns registros DNS e ver o que acontece.
Ao atualizar os registros DNS, existem duas opções principais:
- manter os mesmos servidores de nomes;
- alterar servidores de nomes.
Vamos falar sobre TTL
Mas esquecemos algo importante. Este é o TTL. Como dissemos antes, o servidor DNS recursivo armazenará os registros em cache até que expirem. Ele decide sobre a expiração de um registro com base em seu TTL (tempo de vida).
Neste exemplo, o servidor de nomes GitHub retorna um TTL de 60 para seu registro DNS, o que significa 60 segundos:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Este é um TTL bastante curto. Em teoria, se todas as implementações de DNS seguissem o padrão DNS , isso significaria que se o GitHub decidisse alterar o endereço IP de github.com, todos receberiam um novo endereço IP em 60 segundos. Vamos ver como isso acontece na prática.
Opção 1: atualizar o registro DNS nos mesmos servidores de nomes
Primeiro, atualizei meus servidores de nomes (Cloudflare) para obter um novo registro DNS, o registro A, que mapeia
test.jvns.capara 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Funcionou imediatamente! Não havia necessidade de esperar, porque antes disso não havia nenhum registro DNS
test.jvns.caque pudesse ser armazenado em cache. Excelente. Mas parece que o novo registro é armazenado em cache por cerca de cinco minutos (299 segundos).
E se tentarmos alterar esse endereço IP? Mudei para 5.6.7.8 e executei a mesma consulta DNS:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Parece que neste servidor DNS o registro 1.2.3.4 ainda é armazenado em cache por 144 segundos. Curiosamente, se você consultar 8.8.8.8 várias vezes, obterá resultados conflitantes - às vezes, ele fornece um novo IP e às vezes um antigo. Provavelmente o 8.8.8.8 realmente distribui a carga por vários back-ends diferentes, cada um com seu próprio cache.
Após cinco minutos de espera, todos os caches do 8.8.8.8 foram atualizados e sempre retornaram uma nova entrada do 5.6.7.8. Surpreendente. É muito rápido!
Você nem sempre pode confiar no TTL
Como acontece com a maioria dos protocolos da Internet, nem tudo segue as especificações DNS. Alguns servidores DNS do ISP armazenarão em cache os registros por mais tempo do que o TTL especificado. Por exemplo, em dois dias em vez de cinco minutos. E as pessoas sempre podem codificar o endereço IP antigo em seus arquivos
/etc/hosts.
Na prática, ao atualizar um registro DNS com um TTL de cinco minutos, você pode esperar que uma grande porcentagem de clientes migre rapidamente para novos endereços IP (por exemplo, em 15 minutos) e, em seguida, haverá um monte de retardatários que serão atualizados lentamente nos próximos dias.
Opção 2: atualizar seus servidores de nomes
Portanto, vimos que, quando você renova um endereço IP sem alterar seus servidores de nome, muitos servidores DNS obtêm um novo endereço IP muito rapidamente. Excelente. Mas o que acontece se você alterar seus servidores de nomes? Vamos tentar!
Eu não queria atualizar os servidores de nomes do meu blog, então, em vez disso, peguei um domínio diferente meu e usei-o nos exemplos para o log HTTP , examplecat.com.
Anteriormente, meus servidores estavam configurados para
dns1.p01.nsone.net. Decidi mudá-los para servidores do Google com endereços ns-cloud-b1.googledomains.come assim por diante.
Quando fiz a alteração, meu registrador de domínio exibiu uma mensagem um tanto sinistra: “Alterações em examplecat.com salvas. Eles entrarão em vigor nas próximas 48 horas. " Em seguida, defini um novo registro A para o domínio para apontar para 1.2.3.4.
Ok, vamos ver se algo mudou:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Sem alterações. Se eu perguntar a outro servidor DNS, ele saberá o novo IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Mas 8.8.8.8 ainda não sabe de nada. O motivo pelo qual 1.1.1.1 vê um novo IP, embora eu o tenha alterado há cinco minutos, é provavelmente porque ninguém nunca perguntou a 1.1.1.1 sobre este examplecat.com antes - o que significa que ele não tem nada em seu cache Isso foi.
Os servidores de nomes têm muito mais TTL
O motivo pelo qual meu registrador disse: “Isso levará 48 horas” é porque o TTL nos registros NS é muito maior.
O novo servidor de nomes definitivamente retorna um novo endereço IP para examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Mas lembre-se do que aconteceu quando consultamos os servidores de nomes github.com anteriormente:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172.800 segundos são 48 horas! Portanto, a atualização do servidor de nomes geralmente leva muito mais tempo. Leva algum tempo para os caches expirarem e propagarem o novo endereço. Demora muito mais do que apenas atualizar seu endereço IP sem alterar seu servidor de nomes.
Como seus servidores de nomes são atualizados
Quando eu atualizo os servidores de nomes para
examplecat.com, o servidor de nomes .comobtém um novo registro NS com um novo domínio. Como isso:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Mas como esse novo registro NS chega lá? Na verdade, eu digo ao meu registrador de domínio como desejo a aparência dos novos servidores de nomes, atualizando-os no site, e então meu registrador de domínio diz aos servidores
.comde nomes para fazer a atualização.
Pois
.comessas atualizações são muito rápidas (em alguns minutos), mas acho que, para algumas outras zonas de TLD, os servidores de nomes podem não aplicar as atualizações tão rapidamente.
A biblioteca de resolução de DNS do seu programa também pode armazenar em cache os registros de DNS
Outro motivo pelo qual o TTL pode não ser observado na prática é que muitos programas devem resolver nomes DNS e alguns programas também armazenam em cache os registros DNS na memória indefinidamente (até que o programa seja reiniciado).
Por exemplo, há um artigo sobre como configurar JVM TTL para pesquisas de nomes DNS . Eu mesmo não escrevi muito código JVM para pesquisas de DNS, mas uma pequena pesquisa na Internet sobre JVM e DNS dá a impressão de que você pode configurar a JVM para armazenar em cache todas as pesquisas de DNS por um período infinito de tempo (consulte este tíquete ElasticSearch, por exemplo ) ...
Isso é tudo!
Espero que isso ajude você a entender o que acontece quando seu DNS é atualizado.
Farei uma reserva de que todo o histórico de propagação do DNS é determinado não apenas pelo TTL. Alguns servidores DNS recursivos provavelmente não respeitam TTLs, mesmo os principais servidores como 8.8.8.8. Portanto, mesmo que você apenas atualize o registro A com um pequeno TTL, é possível que, na prática, você ainda receba solicitações para o IP antigo em um ou dois dias.
Depois de postar este artigo, mudei os servidores de nomes de examplecat.com de volta aos valores antigos.
O que mais ler:
- Go e caches de CPU .
- Qual banco de dados escolher para o projeto para que você não precise escolher novamente .
- Nosso canal Telegram é sobre transformação digital .