Introducción
Willow Commons ya tiene un sitio comunitario que funciona. Antes de trasladarlo, averigua qué dirección utiliza realmente un cliente. Un registro DNS guardado, una respuesta almacenada en caché y una respuesta del sitio describen partes diferentes del recorrido.
Primero usarás el sitio normal, compararás un servidor autoritativo real con un resolutor de caché independiente y cambiarás un nombre de práctica separado. El nombre que utiliza la comunidad no cambia en esta unidad. Los dos backends HTTP y los servicios DNS están preparados en espacios de nombres de red Linux aislados que comparten el núcleo de una VM.
Debes saber introducir comandos, reconocer rutas y cambiar de pestaña. Este laboratorio explica los comandos DNS y las pequeñas modificaciones de configuración que utiliza. No necesitas una cuenta de dominio público ni experiencia previa administrando BIND. Reserva unos 40 minutos, incluida la lectura y los errores habituales; es una estimación del autor.
Utilizar el sitio que funciona por su nombre
En este paso leerás el sitio actual de la comunidad y guardarás su programa real. Empieza en Community Preview y selecciona Warm Client. Debes ver la página de Willow Commons, tres encuentros y la etiqueta old location. Selecciona Download the programme y abre el texto descargado. La etiqueta de ubicación identifica al backend; no es una animación de éxito.
Lee la etiqueta de ubicación cerca de la parte superior y utiliza Download the programme, debajo de los tres encuentros. La página mostrada es una respuesta real del backend original.
La vista previa realiza una consulta DNS y una petición HTTP reales desde el cliente del curso seleccionado. Su URL externa de plataforma es una pasarela para el navegador; no significa que tu equipo utilice el DNS del curso. Actualizar el navegador envía otra petición sin vaciar la caché del resolutor del curso. Por ahora no utilices Fresh Client.
Cambia al terminal Warm Client. Empieza en /home/labex/project/site-move/warm y tiene su propia configuración de resolución. pwd muestra el directorio actual:
pwd
DNS, el sistema de nombres de dominio, relaciona un nombre con una dirección. Un registro A relaciona un nombre con una dirección IPv4. Después, HTTP utiliza esa dirección y un puerto para solicitar contenido. Aquí el nombre es site.community.test; 8081 es el puerto HTTP, no un valor del registro DNS. .test es un sufijo reservado para pruebas, no un dominio comunitario público.
curl realiza una petición HTTP. --noproxy '*' excluye cualquier proxy en esta petición; las comillas mantienen literal el asterisco. -f trata los errores HTTP como fallos, -s oculta el indicador de progreso y -S sigue mostrando los errores. --max-time 5 limita la petición a cinco segundos:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Debes obtener HTML que contenga Willow Commons y old location. El terminal muestra el código fuente; el navegador representa la misma página. Ahora descarga el recurso de texto real. -o programme.txt guarda la respuesta en el directorio actual de este cliente:
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat muestra el archivo guardado:
cat programme.txt
Debes ver los tres encuentros, la información de acceso sin escalones y Service location: old. La existencia de un archivo o un estado HTTP, por sí solos, no demuestran que el contenido sea correcto.
Si curl indica Could not resolve host, comprueba la escritura del nombre. Failed to connect significa que no se estableció una conexión HTTP; es distinto de un HTTP 404, que significa que un servidor respondió pero la ruta no existía. Corrige la errata y repite la URL indicada. No cambies el DNS de la plataforma, /etc/hosts ni un archivo del resolutor del curso. Si abres otro terminal, utiliza la pestaña real Warm Client y ejecuta cd /home/labex/project/site-move/warm antes de guardar. Los archivos y los directorios de trabajo pertenecen a ese cliente; una descarga del navegador pertenece a tu navegador.
Comparar el servidor autoritativo y la caché
En este paso distinguirás el registro de origen de una copia temporal en caché. Quédate en Warm Client. El servidor autoritativo gestiona community.test y su dirección es 10.94.0.2. El resolutor de caché del cliente escucha en 127.0.0.1, la dirección de bucle local dentro de este cliente. El otro cliente tiene su propio resolutor y su propia caché.
dig plantea una pregunta a DNS. @10.94.0.2 selecciona explícitamente el servidor. A solicita una dirección IPv4. +noall oculta las secciones habituales de dig y +answer muestra las filas de respuesta:
dig @10.94.0.2 site.community.test A +noall +answer
Debes obtener una fila con esta forma:
site.community.test. 120 IN A 10.94.0.10
Las columnas son nombre, TTL, clase, tipo y dirección. TTL, tiempo de vida, es el número de segundos durante los que una respuesta puede permanecer en caché. IN es la clase Internet. El punto final indica un nombre DNS completo. Los espacios y tabuladores pueden variar.
Pregunta ahora al resolutor del cliente del curso:
dig @127.0.0.1 site.community.test A +noall +answer
La dirección debe seguir siendo 10.94.0.10, pero el TTL puede ser menor porque la petición anterior llenó la caché. sleep 5 espera cinco segundos reales sin modificar DNS:
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Normalmente disminuye el TTL restante. Si caducó la copia anterior, el resolutor vuelve a preguntar al servidor autoritativo y el TTL sube de nuevo hacia 120. Leer este laboratorio puede consumir todo el intervalo. Eso es una caducidad normal, no una caché averiada. No es necesario aprovechar una ventana que empiece al preparar el entorno.
Utiliza un nombre separado para la próxima modificación. Apunta al mismo backend antiguo, pero no es el nombre formal del sitio comunitario:
dig @127.0.0.1 practice.community.test A +noall +answer
Observa el nombre, la dirección y el TTL restante. Una consulta correcta no demuestra que el sitio sea accesible; el paso 1 realizó la petición HTTP por separado. Ejecuta la comprobación de este paso y lee el siguiente antes de empezar la breve secuencia de modificación y comparación.
Cambiar un registro de práctica y dejar que caduque su caché
En este paso validarás una pequeña modificación, la cargarás en el servidor autoritativo y observarás por qué un TTL menor no acorta una copia ya almacenada. Solo puedes modificar practice y el serial SOA necesario en community.zone. Conserva el nombre formal site, keep, el servidor de nombres y ambos sitios.
Primero lee las instrucciones de edición. Después, en Warm Client, consulta otra vez el nombre de práctica justo antes de cambiar de pestaña:
dig @127.0.0.1 practice.community.test A +noall +answer
Si quedan pocos segundos, espera a que termine ese intervalo y consulta de nuevo mientras el servidor autoritativo conserve el registro original. Esto renueva la ventana de observación mediante una petición DNS real; no vacía la caché. Una copia nueva dura hasta 120 segundos. Trabaja a tu ritmo y utiliza el párrafo de recuperación si pierdes la ventana.
Cambia a DNS Desk, cuyo directorio es /home/labex/project/site-move. Lee el archivo:
cat community.zone
Una zona es el conjunto de datos autoritativos de una parte de DNS. $TTL 120 proporciona una duración predeterminada. practice 120 IN A 10.94.0.10 establece una duración y dirección explícitas para el nombre de práctica. SOA, Start of Authority, incluye un número de versión llamado serial. Auméntalo al publicar un cambio y conserva los demás valores SOA. Los tiempos de vida DNS y los temporizadores SOA tienen funciones distintas. Aquí @ representa el origen de la zona, community.test.. NS nombra su servidor autoritativo y el registro A de ns proporciona la dirección de ese servidor. Los paréntesis agrupan los campos SOA en un registro. Los valores actuales de actualización, reintento, caducidad y caché negativa pertenecen a la administración de la zona: no los cambies. No son el TTL del registro A de práctica.
El siguiente here-document escribe la zona pequeña completa. > sustituye el archivo. Las comillas de 'ZONE' mantienen $TTL como texto literal, sin expandirlo como variable de shell. El último ZONE debe comenzar al principio de la línea. Copia todo el bloque:
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 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Solo han cambiado la dirección y la duración de práctica, además del serial. named-checkzone valida toda la zona guardada sin cargarla. Su primer argumento es el nombre de zona y el segundo es el archivo:
named-checkzone community.test community.zone
Debes ver loaded serial 2, seguido de OK. Es un resultado de validación del archivo, no una prueba de que el servidor en ejecución lo haya cargado. Si falla la sintaxis, lee el archivo, restaura el bloque completo y vuelve a comprobarlo. Un archivo guardado incorrectamente deja disponible la zona anterior en ejecución hasta que se realice una recarga válida.
sudo ejecuta este único comando administrativo. La herramienta de alcance limitado suministrada invoca el verdadero rndc reload community.test de BIND dentro del servidor autoritativo del curso; no reinicia ninguna caché:
sudo /opt/labex/site-move/reload-zone
Debes ver zone reload queued. Consulta el servidor autoritativo en ejecución para confirmar qué se cargó realmente. El escritorio no tiene un resolutor predeterminado del curso, por lo que este diagnóstico entra explícitamente en el espacio de nombres de red del servidor autoritativo. ip netns exec site-authority ejecuta únicamente el comando que sigue dentro de esa red del curso:
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Debes obtener 45 IN A 10.94.0.20. Cambia a Warm Client y consulta su caché:
dig @127.0.0.1 practice.community.test A +noall +answer
Durante la vida restante de la copia original puede seguir devolviendo 10.94.0.10, incluso con más de 45 segundos pendientes. El nuevo TTL de 45 segundos se aplica a copias nuevas; no reescribe la respuesta antigua almacenada. Ambos backends siguen funcionando mientras los clientes pueden discrepar legítimamente.
Espera el TTL restante que acabas de observar más un segundo y consulta otra vez. Por ejemplo, si mostraba 37 segundos, sleep 38 basta para esa copia. La siguiente espera conservadora cubre el máximo original completo de 120 segundos, aunque no hayas anotado el valor exacto:
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Ahora debes obtener 10.94.0.20 y un TTL restante no superior a 45. Lee la fila real: que termine un temporizador no demuestra nada por sí solo. Realiza una petición HTTP por nombre desde el mismo cliente:
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Debes obtener Service location: new con el programa completo. El nombre formal site.community.test sigue sirviendo la ubicación antigua.
Si no viste la diferencia: el resultado completado sigue siendo válido. Para repetir la observación, utiliza solo practice: en DNS Desk, restaura su línea a practice 120 IN A 10.94.0.10 y aumenta el serial SOA actual mediante nano community.zone. nano es un editor de texto: muévete con las flechas, edita solo esa línea y el serial, pulsa Ctrl+O, Enter para guardar y Ctrl+X para salir. Valida y recarga con los mismos comandos anteriores. Espera a que el TTL observado actualmente en el cliente de práctica caduque de forma natural, consulta para obtener la dirección antigua durante un máximo de 120 segundos y cambia solo practice a la nueva dirección y 45 segundos, con otro serial superior. Valida, recarga y compara inmediatamente. Termina con la caducidad natural y una petición real al sitio nuevo. Nunca restablezcas el sitio formal, reinicies resolutores ni sustituyas contenido web para repetir una ventana.
Si escribiste mal una ruta, utiliza pwd y cd /home/labex/project/site-move en DNS Desk antes de volver a leer el archivo. Los errores de sintaxis y de contenido son problemas distintos: valida el archivo, inspecciona el servidor autoritativo en ejecución, inspecciona la caché y solicita HTTP. Ejecuta la comprobación final cuando el cliente de práctica resuelva la dirección nueva.
Resumen
Has utilizado un sitio que funciona por su nombre, guardado su programa completo y separado los datos autoritativos, las respuestas DNS en caché y el contenido HTTP. Validaste una modificación de práctica limitada y viste que reducir el TTL no acorta una copia existente. El sitio comunitario formal y el backend antiguo siguen disponibles. La próxima unidad aplica estos conocimientos a una migración de dirección por etapas.
