Introdução
A Willow Commons está movendo seu site para um novo endereço de servidor. A comunidade deve continuar usando site.community.test, e o local original precisa permanecer disponível durante a transição. Ambos os backends já contêm suas programações legítimas; seu trabalho é a migração DNS, não a publicação de conteúdo.
Conclua primeiro Ver qual endereço um cliente utiliza. Este ambiente independente recomeça com o nome oficial no endereço antigo, servidor autoritativo e resolvedores de cache separados, além dos serviços HTTP antigo e novo prontos. Ele não reutiliza sua VM anterior. Você preparará o TTL, mudará o endereço e verificará clientes reais e conteúdo completo. Reserve cerca de 50 minutos, incluindo leitura e erros comuns; essa é uma estimativa do autor.
Este é um exercício DNS local controlado. Ele não promete propagação mundial, ausência de interrupções, migração em um registrador público nem permissão para excluir imediatamente o servidor antigo.
Preparar a janela de transição
Nesta etapa, você verificará o serviço normal e o backend novo antes de encurtar o TTL do registro oficial. Comece em Community Preview, selecione Warm Client e leia a página existente da Willow Commons com a identificação old location. Não use Fresh Client até a mudança de endereço. Seu resolvedor separado ainda não consultou esse site.
Mude para Warm Client. Os comandos e as opções curl são os mesmos da primeira unidade. Primeiro solicite o serviço existente pelo nome:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Você deve obter a programação completa de Service location: old. Depois confira o backend novo preparado pelo endereço, usando o mesmo caminho e porta:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
Você deve obter os mesmos três encontros e informações de entrada com Service location: new. Essa prova direta de disponibilidade ignora DNS intencionalmente; ela não demonstra que um cliente usando o nome migrou. Mantenha ambos os sites inalterados.
Consulte a cópia atual de Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
Você deve obter o endereço antigo com TTL não superior a 120. Se a cópia preparada no cache expirou durante a leitura, esta consulta real obtém outra cópia do registro antigo ainda vigente. Não há prazo contado a partir da abertura do laboratório.
Mude para DNS Desk, em /home/labex/project/site-move, e leia o arquivo de registros e o plano de backends preparado:
cat backends.tsv
cat community.zone
As edições de migração se limitam ao endereço A e ao TTL de site, além do serial SOA necessário. practice é reservado para observações repetíveis opcionais; preserve keep, o servidor de nomes e todos os bytes dos sites. O registro antigo preparado possui um TTL real de 120 segundos. O exercício usa segundos deliberadamente; isso não significa que a duração de um cache de um dia em produção desapareça em dois minutos.
Antes de mudar o endereço, reduza apenas o TTL do registro oficial. Este here-document literal completo usa a sintaxe de gravação ensinada na primeira unidade:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
Você deve obter loaded serial 2 e OK; corrija qualquer problema de sintaxe antes de recarregar:
sudo /opt/labex/site-move/reload-zone
Confirme o servidor autoritativo em execução, não apenas o arquivo salvo:
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Você deve obter 45 IN A 10.94.0.10. O backend antigo continua sendo o destino autoritativo. Mude para Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
A cópia antiga em cache mantém sua duração restante anterior. Não confunda um TTL restante de 40 com prova de que a nova política de 45 segundos foi obtida: uma cópia antiga de 120 segundos também pode ter 40 restantes.
Espere a cópia antiga observada expirar e consulte novamente. Você pode esperar os últimos segundos restantes exibidos mais um. O comando conservador completo abaixo cobre o máximo original de 120 segundos:
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
Você deve obter o endereço antigo com um TTL recém-obtido próximo de 45. Esta última requisição DNS é importante: expirar remove uma cópia antiga, mas não busca sua substituta. A troca DNS nativa registra a resposta do endereço antigo com duração reduzida. A verificação lê essa troca existente antes de suas próprias sondas e nunca prepara esta etapa por você.
Se não houver resposta ou aparecer outro endereço, releia as saídas exatas do servidor autoritativo e do cliente antes de continuar. Corrija erros no arquivo em DNS Desk, valide e recarregue, depois repita a consulta por nome em Warm Client. Não reinicie nem limpe um resolvedor. Execute a verificação desta fase somente depois de obter realmente o endereço antigo com a duração reduzida.
Mudar o endereço e comparar dois clientes
Nesta etapa, você moverá o nome oficial e comparará clientes independentes. Leia a etapa antes de começar a breve sequência. A próxima consulta warm mostra a janela de comparação restante; um acerto de cache não reinicia seu TTL. Só uma cópia nova obtida depois da expiração natural começa uma nova vida de 45 segundos, independentemente da preparação do ambiente. Uma edição lenta pode perder a diferença visível; a migração continua válida, e a recuperação com um nome de prática separado abaixo permite repetir a observação.
Em Warm Client, atualize a visão atual:
dig @127.0.0.1 site.community.test A +noall +answer
Se o TTL restante estiver quase acabando, deixe-o expirar e consulte novamente antes da edição, enquanto o servidor autoritativo ainda retorna o endereço antigo. Depois mude para DNS Desk. Altere o endereço A oficial, mantenha seu TTL de 45 segundos e aumente o serial:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
O servidor autoritativo em execução deve retornar agora 45 IN A 10.94.0.20. Se ainda retorna o endereço antigo, o arquivo salvo e os dados carregados diferem; confira a sintaxe e o resultado da recarga antes de interpretar o cache de um cliente.
Mude para Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Durante a vida restante em cache, ele pode legitimamente usar o endereço antigo e retornar Service location: old. Mude para Fresh Client, que começa em /home/labex/project/site-move/fresh com seu próprio resolvedor:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Você deve obter o endereço novo e a programação completa de Service location: new. Dois clientes podem usar o mesmo nome e chegar a backends válidos diferentes durante uma transição DNS. Eles são namespaces de clientes Linux e processos de cache independentes em uma VM, não dois dispositivos físicos nem VMs independentes.
Se ambos já mostram new: a cópia warm expirou naturalmente antes da comparação. Continue a migração oficial; não são exigidos captura de tela nem sobreposição histórica para passar. Para repetir o fenômeno sem desfazer a migração, use practice.community.test como na primeira unidade. Em DNS Desk, mantenha site no endereço novo, defina apenas practice para o endereço antigo e 120 segundos e aumente o serial atual com nano community.zone (Ctrl+O, Enter, Ctrl+X). Valide e recarregue. Em Warm Client, deixe qualquer cópia de prática atual expirar e consulte practice para iniciar uma janela nova. Altere apenas practice para o endereço novo e 45 segundos com outro serial maior, valide e recarregue, depois compare practice por ambos os clientes. O registro oficial site permanece migrado o tempo todo. Termine a observação de prática naturalmente; nunca esvazie um cache nem substitua conteúdo dos sites.
Se mudou o endereço oficial antes de concluir a preparação do TTL, use o procedimento de edição aprendido para devolver apenas site ao endereço antigo e 45 segundos com um serial maior. Valide e recarregue e deixe a resposta atual de Warm Client expirar. Solicite o endereço antigo com TTL curto e faça a troca novamente com um serial ainda maior. Os dois backends originais continuam disponíveis, portanto essa reversão DNS limitada corrige a sequência sem redefinir serviços nem apagar trabalho. O objetivo final continua sendo o novo endereço oficial. Execute a verificação desta fase depois de confirmar a mudança no servidor autoritativo em execução.
Confirmar o novo caminho por DNS
Nesta etapa, você provará que os clientes controlados chegam ao conteúdo novo e que o serviço antigo permanece disponível. Comece em Warm Client. Sua cópia original de migração dura no máximo 60 segundos conforme a política permitida; o exemplo usa 45. Inspecione o TTL restante:
dig @127.0.0.1 site.community.test A +noall +answer
Se ainda mostra o endereço antigo, espere os segundos restantes mais um e repita. Esta espera conservadora completa cobre a duração curta máxima permitida:
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
Você deve obter 10.94.0.20, com um TTL restante não superior a 45 na política mostrada. Um endereço correto não basta: solicite a página inicial e salve a programação completa por esse nome:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Você deve obter a página inicial verdadeira new location e a programação Service location: new, com os três encontros e as informações de entrada. Se DNS está correto, mas o conteúdo não, investigue o caminho e o endereço do backend real; editar o site antigo para parecer o novo está fora do escopo.
Mude para Fresh Client e salve independentemente o mesmo recurso completo:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Você deve obter o mesmo conteúdo do local novo. Mude para Community Preview, volte à seleção com Back do navegador se necessário, selecione cada cliente e atualize a página real. Agora ambos mostram new location. Use Download the programme em cada visualização e abra o texto completo. Essas requisições do navegador utilizam o cliente do curso selecionado, independentemente do DNS do computador do navegador.
Leia a identificação new location perto do topo e o link original da programação abaixo dos três encontros. Cada cliente deve mostrar esta página real do backend novo.
Volte para Warm Client para comprovar os requisitos de preservação. Solicite o backend antigo diretamente:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
Você deve obter a programação original do local antigo. Consulte o nome não relacionado no servidor autoritativo:
dig @10.94.0.2 keep.community.test A +noall +answer
Você deve obter o valor inalterado 120 IN A 10.94.0.10. O serviço antigo continua fazendo parte do contrato da transição. Não o pare depois que dois clientes migrarem: essas observações não estabelecem que todos os clientes do mundo real foram atualizados.
Se um arquivo salvo contém um local anterior, repita o mesmo comando de download na aba correta desse cliente depois que sua consulta DNS real mudar. Se o caminho estiver errado, recupere-se com pwd e cd /home/labex/project/site-move/warm, ou com o diretório fresh correspondente. As verificações finais leem as provas DNS e de recarga existentes antes de suas próprias requisições. Repetir a avaliação não esvazia caches nem recarrega o servidor autoritativo; leituras normais podem acrescentar registros nativos.
Resumo
Você verificou o backend novo, reduziu o TTL enquanto o endereço antigo continuava autoritativo e deixou um cliente real obter essa política. Depois mudou o endereço, comparou clientes independentes e verificou o conteúdo novo completo após a expiração natural. O nome original, o backend antigo e os registros não relacionados continuam disponíveis. São observações de clientes controlados, não uma garantia de propagação DNS mundial.
