Cambios de número de serieEditar
La parte del preámbulo de la transferencia de zona se basa en el número de serie, y sólo 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. En algunos paquetes de servidores DNS, los administradores mantienen a mano 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). El 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 construyendo automáticamente el número de serie a partir de la última marca de tiempo de modificación del archivo de la base de datos en el disco. Este es el caso de djbdns, por ejemplo. El sistema operativo asegura que la última marca de tiempo de modificación se actualiza cada vez que un administrador edita el archivo de la base de datos, actualizando automáticamente el número de serie, y por lo tanto aliviando a los administradores de la necesidad de hacer 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 la comprobación del número de serie (y de hecho la transferencia de zona en sí misma) está diseñado, que implica un único servidor DNS central que mantiene la versión primaria de la base de datos con todos los otros servidores DNS simplemente manteniendo copias, simplemente no coincide con el de muchos paquetes de servidores DNS modernos. Los paquetes modernos de servidores DNS con sofisticados back-ends de bases de datos, como los servidores SQL y Active Directory, permiten a los administradores realizar actualizaciones de la base de datos en múltiples lugares (estos sistemas emplean la replicación multimaster), y el propio mecanismo de replicación de la base de datos gestiona la replicación a todos los demás servidores. Este paradigma simplemente no coincide con el de un número único, central y monótonamente creciente para registrar los cambios, y por lo tanto es incompatible con la transferencia de zonas en gran medida. Los paquetes modernos de servidores DNS con sofisticadas bases de datos 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 esto y por varias razones que se exponen más adelante, los servidores DNS que utilizan estos sofisticados back-ends de bases de datos en general rara vez utilizan la transferencia de zona como su mecanismo de replicación de la base de datos en primer lugar, y por lo general emplean los mecanismos de replicación de la base de datos distribuida muy superiores que los propios back-ends proporcionan.
Las comparaciones de números de serieEditar
Las comparaciones de números de serie están destinadas a utilizar la Aritmética de Números de Serie como se define en el RFC 1982. Sin embargo, esto no se especificó claramente en el RFC 1034, por lo que no todos los clientes realizan la comprobación del número de serie, en el preámbulo, de la misma manera. Algunos clientes comprueban simplemente que el número de serie suministrado por el servidor es diferente del conocido por el cliente, o distinto de cero. Otros clientes comprueban que el número de serie suministrado por el servidor está dentro de un rango determinado del número de serie ya conocido por el cliente. Otros clientes aún realizan esta última comprobación y comprueban adicionalmente que el número de serie suministrado por el servidor no sea cero.
Múltiples registros de recursosEditar
Originalmente, en la transferencia de datos real cada conjunto de registros de recursos para un solo nombre de dominio y tipo 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 «pegados» en la misma respuesta que un conjunto de registros de recursos NS, SRV o MX
- recopilar todos los conjuntos de registros de recursos relativos a un solo nombre de dominio juntos y enviarlos, si caben, en una sola respuesta
Algunos clientes se escribieron para esperar sólo el formato de respuesta original, y no realizarían la transferencia de datos si se emplearan tales optimizaciones. Por ello, varios paquetes de servidores DNS disponen de un ajuste 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 datosEditar
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 pueden pasar a ser de dominio público, lo que puede ser utilizado 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.
En 2008, un tribunal de Dakota del Norte (EE. UU.) dictaminó que realizar una transferencia de zona como persona ajena no autorizada para obtener información que no era de acceso público constituye una violación de la ley de Dakota del Norte.