En general, para obtener la definición más autorizada y completa de DNS, consulte el documento RFC, aquí . Sin embargo, este artículo no es una documentación completa de DNS, comienza con un ejemplo de uso, utiliza wireshark para analizar y presentar una solicitud de DNS específica e introduce el significado de algunos de los campos más comunes en DNS.
La aparición de los nombres de dominio es para facilitar que las personas recuerden las direcciones de los servicios públicos en la red, por lo que los nombres de dominio generalmente se representan mediante cadenas con significados específicos, como csdn.net. Sin embargo, la identificación del host en el espacio de la red es la dirección IP, y la dirección IP se divide en IPv4 e IPv6, como 192.168.0.1. El uso de números para representar direcciones es amigable con las máquinas y facilita operaciones como el almacenamiento y el direccionamiento. Lo que los humanos recuerdan es el nombre del dominio, lo que la máquina recuerda es la dirección IP.Para completar la interacción entre el hombre y la máquina, apareció el DNS. El nombre completo de DNS se denomina sistema de nombres de dominio, y la esencia de DNS es la tabla de asignación del nombre de dominio a la IP. Por supuesto, es fácil construir esta mesa, pero cómo hacer un buen uso de esta mesa en el ciberespacio requiere la cooperación de software y hardware. El software aquí se refiere a lo que solemos llamar el protocolo DNS, y el hardware aquí son los diversos servidores DNS que existen en el espacio de la red.
Ejemplo de DNS
Las solicitudes de DNS son muy simples en términos de lógica comercial, como se muestra en la Figura 1 a continuación:
Figura 1
- La dirección de origen 192.168.0.103 inicia una solicitud de DNS a la dirección de destino 192.168.0.1.
- 192.168.0.1 respondió a la dirección IP correspondiente al nombre de dominio p3p.sogou.com.
Entre ellos, 192.168.0.103 es el cliente que solicita la resolución, 192.168.0.1 es la dirección del servidor DNS local y hay varias direcciones IP correspondientes al nombre de dominio p3p.sogou.com, incluidas varias direcciones IP como 49.7.176.34 y 49.7 .176.60. Lo anterior es una descripción de toda la lógica comercial de DNS, y el análisis de los campos de solicitud y respuesta es el siguiente.
Ya sea un mensaje de solicitud de DNS o un mensaje de respuesta, la estructura general del mensaje de DNS en RFC1035 se muestra en la Figura 2: Figura
2
La parte del encabezado está disponible para cada mensaje DNS.De acuerdo con la diferencia del encabezado, la estructura de contenido de la solicitud y respuesta DNS es diferente.
encabezado DNS
La estructura del encabezado es como se muestra en la Figura 3:
Figura 3
En la Figura 4 se muestra un ejemplo del encabezado de solicitud correspondiente a la Figura 1:
Figura 4
En la Figura 5 se muestra un ejemplo del encabezado de respuesta correspondiente a la Figura 2:
Figura 5
Ya sea que el ID de la transacción
sea para TCP o UDP, un flujo puede transportar múltiples solicitudes y respuestas. Por lo tanto, para distinguir la solicitud y el par correspondiente que aparece en un flujo, las dos partes en la comunicación usan el ID de transacción para distinguir en la capa de aplicación, lo que se denomina interacción de transacción. Se puede ver que la Figura 4 y la Figura 5 usan el mismo ID de transacción para representar este conjunto de solicitudes y respuestas.
código QR
- El significado de cada bit subsiguiente en el campo QR es diferente según la diferencia del primer bit. Si el primer indicador es 0, significa que se trata de una solicitud de DNS, como se muestra en la Figura 4. Si el primer indicador es 1, significa que se trata de una respuesta de DNS, como se muestra en la Figura 5.
El campo OPCODE
utiliza un total de 4 bits para representar. 0 significa una solicitud de DNS estándar. 1 significa solicitud de DNS inverso, generalmente DNS solicita IP a través del nombre de dominio, y DNS inverso significa que solicita el nombre de dominio a través de IP. Sin embargo, cuando se usa nslookup para realizar una solicitud de DNS inverso, el valor de este campo sigue siendo 0 y el campo de tipo de la solicitud se usa para indicar el DNS inverso, como se muestra en la figura 6. Un OPCODE de 2 indica el estado del servidor de solicitudes. OPCODE3-15 están reservados para su uso.
Figura 6
AA
AA es Respuesta autorizada, lo que significa una respuesta autorizada. Cuando el servidor que responde no es el servidor DNS establecido durante el registro del nombre de dominio, el valor de la respuesta DNS es 0, como se muestra en la Figura 5. Cuando el servidor que responde es el servidor DNS especificado durante el registro del nombre de dominio, el valor es 1. Este campo se utiliza para recordar que puede haber problemas en la respuesta del servidor de resolución de DNS designado no registrado.
Debido a la limitación de la capa portadora de IP en TC
, cuando el mensaje de la capa superior es demasiado grande, se producirá una transmisión fragmentada.La capa de aplicación DNS utiliza esta bandera para indicar si el mensaje DNS está truncado. 0 significa que es un mensaje DNS completo, 1 significa que se produce un truncamiento, como se muestra en la Figura 4/5.
RD
Recursion deseada, el método de consulta de DNS incluye consulta recursiva y consulta iterativa. El bit indicador es 1 para solicitar al servidor DNS que utilice consulta recursiva y 0 para indicar que el cliente utiliza consulta iterativa. La consulta recursiva es más común, como se muestra en la Figura 4/5 que se muestra. Los dos métodos de consulta se presentarán por separado.
RA
Este campo es significativo en la respuesta DNS. Cuando es 1, significa que el servidor admite consultas recursivas, como se muestra en la Figura 5 anterior.
Z
está reservado para la planificación futura, como se muestra en la Figura 4/5.
AD
tiene 3 Z bits reservados en la Figura 3, pero en la Figura 4/5, Z solo ocupa 1 bit. Esto se debe a que el RFC1035 se redactó en 1987, es muy antiguo y ha sufrido muchas revisiones durante el período, como se muestra en la Figura 7 a continuación:
Figura 7
El campo reservado se revisó en RFC2535, como se muestra en la Figura 8 a continuación: Por lo tanto, la Figura
8
significa que AD indica si los datos de respuesta han sido autenticados por el servidor DNS, y esta bandera tiene un significado real en la respuesta, como se muestra en la Figura 5 .
CD
indica si los datos que no han sido autenticados por el servidor son aceptables, 0 indica inaceptable, 1 indica aceptable, como se muestra en la Figura 4/5.
RCODE
Código de respuesta, un código de respuesta de 4 dígitos, utilizado para indicar posibles errores en el servidor. 0 significa que no hay ningún error, 1 significa que el formato de solicitud de DNS es incorrecto o que el servidor no puede analizar la solicitud y 2 significa que el propio servidor no puede analizar la solicitud. Otros valores aparecen con menos frecuencia y puede consultar el documento RFC1035 después de que aparezcan.
Los 2 bytes de QDCOUNT
indican el número de nombres de dominio a consultar posteriormente, el valor de la figura 4 es 1, y solo hay un registro en la solicitud correspondiente. Los 2 bytes de ANCOUNT indican la cantidad de entradas en la respuesta del servidor DNS, como se muestra en la Figura 5, hay 5 registros de respuesta, porque un nombre de dominio puede corresponder a varias direcciones IP, por lo que hay 5 registros de respuesta
. Los 2 bytes de NSCOUNT indican el número de registros autenticados por el servidor, como se muestra en la Figura 4/5, y la estructura del registro de autenticación en la Figura 2. Los bytes ARCOUNT 2 indican si hay registros de información adicional, como se muestra en la Figura 4/5, y la estructura de la información adicional en la Figura 2.
Campo de solicitud de DNS
El contenido del mensaje de solicitud definido por RFC 1035 es como se muestra en la Figura 9: Figura
9
QNAME
Este campo indica el contenido del nombre de dominio solicitado Dado que la cadena del nombre de dominio es de longitud variable, esta parte del contenido utiliza una codificación especial método, longitud + contenido de caracteres, y está codificado en código ASCII 0 como final.
QTYPE
Este campo utiliza dos bytes para indicar el tipo de registro de la solicitud, como se muestra en la Figura 4, el número 1 representa el registro A, es decir, la resolución del nombre de dominio a la dirección IP. Además, DNS también admite muchos otros tipos de solicitudes de resolución, como se muestra en la Figura 10 a continuación. Entre ellos, CNAME representa un registro de alias; NS representa el registro de dirección IP para consultar el servidor DNS; PTR representa un registro de consulta inversa, es decir, el registro de mapeo de IP a DNS; MX representa el registro de mapeo del nombre de dominio al dirección del servidor de correo, como buscar según el sufijo del buzón. La dirección del servidor de correo correspondiente pertenece a este escenario.
En la primera red, QCLASS
consideró otras redes fuera de Internet, como se muestra en la Figura 11. Pero este campo es básicamente 1 en las solicitudes de DNS ahora, porque básicamente desaparecen otros tipos de redes.
Figura 10
Figura 11
campo de respuesta DNS
El contenido del mensaje de solicitud definido por RFC 1035 se muestra en la Figura 12:
Figura 12
Entre ellos, los significados de NOMBRE, TIPO y CLASE son los mismos que los de la solicitud, y los significados de otros campos son los siguientes:
TTL
4 bytes indican la cantidad de segundos que se almacena en caché la sugerencia de registro DNS.
Los dos bytes de RDLENGTH
indican la longitud de los datos de la parte RDDATA, y
los datos de longitud variable de RDDATA
indican el contenido del análisis, que corresponde a la dirección IP analizada en la Figura 5.
A través de los documentos RFC anteriores y los paquetes de datos DNS reales, se presenta cada campo de DNS y los dos métodos de consulta de DNS se presentarán más adelante.
Este artículo es un artículo original de los jóvenes del pueblo de CSDN, y no puede ser reproducido sin permiso. El blogger enlaza aquí .