Transferencia de zona DNS - DNS zone transfer

La transferencia de zona DNS , también conocida a veces por el tipo de consulta de DNS inductora AXFR , es un tipo de transacción de DNS . Es uno de los muchos mecanismos disponibles para que los administradores repliquen las 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 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, históricamente conocido como maestro y esclavo . La parte de la base de datos que se replica es una zona .

Operación

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 la zona", el nodo del espacio de nombres DNS que está 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 que se produzca la transferencia de datos real. El cliente compara el número de serie del registro de recursos SOA con el número de serie en la última copia de ese registro de recursos que tiene. Si el número de serie del registro que se transfiere 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 usando la copia de la base de datos que ya tiene, si la tiene.

El proceso de transferencia de datos real 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. El servidor responde con una serie de mensajes de respuesta, que comprenden todos los registros de recursos para cada nombre de dominio en la "zona". La primera respuesta comprende el registro de recursos SOA para el ápice de la zona. Los otros datos siguen sin ningún orden especificado. El servidor señala el final de los datos repitiendo la respuesta que contiene el registro de recursos SOA para el ápice de la zona.

Algunos clientes de transferencia de zona realizan la búsqueda SOA del preámbulo utilizando el mecanismo normal de resolución de consultas de DNS de su sistema. Estos clientes no abren una conexión TCP al servidor hasta que han determinado que necesitan realizar la transferencia de datos real. Sin embargo, dado que TCP se puede usar para transacciones DNS normales, así como para transferencia de zona, otros clientes de transferencia de zona realizan el preámbulo de búsqueda SOA sobre la misma conexión TCP, ya que luego (pueden) realizar la transferencia de datos real. Estos clientes abren la conexión TCP al 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:

  • El cliente utiliza el QTYPE IXFR especial (valor 251) en lugar del QTYPE AXFR.
  • El cliente envía el registro de recursos SOA para el ápice de la zona que tiene actualmente, si lo tiene, en el mensaje IXFR, lo que le permite al servidor saber qué versión de la "zona" cree que está actual.
  • Aunque el servidor puede responder de la manera AXFR normal con los datos completos de la zona, también puede responder con una transferencia de datos "incremental". Este último comprende la lista de cambios en los datos de la zona, en el orden del número de serie de la zona, entre la versión de la zona que el cliente informó al servidor que tiene y la versión de la zona actual en el servidor. Los cambios comprenden dos listas, una de los registros de recursos que se eliminan y otra de los registros de recursos que se insertan. (Una modificación a un registro de recursos se representa como una eliminación seguida de una inserción).

La transferencia de zona es totalmente iniciada por el cliente. Aunque los servidores pueden enviar un mensaje de NOTIFICACIÓN a los clientes (de los que se les ha informado) cada vez que se realiza un cambio en los datos de la zona, la programación de las transferencias de zona está totalmente bajo el control de los clientes. Los clientes programan 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 en los campos "actualizar", "reintentar" y "expirar" en el registro de recursos SOA del ápice de la zona.

Limitaciones

Aunque está estandarizada, la transferencia de zona completa se describe como uno de los posibles mecanismos de replicación de base de datos en RFC 1034 y RFC 5936 (transferencia de zona incremental descrita en RFC 1995), la transferencia de zona es el más limitado de esos mecanismos de replicación de base de datos. La transferencia de zona opera en términos de registros de recursos en " formato de cable ", es decir , registros de recursos a medida que se transfieren mediante el protocolo DNS. Sin embargo, el esquema de registros de recursos de formato de alambre no puede ser idéntico al esquema de base de datos utilizada por los extremos traseros de los servidores DNS propios.

Problemas operacionales

Cambios de número de serie

La parte del preámbulo de la transferencia de zona se basa en el número de serie, y solo en el número de serie, para determinar si los datos de una zona han cambiado y, por lo tanto, si se requiere la transferencia de datos real. Para algunos paquetes de servidor 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 olvidar cambiar el número de serie o cambiarlo incorrectamente (reducirlo). 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 servidor DNS han superado este problema construyendo 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 cada vez que un administrador edita el archivo de la base de datos, actualizando automáticamente el número de serie y liberando así a los administradores de la necesidad de realizar dos ediciones (en dos lugares diferentes) para cada cambio.

Además, el paradigma de la replicación de la base de datos para el que se diseñó la verificación del número de serie (y de hecho la transferencia de zona en sí), que involucra un único servidor DNS central que contiene la versión primaria de la base de datos con todos los demás servidores DNS que simplemente tienen copias, simplemente no coincide. el de muchos paquetes de servidores DNS modernos. Los paquetes de servidores DNS modernos con sofisticados back-end de bases de datos, como servidores SQL y Active Directory, permiten a los administradores realizar actualizaciones en la base de datos en varios lugares (dichos sistemas emplean replicación multimaestro ), con el propio mecanismo de replicación del back-end de la base de datos manejando la replicación para todos. otros servidores. Este paradigma simplemente no coincide con el de un número único, central, que aumenta monótonamente para registrar los cambios y, por lo tanto, es incompatible con la transferencia de zona en gran medida. Los paquetes de servidores DNS modernos con sofisticados back-end de bases de datos 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 esto y por varias razones que se describen más adelante, los servidores DNS que utilizan backends de base de datos tan sofisticados en general rara vez utilizan la transferencia de zona como mecanismo de replicación de la base de datos en primer lugar, y por lo general emplean los mecanismos de replicación de base de datos distribuidos muy superiores que los backends. ellos mismos proporcionan.

Comparaciones de números de serie

Las comparaciones de números de serie están destinadas a utilizar la aritmética de números de serie como se define en RFC 1982. Sin embargo, esto no se especificó claramente en RFC 1034, por lo que no todos los clientes realizan la verificación del número de serie, en el preámbulo, de la misma manera. Algunos clientes comprueban simplemente que el número de serie proporcionado por el servidor es diferente del conocido por el cliente, o distinto de 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 ya conocido por el cliente. Sin embargo, otros clientes siguen realizando la última comprobación y además comprueban que el número de serie proporcionado por el servidor no sea cero.

Múltiples registros de recursos

Originalmente, en la transferencia de datos real, cada conjunto de registros de recursos para un solo nombre y tipo de dominio se transfería en un mensaje de respuesta separado del servidor al cliente. Sin embargo, esto es ineficiente y algunos software de servidor DNS implementaron optimizaciones, orientadas a permitir que el mecanismo de compresión de respuesta en el protocolo DNS reduzca los requisitos de ancho de banda total de las transferencias de datos, tales como:

  • realizar un "procesamiento de sección adicional" para incluir cualquier conjunto de registros de recursos "pegado" en la misma respuesta que un conjunto de registros de recursos NS, SRV o MX
  • recopilar todos los conjuntos de registros de recursos relacionados con un solo nombre de dominio juntos y enviarlos, si encajan, en una sola respuesta

Algunos clientes se escribieron para esperar solo el formato de respuesta original y no podrían realizar la transferencia de datos si se emplearan tales optimizaciones. Por lo tanto, varios paquetes de servidor DNS tienen un ajuste de configuración que permite a los administradores especificar el uso de respuestas de "formato de respuesta única" para aquellos clientes que lo requieran.

Exposición de datos

Los datos contenidos en una zona DNS pueden ser sensibles desde el punto de vista de la seguridad operativa. Esto se debe a que la información, como los nombres de host de los servidores, puede convertirse en de conocimiento público, lo que se puede utilizar 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ó la exposición accidental de 5,6 millones de registros.

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 de acceso público constituye una violación de la ley de Dakota del Norte.

Ver también

Referencias

enlaces externos

Información sobre estándares de seguridad

Solicitud de comentarios relacionada