¿Qué es la autenticación de firma DNS?
Corrección: La pregunta debería ser sobre el protocolo DNS. La siguiente es una introducción específica al protocolo DNS:
DNS es la abreviatura de Domain Name System (Sistema de nombres de dominio), que se utiliza para nombrar computadoras y servicios de red organizados en jerarquías de dominio. Un nombre de dominio se compone de una cadena de palabras o abreviaturas separadas por puntos. Cada nombre de dominio corresponde a una dirección IP única. Existe una correspondencia uno a uno entre los nombres de dominio y las direcciones IP en Internet. realiza la resolución de nombres de dominio. La denominación DNS se utiliza en redes TCP/IP, como Internet, para buscar computadoras y servicios mediante nombres fáciles de usar. DNS es un servicio central de Internet, que sirve como una base de datos distribuida que puede asignar nombres de dominio y direcciones IP entre sí.
Problemas técnicos:
Hay cuatro partes para describir los datos de una zona: los datos de autenticación de todos los nodos en la zona definen los datos del nodo superior en la zona (este Los datos se pueden considerar como parte de autenticación de los datos) que describe los datos que representan la subregión. Acceda a los datos de la subregión del servidor (también los llamamos datos "pegantes"). Todos estos datos se representan en forma de RR. se puede configurar mediante la descripción del formato. Al transmitir RR, se puede transmitir toda la zona. El método específico puede ser transmitir el archivo de texto correspondiente a través de FTP o mediante transmisión de mensajes de red. Los datos de autenticación de una zona son todos RR. Estos RR están asociados con todos los nodos en el árbol o están asociados con los nodos después de la segmentación. El RR que describe el nodo superior es particularmente importante para la gestión de la zona. Hay dos tipos de estos RR, el RR del servidor de nombres, que describe la lista de servidores en la zona y el otro es SOARR, que describe los parámetros de gestión del; zona.
El RR que describe la división es NSRR, porque la división se realiza entre nodos y todos los RR no son parte de los datos de autenticación de la zona. Debe ser coherente con el nodo superior correspondiente en la subzona. Debido a que los servidores de nombres generalmente están asociados con límites de zona, NSRR solo está disponible en el vértice de algunas zonas. En los datos que componen una región, la NSRR ocurre en los nodos de nivel superior y se divide en la parte inferior del límite, pero no en otros lugares.
Uno de los objetivos de la estructura de zonas es que cualquier zona tenga suficientes datos para establecer comunicación con cualquier subzona. Es decir, la zona principal tiene suficiente información para acceder a cualquier servidor de nombres en la zona secundaria. NSRR nombra el servidor de subzona, lo cual no es suficiente para completar los requisitos anteriores, por lo que tiene un nombre pero aún no conoce la dirección. En particular, si el nombre del servidor de nombres está dentro de la subzona, no tenemos forma de saber qué pasa a través de ella. Para solucionar este problema, la zona incluye un RR asociado, que no forma parte de los datos de la autoridad de autenticación, pero que representa la dirección del servidor. Estos RR son necesarios si el nombre del servidor de nombres está fragmentado.
Problemas de gestión:
Cuando algunas organizaciones quieren tomar el control de su propio dominio, el primer paso es marcar la zona principal adecuada y luego obtener permiso del nodo de gestión en el dominio principal. zona para gestionarlo. No hay cuestiones técnicas específicas en la gestión, pero todavía existen algunas reglas. Los distritos medianos no necesitan estas regulaciones, pero los pequeños no. Este artículo no discutirá este tema en detalle. Si está interesado, puede consultar la información relevante.
Una vez que se selecciona un nombre para una subzona, el nuevo nodo de administración para esta zona requiere servidores de nombres redundantes para admitirlo. Nota: No existe ningún requisito de que los servidores de una zona deban estar en hosts nombrados en el dominio. En muchos casos, es mejor distribuir el contenido fuera de una sección en lugar de agruparlo para que sea más fácilmente accesible. Hoy en día, los servidores de nombres de muchos países se ubican en otros países, de modo que al obtener la resolución de nombres, la solicitud no tiene que enviarse completamente al host remoto. Como último paso de la configuración, debe seleccionar NSRR y el RR asociado.
Servidor de nombres en profundidad 1. Consulta y respuesta
Servidor de nombres en profundidad
El contenido principal del servidor de nombres es responder a consultas estándar. Las consultas y respuestas tienen un formato dedicado. Las consultas incluyen QTYPE, QCLASS y QNAME, que describen el tipo, clase y nombre de los datos requeridos.
La respuesta del servidor depende de si admite consultas en bucle:
La más simple es que no admite consultas en bucle. Devuelve información local o un código de error, indicando al usuario que la información que desea no está. disponible aquí y luego devuelve la dirección de un servidor cercano para que el usuario pueda verificarlo allí.
Si se admite la consulta en bucle, si el servidor de nombres no puede encontrar la información correspondiente localmente, consultará a otros servidores en nombre del usuario. En este momento, desempeñará el papel de resolutor en nombre. del usuario hasta que se obtenga el resultado final (o puede que no haya ningún resultado, entonces se devuelve un error) y se devuelve al usuario.
El uso de consultas en bucle requiere soporte tanto del cliente como del servidor. Esta información se intercambia a través de dos bits en la consulta y la respuesta:
Si se permiten consultas en bucle, se establece el bit RA. El servidor puede configurar este bit directamente independientemente de si el cliente realiza una solicitud.
Consulta Si se solicita una consulta circular, el bit RD está configurado. El cliente solo puede realizar una solicitud de consulta circular después de saber que el servidor admite consultas circulares.
El cliente puede configurar tanto RA como. Bits RD en la respuesta para confirmar si se admite la consulta circular. Tenga en cuenta: el servidor no realizará una consulta de bucle por sí solo cuando el cliente no especifique el bit RD.
Si se solicita una consulta en bucle y también se admite la consulta en bucle, la respuesta a la consulta será una de las siguientes:
¿Consultar cuántos alias tiene el CNAMERR especificado?
p>
El servidor de nombres especificado no existe
Error temporal
Si no se solicitó o no se admite la consulta por turnos, la respuesta PUEDE ser:
-Autoridad Certificada El servidor indica que el nombre no existe
-Error temporal
Además se proporcionará cierta información para indicar si el RR que se está consultando proviene de una zona o si está almacenado en caché otro tipo de información. Especificar un servidor de nombres indica que hay otro servidor con el mismo registro que está más cerca del antepasado del nombre que se está consultando.
2. Algoritmo
El algoritmo utilizado por el servidor de nombres está relacionado con el sistema operativo local y la estructura de datos. El siguiente algoritmo supone que RR está organizado en varias estructuras de árbol y una. El árbol es una zona.
3. Usar formato de protocolo
DNS utiliza el protocolo TCP cuando se realiza la transferencia de zona y el protocolo UDP en otros momentos;
Las especificaciones de DNS estipulan 2. Hay dos tipos. De los servidores DNS, uno se llama servidor DNS primario y el otro se llama servidor DNS secundario. En una zona, el servidor DNS primario lee la información de datos DNS de la zona desde su propio archivo de datos, mientras que el servidor DNS secundario lee la información de datos DNS de la zona desde el servidor DNS primario de la zona. Cuando se inicia un servidor DNS secundario, necesita comunicarse con el servidor DNS primario y cargar información de datos. Esto se denomina transferencia de zona.
¿Por qué utilizar tanto TCP como UDP?
Primero, comprenda los límites de longitud de los bytes de transmisión TCP y UDP:
La longitud máxima de los mensajes UDP es 512 bytes, mientras que TCP permite que la longitud de los mensajes supere los 512 bytes. Cuando la consulta DNS supera los 512 bytes, el indicador TC del protocolo aparece con una marca de eliminación y se utiliza TCP para enviarlo. Por lo general, los mensajes UDP tradicionales no suelen tener más de 512 bytes.