Introducción
Willow Commons va a trasladar su sitio web a una nueva dirección de servidor. La comunidad debe seguir utilizando site.community.test y la ubicación original debe permanecer disponible durante la transición. Ambos backends ya contienen sus programas legítimos; tu trabajo es migrar DNS, no publicar contenido.
Completa primero Ver qué dirección utiliza un cliente. Este entorno independiente vuelve a empezar con el nombre formal en la dirección antigua, un servidor autoritativo y resolutores de caché separados, y servicios HTTP antiguo y nuevo preparados. No reutiliza la VM anterior. Prepararás el TTL, cambiarás la dirección y verificarás clientes reales y contenido completo. Reserva unos 50 minutos, incluida la lectura y los errores habituales; es una estimación del autor.
Este es un ejercicio DNS local controlado. No promete propagación mundial, ausencia de interrupciones, migración de un registrador público ni permiso para eliminar inmediatamente el servidor antiguo.
Preparar la ventana de transición
En este paso comprobarás el servicio normal y el backend nuevo antes de acortar el TTL del registro formal. Empieza en Community Preview, selecciona Warm Client y lee la página actual de Willow Commons con la etiqueta old location. No utilices Fresh Client hasta cambiar la dirección. Su resolutor independiente todavía no ha consultado este sitio.
Cambia a Warm Client. Los comandos y las opciones de curl son los mismos que en la primera unidad. Solicita primero el servicio existente por su nombre:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Debes obtener el programa completo de Service location: old. Después comprueba el backend nuevo preparado mediante su dirección, con la misma ruta y puerto:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
Debes ver los mismos tres encuentros y la información de entrada con Service location: new. Esta prueba directa de disponibilidad omite DNS intencionadamente; no demuestra que un cliente que utiliza el nombre haya migrado. Conserva ambos sitios sin cambios.
Consulta la copia actual de Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
Debes obtener la dirección antigua con un TTL no superior a 120. Si la copia preparada en la caché caducó mientras leías, esta consulta real obtiene otra copia del registro antiguo que sigue vigente. No hay un plazo que empiece al abrir el laboratorio.
Cambia a DNS Desk, en /home/labex/project/site-move, y lee el archivo de registros y el plan de backends preparado:
cat backends.tsv
cat community.zone
Las modificaciones de migración se limitan a la dirección A y el TTL de site, más el serial SOA necesario. practice queda reservado para observaciones repetibles opcionales; debes conservar keep, el servidor de nombres y todos los bytes de los sitios. El registro antiguo preparado tiene un TTL real de 120 segundos. El ejercicio utiliza segundos deliberadamente; no significa que la vida de una caché de un día en producción desaparezca en dos minutos.
Antes de cambiar la dirección, reduce únicamente el TTL del registro formal. Este here-document literal completo utiliza la sintaxis de escritura de archivos enseñada en la primera unidad:
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
Debes obtener loaded serial 2 y OK; corrige cualquier problema de sintaxis antes de recargar:
sudo /opt/labex/site-move/reload-zone
Confirma el servidor autoritativo en ejecución, no solo el archivo guardado:
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Debes obtener 45 IN A 10.94.0.10. El backend antiguo sigue siendo la respuesta autoritativa. Cambia a Warm Client:
dig @127.0.0.1 site.community.test A +noall +answer
La copia antigua en caché conserva su vida restante anterior. No confundas un TTL restante de 40 con una prueba de que se obtuvo la nueva política de 45 segundos: una copia antigua de 120 segundos también puede tener 40 pendientes.
Espera a que caduque la copia antigua observada y consulta otra vez. Puedes esperar los últimos segundos restantes mostrados más uno. El comando conservador completo siguiente cubre el máximo original de 120 segundos:
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
Debes obtener la dirección antigua con un TTL recién adquirido de unos 45 segundos. Esta última petición DNS es importante: la caducidad elimina una copia antigua, pero no obtiene por sí sola su sustituta. El intercambio DNS nativo registra la respuesta antigua con su duración reducida. La comprobación lee ese intercambio existente antes de hacer ninguna prueba y nunca prepara esta etapa por ti.
Si no hay respuesta o aparece otra dirección, vuelve a leer las salidas exactas del servidor autoritativo y del cliente antes de continuar. Corrige los errores del archivo en DNS Desk, valida, recarga y repite la consulta por nombre en Warm Client. No reinicies ni vacíes un resolutor. Ejecuta la comprobación de esta etapa solo cuando hayas obtenido realmente la dirección antigua con la vida reducida.
Cambiar la dirección y comparar dos clientes
En este paso trasladarás el nombre formal y compararás clientes independientes. Lee el paso antes de empezar la breve secuencia. La próxima consulta del cliente warm muestra la ventana de comparación restante; un acierto de caché no reinicia su TTL. Solo una copia nueva obtenida después de la caducidad natural empieza una vida nueva de 45 segundos, independientemente de la preparación del entorno. Una edición lenta puede perder la diferencia visible; la migración sigue siendo válida y la recuperación con el nombre de práctica separado permite repetir la observación.
En Warm Client, actualiza la vista actual:
dig @127.0.0.1 site.community.test A +noall +answer
Si su TTL restante está a punto de agotarse, deja que caduque y consulta de nuevo antes de editar, mientras el servidor autoritativo siga devolviendo la dirección antigua. Después cambia a DNS Desk. Cambia la dirección A formal, conserva su TTL de 45 segundos y aumenta el 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
El servidor autoritativo en ejecución debe devolver ahora 45 IN A 10.94.0.20. Si sigue devolviendo la dirección antigua, el archivo guardado y los datos cargados no coinciden: revisa la sintaxis y el resultado de la recarga antes de interpretar una caché de cliente.
Cambia a 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 la vida restante de su copia puede usar legítimamente la dirección antigua y devolver Service location: old. Cambia a Fresh Client, que empieza en /home/labex/project/site-move/fresh con su propio resolutor:
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Debes obtener la dirección nueva y el programa completo de Service location: new. Dos clientes pueden utilizar el mismo nombre y llegar a backends válidos distintos durante una transición DNS. Son espacios de nombres de cliente Linux y procesos de caché independientes dentro de una sola VM, no dos dispositivos físicos ni dos VM independientes.
Si ambos ya muestran new: la copia warm caducó naturalmente antes de la comparación. Continúa con la migración formal; no se exige ninguna captura ni un solapamiento histórico para aprobar. Para repetir el fenómeno sin deshacerla, utiliza practice.community.test como en la primera unidad. En DNS Desk, conserva site en su dirección nueva, establece solo practice en la dirección antigua con 120 segundos y aumenta el serial actual con nano community.zone (Ctrl+O, Enter, Ctrl+X). Valida y recarga. En Warm Client, deja caducar cualquier copia de práctica actual y consulta practice para iniciar una ventana nueva. Cambia solo practice a la dirección nueva y 45 segundos con otro serial superior, valida y recarga, y compara practice mediante ambos clientes. El registro formal site permanece migrado todo el tiempo. Termina la observación de práctica de forma natural; nunca vacíes una caché ni sustituyas contenido del sitio.
Si cambiaste la dirección formal antes de completar la preparación del TTL, utiliza el procedimiento de edición aprendido para devolver solo site a la dirección antigua y 45 segundos, con un serial superior. Valida, recarga y deja caducar la respuesta actual de Warm Client. Solicita la dirección antigua con el TTL corto y vuelve a cambiarla con un serial aún mayor. Ambos backends originales siguen disponibles, por lo que esta reversión DNS limitada repara la secuencia sin restablecer servicios ni borrar trabajo. El objetivo final sigue siendo la dirección formal nueva. Ejecuta la comprobación de esta etapa después de confirmar el cambio en el servidor autoritativo en ejecución.
Confirmar la nueva ruta mediante DNS
En este paso demostrarás que los clientes controlados llegan al contenido nuevo y que el servicio antiguo sigue disponible. Empieza en Warm Client. Su copia original de la migración dura como máximo 60 segundos con la política permitida; el ejemplo utiliza 45. Inspecciona el TTL restante:
dig @127.0.0.1 site.community.test A +noall +answer
Si aún muestra la dirección antigua, espera los segundos restantes más uno y repite. Esta espera conservadora completa cubre la duración corta máxima permitida:
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
Debes obtener 10.94.0.20, con un TTL restante no superior a 45 para la política del ejemplo. Una dirección correcta no basta: solicita la página inicial y guarda el programa completo mediante ese nombre:
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
Debes obtener la página inicial auténtica new location y el programa Service location: new, con los tres encuentros y la información de entrada. Si DNS es correcto pero el contenido no, investiga la ruta y dirección del backend real; modificar el sitio antiguo para que parezca el nuevo queda fuera del alcance.
Cambia a Fresh Client y guarda independientemente el mismo 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
Debes obtener el mismo contenido de la ubicación nueva. Cambia a Community Preview, vuelve a su página de selección con Back del navegador si hace falta, selecciona cada cliente y actualiza la página real. Ambos muestran ahora new location. Utiliza Download the programme en cada vista y abre el texto completo. Estas peticiones del navegador utilizan el cliente del curso seleccionado, independientemente del DNS del equipo donde se ejecuta tu navegador.
Lee la etiqueta new location cerca de la parte superior y el enlace original al programa debajo de los tres encuentros. Cada cliente debe mostrar esta página auténtica del backend nuevo.
Vuelve a Warm Client para demostrar los requisitos de conservación. Solicita directamente el backend antiguo:
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
Debes obtener el programa original de la ubicación antigua. Consulta el nombre no relacionado en el servidor autoritativo:
dig @10.94.0.2 keep.community.test A +noall +answer
Debes obtener el valor intacto 120 IN A 10.94.0.10. El servicio antiguo sigue formando parte del contrato de transición. No lo detengas cuando migren dos clientes: estas observaciones no demuestran que todos los clientes del mundo real se hayan actualizado.
Si un archivo guardado contiene una ubicación anterior, repite el mismo comando de descarga en la pestaña correcta de ese cliente después de que cambie su consulta DNS real. Si la ruta es incorrecta, recupérate con pwd y cd /home/labex/project/site-move/warm, o con el directorio fresh correspondiente. Las comprobaciones finales leen las pruebas DNS y de recarga existentes antes de hacer sus propias peticiones. Repetir la evaluación no vacía cachés ni recarga el servidor autoritativo; las lecturas normales pueden añadir registros nativos.
Resumen
Comprobaste el backend nuevo, redujiste el TTL mientras la dirección antigua seguía siendo autoritativa y dejaste que un cliente real obtuviera esa política. Después cambiaste la dirección, comparaste clientes independientes y verificaste el contenido nuevo completo tras la caducidad natural. El nombre original, el backend antiguo y los registros no relacionados siguen disponibles. Son observaciones de clientes controlados, no una garantía de propagación DNS mundial.
