ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Transferencia de zona DNS wiki: info, historia y vídeos


La información contenida en esta web debe ser considerada como información general, de carácter formativo, educativo o divulgativo, y no puede ser utilizada o interpretada como consejo o diagnótico médico, psicológico o de ningún otro tipo. Es posible que algunos datos mostrados no esten actualizados. Por ello, en caso de duda lo recomentable es consultar a un experto cualificado.


 


 

videos internet

salud  Transferencia de zona DNS 


Una trasferencia de zona usa el protocolo TCP para el transporte, y toma la manera de una transacción de usuario-servidor. El usuario que pide una trasferencia de zona puede ser un servidor esclavo o bien servidor secundario, que pide datos de un servidor profesor, en ocasiones llamado un servidor primario. La una parte de la base de datos que se contesta es una zona.


La trasferencia de zona entiende un preámbulo seguido de la trasferencia de datos misma. El preámbulo entiende una busca de la SOA (Start of Authority) registro de recursos para la "zona ápice", el nodo del espacio de nombres DNS que se halla en la parte superior de la "zona". Los campos de este registro de recursos SOA, particularmente, el "número de serie", determinan si la trasferencia de datos precisa suceder o bien no. El cliente del servicio equipara 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 es transferido es mayor, los datos en la zona se cree que han "alterado" (de alguna forma) y el esclavo procede a pedir la trasferencia real de datos de zona. Si los números de serie son idénticos, los datos en la zona se estimará que no ha "alterado", y el cliente del servicio puede continuar usando la copia de la base de datos que tiene, si tiene una.


El proceso de trasferencia de datos real empieza por el usuario de mandar una consulta (opcode 0) con el QTYPE singular (género de consulta) AXFR (valor doscientos cincuenta y dos) por medio de la conexión TCP con el servidor. El servidor responde con una serie de mensajes de contestación, que entiende todos y cada uno de los registros de recursos para cada nombre de dominio en la "zona". La primera contestación entiende el registro de recursos SOA de la zona ápice. Los otros datos prosiguen sin un orden determinado. El final de los datos es señalado por el servidor de repitiendo la contestación que contiene el registro de recursos SOA para la zona de ápice.


Algunos clientes del servicio de trasferencia de zona efectúan la busca de SOA de el preámbulo usando el mecanismo normal de resolución de consultas DNS de su sistema. Estos clientes del servicio no abren una conexión TCP con el servidor hasta el momento en que hayan determinado que precisan realizar la trasferencia de datos. No obstante, puesto que TCP puede ser empleado para las transacciones de DNS normales, de este modo para la trasferencia de zona, otros clientes del servicio de trasferencia de zona efectúan la busca preámbulo SOA sobre exactamente la misma conexión TCP, en tanto que ahora (pueden) efectuar la trasferencia de datos real. Estos clientes del servicio abren la conexión TCP con el servidor antes que aun efectúan el preámbulo.


Lo precedente describe la trasferencia de zona completa. Trasferencia de zona incremental difiere de trasferencia de zona completa en los próximos aspectos:





  • Los usuario emplea el QTYPE IXFR singular (valor doscientos cincuenta y uno) en vez del AXFR QTYPE.
  • Los usuario manda el registro de recursos SOA de la zona ápice que hoy en día cuenta, en su caso, en el mensaje IXFR, dejando que el servidor saber qué versión de la "zona" que piensa que es actual.
  • Aunque el servidor puede contestar de la forma normal AXFR con los datos completos de la zona, asimismo puede contestar con un sitio de trasferencia de datos "incrementales". Este último entiende la lista de cambios en los datos de zona, en la zona para el número de serie, entre la versión de la zona que el cliente del servicio notifica al servidor como que tiene y la versión de la zona que es actual en el servidor. Los cambios entienden 2 listas, una de los registros de recursos que se suprime y uno de los registros de recursos que se introducen. (Una modificación de un registro de recurso se representa como una supresión seguido por una inserción.)

La trasferencia de zona es completamente iniciada por el cliente del servicio. Si bien los servidores pueden mandar un mensaje NOTIFICACIÓN (NOTIFY) a los clientes del servicio (que se les ha informado sobre) toda vez que se ha efectuado un cambio en los datos de zona, la programación de las trasferencias de zona está plenamente bajo el control de los clientes del servicio. Los clientes del servicio programan las trasferencias de zona en un comienzo, cuando sus bases de datos están vacíos, y más tarde a intervalos regulares, en un patrón controlado por los valores en los campos "refrescar", "reintentar", y "caducar" en el registro de recursos SOA de la zona ápice.


A pesar de que está estandarizado, la trasferencia de zona completa que se describe como uno de los posibles mecanismos de replicación de bases de datos en el RFC mil treinta y cuatro y RFC cinco mil novecientos treinta y seis (trasferencia de zona incremental se describe en el RFC mil novecientos noventa y cinco), la trasferencia de zona es el más limitado de los mecanismos de replicación de bases de datos. La trasferencia de zonas opera en concepto de "Formato de cable" de los registros de recursos, en tanto que se trasfieren a través de el protocolo DNS. No obstante, el esquema de los registros de recursos transferidos puede no coincidir con el esquema de base de datos usado por los extremos siguientes de los propios servidores DNS.


Cambios de números seriales


El preámbulo de la trasferencia de la zona se fundamenta en el número de serie, y solo el número de serie, para determinar si los datos de una zona han alterado, y por consiguiente, si se requiere la trasferencia de datos pedida. Para ciertas implementaciones de servidores DNS, los números de serie de los registros de recursos SOA son mantenidos por los administradores a mano. Cada edición de la base de datos consiste en efectuar 2 cambios, uno para el registro que se cambia y el otro para el número de serie de la zona. Este es un proceso trabajoso y que es propenso a fallo, así sea con los administradores olvidándose de mudar un número de serie o bien mudando un número de serie incorrectamente (como la minoración o bien el incremento por un sinnúmero).


Algunas implementaciones de servidores DNS han superado este inconveniente edificando de manera automática el número de serie desde la última data y hora de modificación del fichero de base de datos en el disco. Este es el caso de djbdns, por poner un ejemplo.El sistema operativo se cerciora de que la última hora de modificación se actualiza toda vez que un administrador edita el fichero de base de datos, de forma eficaz la actualización automáticamente el número de serie, y por tanto calmando los administradores de la necesidad de hacer 2 ediciones (en 2 lugares diferentes) para cada cambio.


Por otra parte, el paradigma de la replicación de bases de datos a fin de que la comprobación de número de serie (y en verdad la propia de trasferencia de zona) se diseñó, lo que implica un solo servidor central DNS sosteniendo la versión profesora de la base de datos con todos los otros servidores DNS sencillamente conteniendo copias, sencillamente no coincide la de muchos bultos de servidores DNS modernos. Los bultos modernos de servidor DNS con servicios de back-end de base de datos complejas, como servidores SQL y Active Directory dejan a los administradores efectuar cambios a la base de datos en múltiples lugares (semejantes sistemas emplean replicación multi-profesor), con el propio mecanismo de replicación del back-end de la base de datos manejando la replicación a todos otros servidores. Este paradigma sencillamente no coincide con el de un solo, centralizado y monótonamente creciente número para registrar los cambios, y por tanto es incompatible con trasferencia de zona en buena medida. Los bultos de modernos de esta clase con frecuencia crean un número de serie "cuña", que simula la existencia de un solo sitio central donde se hacen cambios, mas esto es en el mejor caso, imperfecto.


Afortunadamente, por esta y muchas razones esbozadas más adelante, los servidores DNS que emplean semejantes bases de datos complejas raras veces emplean la trasferencia de zona como su mecanismo de replicación de bases de datos en el primer sitio, y en general emplean en su sitio mecanismos de replicación de bases de datos superiores distribuidos que los extremos traseros dan por sí solos.


Comparaciones de número de serie


Las comparaciones de número de serie están destinadas a usar la aritmética de número de serie como se define en el RFC mil novecientos ochenta y dos. No obstante, esto no fue meridianamente detallados en el RFC mil treinta y cuatro, lo que resulta en que no todos y cada uno de los clientes del servicio efectúan la verificación del número de serie, en el preámbulo, del mismo modo. Ciertos clientes del servicio sencillamente verifican que el número de serie proporcionado por el servidor es diferente al conocido por el usuario, o bien diferente de cero. Otros clientes del servicio verifican que el número de serie proporcionado por el servidor esté en un rango dado del número de serie ya conocido por el cliente del servicio. No obstante, otros clientes del servicio aún efectúan esta última comprobación y, además de esto, revisar que el número de serie suministrado por el servidor no es cero. Exiten múltiples casos donde todavía siguiendo bien esta regla, únicamente validar los números de serie hace que el cliente del servicio no advierta que precisa una actualización.


Registros de recursos múltiples


Originalmente, en la trasferencia de datos misma se trasfirió cada conjunto de registros de recursos para un solo nombre de dominio y el tipo en un mensaje de contestación independiente del servidor al cliente del servicio. No obstante, esto es ineficiente, y ciertas optimizaciones incorporadas de software de servidor de DNS, orientadas a dejar que el mecanismo de compresión contestación en el protocolo DNS para reducir los requisitos de ancho de banda total de las trasferencias de datos, semejantes como:



  • Ejecutando "un procesamiento de sección auxiliar" para "pegar" conjuntos de registros de recursos en exactamente la misma contestación como, SRV, MX o bien NS.
  • recogida de todos y cada uno de los conjuntos de registros de recursos relacionados con un solo nombre de dominio y mandarles a, si corresponde, en una contestación.

Algunos clientes del servicio fueron escritos para aguardar solo el formato de contestación original, y fallarían en realizar la trasferencia de datos si se emplean semejantes optimizaciones. De esta manera, múltiples bultos de servidores DNS tienen una alternativa de configuración que deja a los administradores concretar el empleo de contestaciones "de formato de contestación única" para aquellos clientes del servicio que de esta forma lo requieran.


La exposición de datos


Los datos contenidos en una zona DNS pueden ser sensibles desde un aspecto de la seguridad operacional. Esto es por el hecho de que la información tal y como nombres de host de servidor puede ser de conocimiento público, lo que se puede emplear para descubrir información sobre una organización e inclusive suministrar una superficie de ataque más grande.


En dos mil ocho un tribunal de Dakota del Norte, EE.UU., decretó que la realización de una trasferencia de zona por un extraño no autorizado para conseguir información que no era alcanzable al público forma una violación de la ley de Dakota del Norte.


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 





Está aquí: Inicio > [ INTERNET ] > ıllı Transferencia de zona DNS wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas