La transferencia de zona DNS , también conocida a veces como el tipo de consulta DNS inductora AXFR , es un tipo de transacción DNS . Es uno de los muchos mecanismos disponibles para que los administradores repliquen bases de datos DNS en un conjunto de servidores DNS .
Una transferencia de zona utiliza el Protocolo de control de transmisión (TCP) para el transporte, [1] [2] y toma la forma de una transacción cliente-servidor . El cliente que solicita una transferencia de zona puede ser un servidor secundario que solicita datos de un servidor primario . [3] La parte de la base de datos que se replica es una zona .
La transferencia de zona consta de un preámbulo, seguido de la transferencia de datos real. El preámbulo comprende una búsqueda del registro de recursos de inicio de autoridad (SOA) para el "ápice de zona", el nodo del espacio de nombres DNS que se encuentra en la parte superior de la "zona". Los campos de este registro de recursos SOA, en particular el "número de serie", determinan si es necesario o no que se realice la transferencia de datos real. El cliente compara el número de serie del registro de recursos SOA con el número de serie de la última copia de ese registro de recursos que tiene. Si el número de serie del registro que se está transfiriendo es mayor, se considera que los datos de la zona han "cambiado" (de alguna manera) y el secundario procede a solicitar la transferencia de datos de la zona real. Si los números de serie son idénticos, se considera que los datos de la zona no han "cambiado" y el cliente puede continuar utilizando la copia de la base de datos que ya tiene, si tiene una.
El proceso de transferencia de datos propiamente dicho comienza cuando el cliente envía una consulta (código de operación 0) con el tipo de consulta especial AXFR (valor 252) a través de la conexión TCP al servidor. Aunque DNS técnicamente admite AXFR sobre el Protocolo de datagramas de usuario (UDP), se considera que no es aceptable debido al riesgo de pérdida o falsificación de paquetes. [2] [1] El servidor responde con una serie de mensajes de respuesta que comprenden todos los registros de recursos de cada nombre de dominio de la "zona". La primera respuesta comprende el registro de recursos SOA para el vértice de la zona. Los demás datos siguen sin ningún orden especificado. El final de los datos se indica mediante el servidor que repite la respuesta que contiene el registro de recursos SOA para el vértice de la zona.
Algunos clientes de transferencia de zona realizan la búsqueda SOA del preámbulo mediante el mecanismo de resolución de consultas DNS normal de su sistema. Estos clientes no abren una conexión TCP con el servidor hasta que han determinado que necesitan realizar la transferencia de datos real. Sin embargo, dado que TCP se puede utilizar para transacciones DNS normales, así como para la transferencia de zona, otros clientes de transferencia de zona realizan la búsqueda SOA del preámbulo mediante la misma conexión TCP a la que luego (pueden) realizar la transferencia de datos real. Estos clientes abren la conexión TCP con el servidor incluso antes de realizar el preámbulo.
Lo anterior describe la transferencia de zona completa. La transferencia de zona incremental difiere de la transferencia de zona completa en los siguientes aspectos:
La transferencia de zona es completamente iniciada por el cliente. Aunque los servidores pueden enviar un mensaje de NOTIFICACIÓN a los clientes (sobre el que han sido informados) cada vez que se realiza un cambio en los datos de la zona, la programación de las transferencias de zona está completamente bajo el control de los clientes. Los clientes programan las transferencias de zona inicialmente, cuando sus bases de datos están vacías, y luego a intervalos regulares, en un patrón controlado por los valores de los campos "refresh", "retry" y "expire" en el registro de recursos SOA del vértice de la zona.
Aunque está estandarizada, la transferencia de zona completa se describe como uno de los posibles mecanismos de replicación de bases de datos en RFC 1034 y RFC 5936 (la transferencia de zona incremental se describe en RFC 1995), la transferencia de zona es el más limitado de esos mecanismos de replicación de bases de datos. La transferencia de zona opera en términos de registros de recursos de " formato de cable ", es decir , registros de recursos tal como se transfieren utilizando el protocolo DNS. Sin embargo, el esquema de los registros de recursos de formato de cable puede no ser idéntico al esquema de base de datos utilizado por los back-end de los propios servidores DNS.
La parte del preámbulo de la transferencia de zona se basa en el número de serie, y solo en él, para determinar si los datos de una zona han cambiado y, por lo tanto, si se requiere la transferencia de datos real. En el caso de algunos paquetes de servidores DNS, los administradores mantienen manualmente los números de serie de los registros de recursos SOA. Cada edición de la base de datos implica realizar dos cambios, uno en el registro que se está modificando y el otro en el número de serie de la zona. El proceso requiere precisión: el administrador puede olvidarse de cambiar el número de serie o cambiarlo incorrectamente (reducirlo). La RFC 1912 (sección 2.2 Registros SOA) recomienda utilizar el valor AAAAMMDDnn como número (AAAA=año, MM=mes, DD=día, nn=número de revisión). Esto no se desbordará hasta el año 4294.
Algunos paquetes de servidores DNS han superado este problema al construir automáticamente el número de serie a partir de la última marca de tiempo de modificación del archivo de base de datos en el disco. Este es el caso de djbdns , por ejemplo. El sistema operativo garantiza que la última marca de tiempo de modificación se actualice siempre que un administrador edite el archivo de base de datos, actualizando automáticamente el número de serie y, por lo tanto, liberando a los administradores de la necesidad de realizar dos ediciones (en dos lugares diferentes) para cada cambio.
Además, el paradigma de replicación de base de datos para el cual está diseñada la verificación del número de serie (y de hecho la transferencia de zona en sí), que implica un único servidor DNS central que contiene la versión principal de la base de datos y todos los demás servidores DNS simplemente contienen copias, simplemente no coincide con el de muchos paquetes de servidores DNS modernos. [ cita requerida ] Los paquetes de servidores DNS modernos con bases de datos sofisticadas como servidores SQL y Active Directory permiten a los administradores realizar actualizaciones a la base de datos en múltiples lugares (tales sistemas emplean replicación multimaestro ), con el propio mecanismo de replicación de la base de datos manejando la replicación a todos los demás servidores. Este paradigma simplemente no coincide con el de un único número central que aumenta monótonamente para registrar los cambios y, por lo tanto, es incompatible con la transferencia de zona en gran medida. [ cita requerida ] Los paquetes de servidores DNS modernos con bases de datos sofisticadas a menudo crearán un número de serie "shim", simulando la existencia de un único lugar central donde se realizan las actualizaciones, pero esto es, en el mejor de los casos, imperfecto.
Afortunadamente, por esta y varias razones que se describen más adelante, los servidores DNS que utilizan back ends de base de datos tan sofisticados en general rara vez utilizan la transferencia de zona como su mecanismo de replicación de base de datos en primer lugar, y en su lugar suelen emplear los mecanismos de replicación de base de datos distribuida enormemente superiores que los mismos back ends proporcionan. [ cita requerida ]
Las comparaciones de números de serie tienen como objetivo utilizar la aritmética de números de serie , tal como se define en RFC 1982. Sin embargo, esto no se especificó claramente en RFC 1034, lo que da como resultado que no todos los clientes realicen la verificación del número de serie, en el preámbulo, de la misma manera. Algunos clientes simplemente verifican que el número de serie proporcionado por el servidor sea diferente del que conoce el cliente, o que no sea cero. Otros clientes verifican que el número de serie proporcionado por el servidor esté dentro de un rango determinado del número de serie que ya conoce el cliente. Sin embargo, otros clientes aún realizan la última verificación y, además, verifican que el número de serie proporcionado por el servidor no sea cero.
Originalmente, en la transferencia de datos propiamente dicha, cada conjunto de registros de recursos para un único nombre y tipo de dominio se transfería en un mensaje de respuesta independiente del servidor al cliente. Sin embargo, esto es ineficiente y algunos programas de servidores DNS implementaron optimizaciones destinadas a permitir que el mecanismo de compresión de respuesta del protocolo DNS reduzca los requisitos totales de ancho de banda de las transferencias de datos, como por ejemplo:
Algunos clientes fueron diseñados para esperar únicamente el formato de respuesta original y no podrían realizar la transferencia de datos si se emplearan dichas optimizaciones. Por lo tanto, varios paquetes de servidores DNS tienen una opción de configuración que permite a los administradores especificar el uso de respuestas de "formato de respuesta única" para aquellos clientes que lo requieran.
Los datos contenidos en una zona DNS pueden ser sensibles desde un punto de vista de seguridad operativa. Esto se debe a que información como los nombres de host de servidores pueden volverse de conocimiento público, lo que puede usarse para descubrir información sobre una organización e incluso proporcionar una mayor superficie de ataque . En junio de 2017, el registrador responsable de los dominios de nivel superior rusos habilitó accidentalmente las transferencias de zona DNS a través de AXFR, lo que provocó que 5,6 millones de registros quedaran expuestos accidentalmente. [4]
En 2008, un tribunal de Dakota del Norte (EE. UU.) dictaminó que realizar una transferencia de zona como un extraño no autorizado para obtener información que no era accesible al público constituye una violación de la ley de Dakota del Norte. [5]