Transferencia de zona DNS

Transferencia de zona DNS, a veces, también conocido por el tipo de consulta DNS induciendo AXFR, es un tipo de DNS transacción. Es uno de los muchos mecanismos disponibles para los administradores replicar Bases de datos de DNS a través de un conjunto de Servidores DNS. Las transferencias de zona pueden realizarse mediante dos métodos, AXFR completo y IXFR incremental.

Operación

Una transferencia de zona utiliza el Transmission Control Protocol (TCP) para el transporte y toma la forma de un cliente – servidor transacción. El cliente solicita una transferencia de zona puede ser un servidor esclavo o servidor secundario, solicitar datos de un servidor maestro, a veces llamado un servidor principal. La porción de la base de datos que se replica es un zona.

Transferencia de zona consta de un preámbulo, seguido de la transferencia de datos reales. El preámbulo compone de una búsqueda de la Principio de autoridad Registro de recursos (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 "serial number", determinan si la transferencia de datos real necesita ocurrir en absoluto. 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 transferido es mayor, los datos de la zona se considerarán que han "cambiado" (de alguna manera) y el esclavo procede a solicitar la transferencia de datos reales de la zona. Si los números de serie son idénticos, se considerarán que los datos en la zona no han "cambiado", y el cliente podrá continuar utilizando la copia de la base de datos que ya tiene, si tiene uno.

Comienza el proceso de transferencia de datos reales por el cliente envía una consulta (opcode 0) con el tipo de consulta especial AXFR (valor 252) sobre la conexión TCP al servidor. El servidor responde con una serie de mensajes de respuesta, que abarca todos los registros de recurso 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 sigue sin un orden especificado. Al final de los datos es señalado por el servidor repetir la respuesta que contiene el registro de recursos SOA para el ápice de la zona.

Algunos clientes de transferencia de zona efectuar la búsqueda SOA del preámbulo mediante el mecanismo de resolución de su sistema normal DNS query. Estos clientes no abra una conexión TCP con el servidor hasta que ellos han determinado que necesitan para llevar a cabo la transferencia de datos reales. Sin embargo, dado que TCP puede ser utilizado para las transacciones normales de DNS, así como para la transferencia de zona, otros clientes de transferencia de zona realizan el preámbulo de la búsqueda SOA en la misma conexión TCP como entonces (mayo) realizar la transferencia de datos reales. Estos clientes abren la conexión TCP con el servidor antes de que incluso realizan el preámbulo.

Lo anterior describe la transferencia de zona completa. Transferencia de zona incremental difiere de transferencia de zona completa en los siguientes aspectos:

• El cliente utiliza el especial QTYPE IXFR (valor de 251) en lugar del AXFR QTYPE.
• El cliente envía el registro de recursos SOA para el ápice de la zona que tiene actualmente, si los hubiere, en el mensaje IXFR, el servidor a saber qué versión de la "zona" cree para estar al corriente.
• Aunque el servidor puede responder de la manera normal AXFR con los datos completos de la zona, también en su lugar puede responder con una transferencia de datos "incrementales". Este último incluye la lista de cambios a los datos de la zona, en orden de número de serie de zona, entre la versión de la zona que el cliente informó al servidor como teniendo y la versión de la zona que es actual en el servidor. Los cambios abarcan dos listas, uno de los registros de recursos que se borran y uno de los registros de recursos que se insertan. (Una modificación de un registro de recursos es representada como una eliminación seguida de una inserción.)

Transferencia de zona está completamente iniciados. Aunque servidores pueden enviar un mensaje de notificar a los clientes (que haber sido informado sobre) cada vez que un cambio en la zona de datos se ha hecho, la programación de las transferencias de zona es enteramente bajo el control de los clientes. Los clientes de las transferencias de zona de horario inicialmente, cuando sus bases de datos están vacías y posteriormente a intervalos regulares, en un patrón controlado por los valores de la "actualización", "reintentar" y "caducan" campos en el registro de recursos SOA de la cúspide de la zona.

Limitaciones

Aunque es estandarizada, zona completa transferencia ha descrito como uno de los mecanismos de replicación de bases de datos posibles en RFC 1034 y RFC 5936 (transferencia de zona incremental se describe en RFC 1995), transferencia de zona es la más limitada de esos mecanismos de replicación de base de datos. Transferencia de zona opera en términos de"formato de alambre"los registros de recursos, es decir registros de recursos como son transferidos usando el protocolo DNS. Sin embargo, el esquema de registros de recursos de formato de alambre puede no coincidir con el esquema de base de datos utilizado por el back-ends de los servidores DNS.

Problemas operacionales

Cambia de número de serie

La porción del preámbulo de la transferencia de zona se basa en el número de serie y Sólo el número de serie, para determinar si han cambiado los datos de una zona, y por lo tanto si se requiere la transferencia de datos reales. Para algunos paquetes de servidor DNS, los números de serie de registros de recursos SOA son mantenidos por los administradores a mano. Cada edición a la base de datos consiste en hacer dos cambios, uno para el registro se cambia y la otra para el número de serie de la zona. Este es un proceso laborioso y uno que es propenso a errores, con los administradores de olvido cambiar un número de serie o cambiar un número de serie incorrectamente (como disminuirlo o aumentarlo por una gran cantidad).

Algunos paquetes de servidor DNS han superado este problema construyendo automáticamente el número de serie de la fecha y hora última modificación del archivo de base de datos en disco. Este es el caso de djbdns, por ejemplo. El sistema operativo se asegura que la última modificación timestamp se actualiza cada vez que un administrador edita el archivo de base de datos, actualización efectivamente automáticamente el número de serie y aliviando así los administradores de la necesidad de realizar dos ediciones (en dos lugares diferentes) para cada cambio individual.

Además, se diseña el paradigma de la replicación de base de datos para que la serie número cheque (y zona de hecho transferencia de sí mismo), que consiste en un único servidor DNS central sostiene la versión principal de la base de datos con todos los demás servidores DNS simplemente manteniendo copias, simplemente no coincide con la de muchos paquetes de servidor DNS modernos. Paquetes de servidor DNS modernos con sofisticada base de datos back-ends tales como SQL los servidores y Active Directory permiten a los administradores realizar actualizaciones a la base de datos en múltiples lugares (emplean tales sistemas Replicación de múltiples maestra), con la base de datos de nuevo mecanismo de replicación de final manejo la replicación en todos los otros servidores. Este paradigma simplemente no coincide que de una sola central, monótonamente creciente número para registrar cambia y por lo tanto es incompatible con la transferencia de zona en gran parte. Paquetes de servidor DNS modernos con sofisticada base de datos back-ends a menudo creará un número de serie "calza", simulando la existencia de un solo lugar central donde se realizan las actualizaciones, pero esto es al mejor imperfecto.

Afortunadamente, por ésta y varias razones descritas más adelante, los servidores DNS que usan tan sofisticada base de datos de vuelta termina en general raramente transferencia de zona de uso como su mecanismo de replicación de bases de datos en primer lugar y generalmente en su lugar emplean proporcionan los mecanismos de replicación de bases de datos distribuidas ampliamente superior que se termina la parte de atrás.

Comparaciones de número de serie

Las comparaciones de número de serie están diseñadas para su uso Número de serie aritmética tal como se define en RFC 1982. Sin embargo, esto no claramente se especificó en RFC 1034, dando lugar a no todos los clientes realizar la comprobación del número de serie, en el preámbulo, de la misma manera. Algunos clientes simplemente comprobar que el número de serie proporcionado por el servidor es diferente a la conocida por el cliente, o distinto de cero. Otros clientes verificar el número de serie proporcionado por el servidor dentro de un rango dado el número de serie ya conocido por el cliente. Sin embargo, otros clientes todavía realizan el último cheque y además comprobar que el número de serie proporcionado por el servidor no es cero.

Múltiples registros de recursos

Originalmente, en los datos reales de transferencia cada conjunto de registros de recursos para un nombre de dominio único y tipo fue trasladado en un mensaje de respuesta separada desde el servidor al cliente. Sin embargo, esto es ineficiente, y algún software de servidor DNS implementadas las optimizaciones, destinadas a permitir que el mecanismo de compresión de respuesta en el protocolo DNS para reducir los requerimientos de ancho de banda total de las transferencias de datos, tales como:

• realizar "el procesamiento adicional de la sección" para incluir cualquier "pegamento" registro de recursos se establece en la misma respuesta como un conjunto registro de recursos NS, SRV o MX
• recopilación de todos los registros de recursos conjuntos relativos a un nombre de dominio único juntos y enviarlos, si caben, en una sola respuesta

Algunos clientes se han escrito para esperar Sólo el formato original de la respuesta y fallaría realizar transferencia de datos si se emplearon tales optimizaciones. Varios paquetes de servidor DNS así tienen una configuración permitiendo a los administradores especificar el uso de las respuestas de "formato de respuesta única" para aquellos clientes que lo requieran.

Exposición de los datos

Los datos contenidos en una zona DNS pueden ser sensibles de un aspecto de la seguridad operacional. Esto es debido a información como nombres de servidor puede convertirse en conocimiento público, que puede utilizarse para descubrir información sobre una organización e incluso dar un mayor superficie de ataque.

En 2008, un tribunal en Dakota del norte, Estados Unidos, dictaminó realizar a una transferencia de zona como un extranjero no autorizado para obtener información que no era accesible públicamente constituye una violación de la ley de Dakota del norte.

Información sobre las normas de seguridad

• Transferencias de zona DNS CAPEC-291
• CVE-1999-0532 A DNS server permite que las transferencias de zona.
• Configuración CWE-16
• Permisos predeterminado incorrecto CWE-276

Referencia adicional: Stuart McClure, Joel Scambray, George Kurtz. "Hacking expuestos: Network Security Secrets & Solutions". 6ª edición. McGraw Hill, ISBN 978-0-07-161374-3. 2009

Véase también

• Lista de tipos de registros DNS

Relacionados con las solicitudes de comentarios (RFC)

• RFC 5936 DNS Zone Transfer Protocol (define AXFR, actualizaciones RFC 1034 Los nombres de dominio - conceptos e instalaciones, y RFC 1035 Nombres de dominio - implementación y especificación)
• RFC 1995 Transferencia de zona incremental en DNS
• RFC 1996 Un mecanismo para la pronta notificación de cambios de zona (notificar DNS)
• draft-ietf-dnsext-axfr-aclarar DNS Zone Transfer Protocol (AXFR) borrador de Internet

Referencias

• "Cómo funciona el protocolo AXFR". Publicación en Internet, D. J. Bernstein. 15 de febrero, 2005.
• "Las zonas de comprensión y transferencia de zona". Documentación de producto de Microsoft Windows Server 2003. 27 / 11 / 2011.
• «Cómo DNS apoyo a obras de Active Directory». Documentación de producto de Microsoft Windows Server 2003. 27 / 11 / 2011.
• "Replicación de zona DNS en Active Directory". Documentación de producto de Microsoft Windows Server 2003. 27 / 11 / 2011.

Otras Páginas

• Samsung SGH-F480
• Botcho
• Algoritmo YDS
• Berenson-Eggers tipo de servicio
• Angaliastos
• Castillo de Darrell
• MIRALIA, Iran
• Saddle sore
• Alfombra (cubierta animal)
• Teoria de terreno
• Rajamanohar
• Familia de Javal
• Jim Morton (futbolista)
• Francolinus Finschi
• Hogar nacional Elks