Si conocen algo sobre DNS, seguramente hayan oído hablar del tiempo de vida (en inglés, Time to Live, abreviado TTL). Sin embargo, cometer equivocaciones al configurar los TTL es más habitual de lo que uno podría pensar. En este artículo analizamos las peculiaridades de los conjuntos de registros de DNS, los dominios padre/hijo y cómo evitar los problemas con el TTL.
En esta entrada, analizaremos el valor del “tiempo de vida” (TTL), un campo de cada registro de DNS que le dice a los clientes DS cuánto tiempo de validez tiene la información de ese registro y, por lo tanto, cuánto tiempo se puede almacenar en el caché del cliente DNS. El TTL sería como la fecha de caducidad en una caja de leche. Una vez pasada esa fecha, el caché sabe que debe tirar esa leche y buscar una nueva.
El TTL y los registros de DNS padre/hijo
En el DNS, el “traspaso” de un servidor que sirve un nombre más corto (se.) a uno que sirve un nombre más largo (netnod.se.) se expresa mediante registros tipo “servidor de nombres” (en inglés, nameserver, abreviado NS). Un cliente que le solicite al servidor se. un nombre que termine en netnod.se. solo recibirá registros NS que le indiquen que debe buscar en otra parte, es decir, en los servidores que contienen la información de netnod.se.
Los registros que entrega en servidor se. (el “padre”) se verán de la siguiente forma:
netnod.se. 86400 IN NS nna.netnod.se.
netnod.se. 86400 IN NS nnb.netnod.se.
netnod.se. 86400 IN NS nnp.netnod.se.
netnod.se. 86400 IN NS nnu.netnod.se.
La cadena netnod.se. de la izquierda (llamada “nombre del propietario”) nos dice cuál subdominio (“hijo”) se delega; IN (la “clase”) nos dice que estamos tratando con información relacionada con Internet; NS (el “tipo de registro”) nos dice que la respuesta que estamos recibiendo es información del servidor de nombres para el hijo, y los nombres a la derecha (los “datos de registro”) nos dicen los nombres de los servidores que contienen información de DNS sobre netnod.se. y los nombres que se encuentran “por debajo” de este.
El último campo —el número 86400— se conoce como tiempo de vida (TTL). Este campo le informa a quien recibe los datos que puede confiar en los ellos (en este caso) durante 86 400 segundos (= 24 horas) sin tener que volver a preguntar nuevamente. Los datos se pueden almacenar localmente en el caché del cliente durante este período de tiempo.
PECULIARIDAD No. 1: Todos los TTL de un conjunto de registros deben tener el mismo valor
Un “conjunto de registros” (RRSET) es el conjunto completo de todos los registros que tienen el mismo nombre de propietario, la misma clase y el mismo tipo. En el ejemplo anterior, hay un conjunto de registros para la combinación [netnod.se., IN, NS] que consta de cuatro registros. El DNS trata los conjuntos de registros como si estuvieran “pegados entre sí” y siempre se deben transferir e interpretar como un grupo. Si se permitiera dividir el conjunto de registros, los distintos “actores” del mundo del DNS tendrían diferentes vistas de los datos del DNS, y la base de datos dejaría de ser coherente y consistente.
El requisito de que las vistas de la base de datos deben ser coherentes lleva al requisito de que el valor del TTL debe ser el mismo para todos los miembros de un conjunto de registros. Hay dos razones para ello:
- Los clientes reciben el RRSET y lo almacenan en sus cachés. Todos los valores del TTL de todos los registros en el caché se reducen de forma continua y, cuando el TTL de un registro llega a 0, este registro se elimina del caché. Si los miembros de un RRSET tienen diferentes TTL, se eliminarán en distintos momentos, lo que “obligará” al sistema de caché a dividir el conjunto de registros y ya no se cumplirá el requisito de la coherencia. El caché solo contendrá algunas de las partes. La imagen de la base de datos ya no será correcta. Por lo tanto, es importante que todos los registros de un RRSET se eliminen del caché al mismo tiempo. La ausencia de registros en el caché obligará al cliente a solicitar que la fuente le envíe un RRSET “nuevo” y el caché volverá a contener datos coherentes.
- Esto es incluso más importante cuando se agregan las extensiones de seguridad al DNS (habilitando DNSSEC). En DNSSEC, las firmas criptográficas se utilizan como una herramienta para que el cliente valide que los datos de DNS que recibe no hayan sido manipulados durante su tránsito por la red. DNSSEC firma conjuntos de registros, no registros individuales. Una parte importante de la firma es “el TTL original” (es decir, el valor inicial del TTL, antes de que el caché comenzara a disminuirlo). Ese TTL original es un valor único que cubre a todo el RRSET. Si los registros del conjunto originalmente tenían valores distintos, la firma no sería correcta y no sería posible validar los datos.
RECOMENDACIÓN: Asegúrese de que todos los registros de un conjunto tengan el mismo TTL.
PECULIARIDAD No. 2: Los registros NS para padres e hijos deben estar sincronizados
Los registros NS deben estar presentes tanto en el padre (quien “otorga autoridad”) como en el hijo (quien “recibe autoridad”). Los registros se ven exactamente iguales en ambas ubicaciones, pero no se mantienen sincronizados en forma automática (a menos que se usen adiciones muy recientes al protocolo DNS). Esto se debe hacer manualmente. Como todos sabemos, los seres humanos no somos muy buenos para mantener las cosas sincronizadas, por lo que esto crea una gran oportunidad para que los sistemas diverjan. Habitualmente suceden dos cosas:
- Los administradores de los datos hijos cambian el conjunto de servidores de nombres y se olvidan de informar al padre sobre su deseo de hacerlo. Si los administradores hijos cambian todos los servidores, las cosas dejarán de funcionar. Si solo cambian algunos, las cosas podrían seguir funcionando de manera degradada.
- Los registros del padre tienen un TTL diferente al del hijo. Esto es menos problemático, pero puede generar un tráfico de DNS innecesario si los TTL de los registros en la base de datos hija tienen un TTL más bajo que los de la base de datos padre. Dado que los registros NS en la base de datos hijo se consideran “autoritativos” (es decir, tienen una “prioridad” más alta) que los del padre, el hijo puede “jugar” con el TTL sin el conocimiento o consentimiento del padre. Si el padre diseña sus sistemas DNS para un determinado patrón de tráfico que es el resultado esperable de configurar el TTL para sus hijos en un valor específico, puede que se sorprendan si los hijos establecen el TTL para los registros NS en un valor completamente diferente.
RECOMENDACIÓN: Como administrador de datos hijos, mantenga alineados los valores de sus TTL para los registros NS con los que aparecen en la base de datos de su padre
Espero que este artículo les haya resultado útil. Estén atentos ya que publicaremos otras notas a medida que profundicemos en las peculiaridades del DNS. Mientras tanto, si tienen alguna pregunta sobre la configuración del DNS o sobre cómo el servicio de DNS anycast de Netnod puede ayudarles, pueden hacer clic aquí para comunicarse con nosotros.
