Transferencia de zona DNS , AXFR es un tipo de transacción DNS . Es uno de los mecanismos para replicar bases de datos DNS entre servidores. Hay dos tipos de transferencia de zona: completa (AXFR RFC 1035 ) e incremental (IXFR RFC 1995 ). Estaba muy extendido, pero en los servidores modernos el DNS está siendo suplantado por otros mecanismos de replicación.
Una transferencia de zona funciona sobre el protocolo TCP y es una transacción cliente-servidor . Es atendido por un servidor esclavo, o inglés. esclavo , solicitando la transferencia de parte de los datos de la base de datos, y el servidor maestro (también llamado servidor de zona principal), o inglés. maestro que proporciona estos datos. En algunas fuentes se denominan servidores primarios y secundarios, respectivamente. La parte de los datos que se transfieren es la zona DNS.
Esta transacción consta de un preámbulo y la transferencia de datos en sí. Durante el preámbulo, el registro SOA (fuente autorizada) se busca al principio de la zona ( ápice de la zona en inglés ), el nodo superior del espacio de nombres de esta zona. Los campos en este registro SOA, específicamente el número de serie, determinan si se necesita una transferencia de zona. El cliente compara el número de serie del registro SOA recibido con el que ya tiene. Si el nuevo número de entrada es más alto, entonces el contenido de la zona ha cambiado hasta cierto punto y el cliente está solicitando una transferencia de zona real. Si los números de serie son los mismos, el contenido de la zona se considera sin cambios y el cliente puede continuar usando la copia existente de los datos.
Al comienzo de la transferencia de datos real, el cliente envía una solicitud (código de operación 0) de un tipo especial AXFR (QTYPE AXFR = 252) a través de la conexión TCP. El servidor en respuesta envía secuencialmente mensajes con todos los registros de recursos de la zona. El primer mensaje contiene el registro SOA del inicio de la zona. El resto de los mensajes no se ordenan. La señal de fin de transmisión es un reenvío del registro SOA.
Algunos clientes realizan búsquedas SOA a través del mecanismo estándar de resolución de nombres. No establecen una conexión TCP con el servidor hasta que determinan que la transferencia real es necesaria. Sin embargo, dado que TCP se puede usar tanto para transacciones de DNS normales como para transferencias de zona, otros clientes resolverán el registro SOA en el preámbulo a través de la misma conexión que podrían usar para la transferencia real. Dichos clientes establecen una conexión TCP desde el servidor incluso antes de que comience el preámbulo.
Los principios de la transferencia total se describen anteriormente. La transferencia de zona incremental difiere de la siguiente manera:
Solo el cliente inicia una transferencia de zona. Un servidor PUEDE enviar un mensaje de NOTIFICACIÓN a los clientes que conoce cuando ha habido un cambio en la zona, pero la programación de la transmisión depende completamente del cliente. Un cliente puede desencadenar una transferencia de zona si sus bases de datos están vacías y, luego, según un cronograma determinado en función de los campos de actualización, reintento y caducidad en el registro SOA de inicio de zona.
Aunque la transferencia completa está estandarizada y se describe como uno de los posibles mecanismos de replicación en RFC 1034 (transferencia incremental en RFC 1995 ), la transferencia de zona es la forma menos funcional de replicar bases de datos. La transferencia de registros es "no inteligente", es decir, utiliza el mismo protocolo que la resolución de nombres DNS normal. No tiene en cuenta el esquema de base de datos subyacente utilizado por el back-end de los propios servidores DNS.
El preámbulo de transferencia de zona se basa únicamente en el número de serie para determinar si los datos de la zona han cambiado y si se necesita una transferencia real. En algunos servidores DNS, los administradores deben editar manualmente los números de serie de SOA. Cada cambio en la base de datos requiere dos ediciones: el registro en sí y 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 un valor de la forma AAAAMMDDnn (AAAA=año, MM=mes, DD=día, nn=día cambio de versión) como número. Este formato te permite usar un número hasta el año 4294 y hacer 100 cambios por día (nn del 00 al 99), dándote control sobre la última fecha de cambio.
Algunos servidores resuelven este problema calculando automáticamente el número de serie en función de la última fecha de modificación del de en el disco Lo mismo ocurre, en particular, con djbdns . El sistema operativo realiza un seguimiento de la actualización de la fecha de modificación del archivo, esencialmente automatizando el cálculo del número y liberando al administrador de la necesidad de cada segunda edición.
Los servidores modernos con back-end complejos como SQL y Active Directory permiten a los administradores editar varios sitios al mismo tiempo (sistemas con replicación multimaestro ) donde la base de datos subyacente maneja la replicación a otros servidores, sin embargo, esto solo puede funcionar cuando todos los DNS las zonas están bajo control único. Tal modelo no corresponde a un único registro centralizado de cambios monótonamente crecientes y, por lo tanto, generalmente no es compatible con una transferencia de zona. Los servidores DNS modernos con back-end complejos en las bases de datos a menudo crean un número de serie "imaginario", pretendiendo tener una fuente centralizada de actualizaciones, pero esto es al menos imperfecto.
Por estas y otras razones, los servidores DNS con bases de datos complejas rara vez usan transferencias de zona para la replicación, dejando la tarea a mecanismos de bases de datos internas mucho más eficientes.
La comparación de números de serie implica el uso de la aritmética de números de serie (por ejemplo, para evitar el problema del año 2000 ) según RFC 1982 . Sin embargo, esto no se indicó claramente en RFC 1034 y, como resultado, los clientes comparan los números de preámbulo de manera diferente. Algunos solo se aseguran de que el número recibido sea diferente del existente o distinto de cero. Otros comprueban que el número recibido se encuentra dentro de un intervalo determinado del existente. Otros también hacen una verificación de cero.
Inicialmente, cuando se transfirieron datos, cada entrada para cada nombre y tipo de dominio se transfirió del servidor al cliente en un mensaje separado. Esto fue ineficiente y algunos servidores DNS optimizaron el proceso para reducir la sobrecarga de ancho de banda a través de mecanismos de compresión en el protocolo DNS, como:
Algunos clientes esperaban solo el formato de respuesta original y no podían aceptar datos optimizados de esta manera. Con esto en mente, los servidores DNS individuales se configuraron para enviar "respuestas de formato único" a dichos clientes.
La información contenida en una zona DNS puede considerarse confidencial desde el punto de vista de la seguridad operativa. Por ejemplo, los registros de recursos pueden contener información sobre la función del servidor o huellas digitales de claves SSH ( RFC 4255 ).
En 2008, un tribunal de Dakota del Norte, EE. UU., dictaminó que una transferencia no autorizada de un área privada iniciada por un extraño constituía una violación de la ley estatal.