Hispanopedia WikiLa 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 a un servidor primario . [ 3 ] La porción 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 propiamente dicha. El preámbulo incluye una consulta del registro de recursos de Inicio de Autoridad (SOA) para el "ápice de la 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 realizar la transferencia de datos. El cliente compara el número de serie del registro de recursos SOA con el número de serie de la última copia de dicho registro que posee. 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 servidor secundario procede a solicitar la transferencia de datos de la zona. Si los números de serie son idénticos, se considera que los datos de la zona no han "cambiado" y el cliente puede seguir utilizando la copia de la base de datos que ya posee, si dispone de una.
El proceso de transferencia de datos comienza cuando el cliente envía una consulta ( opcode 0) con el tipo de consulta especial AXFR (valor 252) a través de la conexión TCP al servidor. Aunque técnicamente DNS admite AXFR sobre el Protocolo de Datagramas de Usuario (UDP), se considera inaceptable 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 para cada nombre de dominio en la "zona". La primera respuesta comprende el registro de recursos SOA para el ápice de la zona. Los demás datos siguen sin un orden específico. El final de los datos se señala cuando el servidor repite 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 de resolución de consultas DNS habitual de su sistema. Estos clientes no abren una conexión TCP con el servidor hasta que determinan que necesitan realizar la transferencia de datos. Sin embargo, dado que TCP puede utilizarse tanto para transacciones DNS normales como para la transferencia de zona, otros clientes de transferencia de zona realizan la búsqueda SOA del preámbulo a través de la misma conexión TCP a la que posteriormente (y posiblemente) realizan la transferencia de datos. Estos clientes abren la conexión TCP con el servidor incluso antes de realizar la búsqueda del 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 tipo de datos especial QTYPE IXFR (valor 251) en lugar del tipo de datos AXFR.
- El cliente envía el registro de recursos SOA para el ápice de zona que tiene actualmente, si lo tiene, en el mensaje IXFR, informando al servidor qué versión de la "zona" cree que es la actual.
- Aunque el servidor puede responder de la forma habitual mediante AXFR, enviando todos los datos de la zona, también puede optar por una transferencia de datos incremental. Esta última comprende la lista de cambios en los datos de la zona, ordenados por número de serie, entre la versión de la zona que el cliente informó al servidor y la versión actual de la zona en el servidor. Los cambios constan de dos listas: una de registros de recursos eliminados y otra de registros de recursos insertados. (Una modificación en un registro de recursos se representa como una eliminación seguida de una inserción).
La transferencia de zona es iniciada exclusivamente por el cliente. Si bien los servidores pueden enviar un mensaje de notificación a los clientes (de los cuales han sido informados) cuando se produce un cambio en los datos de la zona, la programación de las transferencias de zona está completamente bajo el control de los clientes. Estos programan las transferencias de zona inicialmente, cuando sus bases de datos están vacías, y posteriormente a intervalos regulares, siguiendo un patrón controlado por los valores de los campos "refresh", "retry" y "expire" en el registro de recursos SOA del nodo á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 bases de datos en los RFC 1034 y 5936 (la transferencia de zona incremental se describe en el RFC 1995), siendo la transferencia de zona el mecanismo de replicación de bases de datos más limitado. La transferencia de zona opera con registros de recursos en formato de transmisión , es decir , registros de recursos tal como se transfieren mediante el protocolo DNS. Sin embargo, el esquema de los registros de recursos en formato de transmisión puede no ser idéntico al esquema de base de datos utilizado por los servidores DNS.
Problemas operativos
Cambios en el 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. Para 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 modifica y 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 usar 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 solucionado este problema construyendo automáticamente el número de serie a partir de la marca de tiempo de la última 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 marca de tiempo de la última modificación se actualice cada vez que un administrador edita el archivo de base de datos, actualizando automáticamente el número de serie y, por lo tanto, evitando que los administradores tengan que realizar dos ediciones (en dos lugares diferentes) por cada cambio.
Además, el paradigma de replicación de bases 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 implica un único servidor DNS central que contiene la versión principal de la base de datos y todos los demás servidores DNS que simplemente contienen copias, simplemente no coincide con el de muchos paquetes de servidores DNS modernos. Los paquetes de servidores DNS modernos con sistemas de bases de datos sofisticados, como servidores SQL y Active Directory, permiten a los administradores realizar actualizaciones en la base de datos en múltiples ubicaciones (estos sistemas emplean replicación multimaster ), y el propio mecanismo de replicación del sistema de bases de datos gestiona 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. Los paquetes de servidores DNS modernos con sistemas de bases de datos sofisticados a menudo crean 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 otras razones que se detallan más adelante, los servidores DNS que utilizan sistemas de bases de datos tan sofisticados rara vez utilizan la transferencia de zona como mecanismo de replicación de bases de datos, y suelen emplear los mecanismos de replicación de bases de datos distribuidas, muy superiores, que proporcionan los propios sistemas.
Comparación de números de serie
Las comparaciones de números de serie están diseñadas para utilizar la aritmética de números de serie definida en la RFC 1982. Sin embargo, esto no se especificó claramente en la RFC 1034, lo que provoca que no todos los clientes realicen la comprobación del número de serie, en el preámbulo, de la misma manera. Algunos clientes simplemente comprueban que el número de serie proporcionado por el servidor sea diferente del que conocen, o distinto de cero. Otros clientes comprueban que el número de serie proporcionado por el servidor esté dentro de un rango determinado del número de serie que ya conocen. Otros clientes, además de esta última comprobación, verifican que el número de serie proporcionado por el servidor no sea cero.
Registros de recursos múltiples
Originalmente, en la transferencia de datos real, cada conjunto de registros de recursos para un único 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 programas de servidor DNS implementaron optimizaciones, orientadas a permitir que el mecanismo de compresión de respuesta en el protocolo DNS reduzca los requisitos totales de ancho de banda de las transferencias de datos, tales como:
- realizar un "procesamiento de sección adicional" para incluir cualquier conjunto de registros de recursos "de unión" 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 único nombre de dominio y enviarlos, si caben, en una única respuesta.
Algunos clientes fueron programados para aceptar únicamente el formato de respuesta original y, si se aplicaran optimizaciones, no podrían transferir los datos. Por ello, varios paquetes de servidores DNS incluyen una opción de configuración que permite a los administradores especificar el uso de respuestas en 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 información como los nombres de host de los servidores puede hacerse pública, lo que puede utilizarse para descubrir información sobre una organización e incluso aumentar la superficie de ataque . En junio de 2017, el registrador responsable de los dominios de nivel superior rusos habilitó accidentalmente las transferencias de zonas DNS a través de AXFR, lo que provocó la exposición accidental de 5,6 millones de registros. [ 4 ]
En 2008, un tribunal de Dakota del Norte, EE. UU., dictaminó que realizar una transferencia de zona como un tercero no autorizado para obtener información que no era de acceso público constituye una violación de la ley de Dakota del Norte. [ 5 ]
Véase también
Referencias
- 1 2 "Nombres de dominio: implementación y especificación" . IETF . Noviembre de 1987.
- 1 2 Dickinson, John; Dickinson, Sara; Bellis, Ray; Mankin, Allison; Wessels, Duane (marzo de 2016). "Transporte DNS sobre TCP: requisitos de implementación" . IETF .
- ↑ Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul (2019). "Terminología DNS" . tools.ietf.org . doi : 10.17487/RFC8499 . Recuperado el 21 de junio de 2020 .
- ↑ "Una configuración de enlace incorrecta expone la lista completa de TLD rusos a Internet" . Blog de SecurityTrails . 14 de marzo de 2018. Consultado el 10 de abril de 2018 .
- ↑ "Multan a un defensor contra el spam por acceder a los registros DNS de una red privada" . The H. 18 de enero de 2008.
- "Cómo funciona el protocolo AXFR" . Publicación en Internet, DJ Bernstein . Consultado el 15 de febrero de 2005 .
- "Comprensión de las zonas y la transferencia de zonas" . Documentación del producto Microsoft Windows Server 2003. 8 de octubre de 2009. Consultado el 27 de noviembre de 2011 .
- "Cómo funciona la compatibilidad con DNS para Active Directory" . Documentación del producto Microsoft Windows Server 2003. Consultado el 27 de noviembre de 2011 .
- "Replicación de zona DNS en Active Directory" . Documentación del producto Microsoft Windows Server 2003. 8 de octubre de 2009. Consultado el 27 de noviembre de 2011 .
- McClure, Stuart; Scambray, Joel; Kurtz, George (2009). Hacking al descubierto: Secretos y soluciones de seguridad de redes (6.ª ed.). McGraw-Hill. ISBN 978-0-07-161374-3.
Enlaces externos
Información sobre estándares de seguridad
- Transferencias de zona DNS CAPEC-291
- CVE-1999-0532 Un servidor DNS permite transferencias de zona.
- Configuración CWE-16
- CWE-276 Permisos predeterminados incorrectos
Solicitud de comentarios relacionada
- RFC 5936 Protocolo de transferencia de zona DNS (define AXFR, actualiza RFC 1034 Nombres de dominio: conceptos y funcionalidades, y RFC 1035 Nombres de dominio: implementación y especificación)
- RFC 1995 Transferencia incremental de zona en DNS
- RFC 1996 Mecanismo para la notificación inmediata de cambios de zona (DNS NOTIFY)
- borrador-ietf-dnsext-axfr-clarify Protocolo de transferencia de zona DNS (AXFR) Borrador de Internet
- Sistema de nombres de dominio