¿Qué es dig +trace?

Mujer sentada frente a una computadora

Autores

Phill Powell

Staff Writer

IBM Think

Ian Smalley

Staff Editor

IBM Think

¿Qué es dig +trace?

Dig +trace es un comando de diagnóstico DNS que funciona con el Sistema de Nombres de Dominio (DNS) y permite la búsqueda DNS recursiva completa para determinados dominios.

Dig +trace realiza un seguimiento completo de la cadena de delegación del dominio en cuestión. Puede ir desde servidores de nombres raíz hasta servidores de dominio de nivel superior (TLD) y servidores de nombres autoritativos. Dig +trace ayuda a los equipos a solucionar problemas de resolución de DNS.

Los problemas más evidentes serían una falla total de conexión con un determinado dominio o subdominio, como lo demuestra una pantalla de aviso de fallo. Otro tipo de problema de resolución de DNS es la latencia, que puede extender los tiempos de consulta más allá de la paciencia humana normal.

El tiempo promedio de búsqueda de DNS se mide en milisegundos (MSEC) y tiende a oscilar entre 20 MSEC y 120 MSEC. Los esfuerzos de optimización buscan reducir aún más esos tiempos de consulta.

Las últimas noticias tecnológicas, respaldadas por los insights de expertos

Manténgase al día sobre las tendencias más importantes e intrigantes de la industria sobre IA, automatización, datos y más con el boletín Think. Consulte la Declaración de privacidad de IBM.

¡Gracias! Ya está suscrito.

Su suscripción se entregará en inglés. En cada boletín, encontrará un enlace para darse de baja. Puede gestionar sus suscripciones o darse de baja aquí. Consulte nuestra Declaración de privacidad de IBM para obtener más información.

¿Cuándo necesita usar dig +trace?

En un comando dig normal, tu servidor DNS, que actúa como el solucionador de tu proveedor de servicios de Internet (ISP), emite una solicitud recursiva y revisa sus cachés locales en busca de un registro DNS reciente y no caducado. Pero eso es lo que sucede en una situación ideal, cuando todo va bien. 

Los administradores recurren a excavar +rastreo cuando necesitan ir "tras bambalinas". Por lo general, debe omitir el proceso de consulta habitual porque algo salió mal. Hay alguna parte de la cadena de enrutamiento que no funciona correctamente. Por lo tanto, los administradores deben poder analizar y estudiar partes de esa cadena y sus diversos vínculos para descubrir qué no funciona correctamente.

Cuando los equipos utilizan dig +trace, ignoran efectivamente lo que se almacenó previamente en caché, por lo que pueden ejecutar una consulta nueva e iterativa sin ser enrutados por rutas antiguas y obsoletas.

Dig +trace es útil para la resolución de problemas porque le permite ver dónde se está interrumpiendo la resolución de DNS. El problema podría estar en el nivel raíz, TLD o de autoridad. También puede verificar si los registros del servidor de nombres de su dominio son correctos y verificar la propagación de DNS después de los cambios.

NS1 Connect

IBM NS1 Connect

Fortalezca la resiliencia de su red con IBM NS1 Connect. En este video, analizamos el valor de IBM NS1 Connect para la resiliencia y el rendimiento de las aplicaciones.

¿Cómo funciona dig +trace?

El proceso dig +trace realmente se reduce a cuatro pasos.

1. El usuario escribe un nombre de dominio.

Si el usuario introdujo previamente ese nombre de dominio y la computadora almacenó en caché su dirección IP, el símbolo de comandos (CMD) recupera instantáneamente la dirección IP necesaria. El sistema accede y descarga el contenido solicitado y el proceso de consulta finaliza en ese momento. 

Sin embargo, si el nombre de dominio es nuevo y desconocido para ese dispositivo, se ejecutan el resto de estos pasos.

2. Primera consulta

El comando dig busca los servidores de nombres raíz para los registros del servidor de nombres (NS) asociados con el dominio de nivel superior (TLD) del dominio de destino que se está encuestando.

3. Consulta del servidor de nombres TLD

El comando dig investiga los servidores de nombres de TLD para descubrir los servidores de nombres autorizados para un dominio en particular.

4. Consulta del servidor de nombres autoritativo

Luego, el comando dig consulta a los servidores de nombres autorizados para acceder a los registros DNS solicitados. Por ejemplo, el “registro A” es un registro de recursos que asocia un nombre de dominio amigable para los humanos con una dirección IPv4 o IPv6. Mientras tanto, los registros de inicio de autoridad (SOA) contienen los datos administrativos necesarios para una zona DNS.

La respuesta de DNS que se proporciona incluye la "sección de respuesta", que son registros de recursos que pueden responder correctamente a la consulta original (también conocida como "sección de preguntas").

Además, la respuesta también puede tener una sección de autoridad que enumere los servidores de nombres autorizados y posiblemente una "sección adicional" que contenga información adicional. Los administradores pueden seleccionar exactamente qué tipos de registros desean, ya sean servidores de correo (registros MX) o servidores de nombres (registros NS). 

Mensajes a lo largo del camino

En cada paso de investigación a lo largo de esa ruta, los administradores reciben mensajes de salida para hacerles saber el estado de cada fase y si la progresión continúa según lo previsto.

Por ejemplo, el administrador ve un mensaje “NOERROR” para hacerle saber que no hubo incidentes en esta etapa de la prueba. (Nota: ese mensaje no indica el éxito o fracaso operativo general y no debe malinterpretarse. Si bien es útil, está limitado en la información que transmite).

Es interesante observar que la infraestructura de DNS ayuda a respaldar la jerarquía de DNS y utiliza un ingenioso sistema de referencias para ayudar en el proceso de búsqueda. De esta manera, si un servidor no puede llevar la consulta hasta su finalización, esencialmente guía la consulta a otro servidor que ayuda en su progreso y amplía su recorrido. 

13 servidores de nombres raíz lógicos

El sistema de nombres de dominio utilizado por Internet está compuesto por diferentes servidores de nombres raíz que operan en varios niveles. De primordial importancia son los 13 servidores de nombres raíz lógicos que trabajan en el nivel superior, que llevan el nombre de las primeras 13 letras del alfabeto.

Cada uno de estos 13 servidores de nombres raíz lógicos no se refiere a computadoras o sistemas operativos individuales, sino que representa una autoridad designada que gobierna una decimotercera parte de todo el tráfico de consultas DNS de Internet. Entonces, cuando nos referimos al "Servidor A", nos referimos a la designación del Servidor A, que puede cubrir un número ilimitado de servidores DNS individuales.

También cabe destacar que los 13 servidores de nombres raíz están delegados a un grupo variado de entidades, entre las que se encuentran diversas empresas con fines de lucro, universidades y organizaciones militares. Y si bien es cierto que originalmente la ubicación de la mayoría de los servidores físicos estaba muy concentrada en Estados Unidos, esa ecuación se ha reequilibrado con el tiempo. Ahora, los servidores físicos están repartidos por todo el mundo.

Estos son los grupos que mantienen la responsabilidad de ejecutar las 13 designaciones diferentes de root-servers.net:

  • Servidor A (a.root-servers.net): Operador: VeriSign, Inc., que ofrece infraestructura de Internet y servicios de registro de nombres de dominio en todo el mundo.
  • Servidor B (b.root-servers.net): Operador: The University of Southern California (ISI). El Instituto de Ciencias de la Información de la USC estudia tecnología avanzada de computación y comunicación.
  • Servidor C (c.root-servers.net): Operador: Cogent Communications, un ISP internacional que gestiona una importante red de fibra óptica y ofrece servicios de colocación.
  • Servidor D (d.root-servers.net): Operador: The University of Maryland y gestionado por su grupo Advanced Cyberinfrastructure and Internet Global Services (ACIGS).
  • Servidor E (e.root-servers.net): Operador: NASA, más específicamente la línea de servicio de Servicios de Red y Telecomunicaciones (NaTS) de la agencia espacial estadounidense. 
  • Servidor F (f.root-servers.net): Operador: Internet Systems Consortium, Inc., una corporación sin fines de lucro que apoya Internet ofreciendo varios software y protocolos. 
  • Servidor G (g.root-servers.net): Operador: Centro de Información de Red (NIC) del Departamento de Defensa de EE. UU., que también es responsable de gestionar el plan de direcciones IPv6 del DoD.
  • Servidor H (h.root-servers.net): Operador: US Army Research Laboratory (ARL), anteriormente conocido como Ballistics Research Laboratory (BRL). 
  • Servidor I (i.root-servers.net): Operador: Netnod, una organización sueca sin fines de lucro de infraestructura de Internet conocida principalmente por sus servicios de interconexión dentro de las regiones nórdicas. 
  • Servidor J (j.root-servers.net): Operador: VeriSign, Inc. (ver Servidor A). 
  • Servidor K (k.root-servers.net): Operador: Reseaux IP Europeens Network Coordination Center (RIPE NCC), un registro regional de Internet (RIR) sin fines de lucro dedicado a Europa, Medio Oriente y Asia. 
  • Servidor L (l.root-servers.net): Operador: Internet Corporation for Assigned Names and Numbers (ICANN), una organización sin fines de lucro que comenzó a través de un contrato con el gobierno de EE. UU., pero ahora existe como una entidad separada y centrada en el mundo.
  • Servidor M (m.root-servers.net): Operador: El Proyecto WIDE, que significa Entorno Distribuido Ampliamente Integrado, este proyecto de Internet comenzó a través de una colaboración de tres universidades japonesas. 

El tráfico de consultas se distribuye uniformemente entre los 13 servidores, sin que ningún servidor maneje más que otro. Los factores regionales pueden influir en los servidores a los que acceden más los usuarios, pero en general el tráfico es similar, y en su mayoría implica solicitudes de direcciones de ISP.

La razón por la que se necesitan 13 entidades para gestionar el tráfico de consultas DNS es que cada año se generan billones de consultas DNS. Algunas estimaciones hacen que el total supere los 100 billones, pero esos números son conjeturas fundamentadas. Es un número tan grande que realmente no se puede calcular.

Temas relacionados

Hay un puñado de problemas relacionados tangencialmente que también deben abordarse:

  • Una forma de obtener aún más empresa de servicios públicos del DNS es mediante el uso de mecanismos de extensión para DNS (EDNS). EDNS es una colección de mejoras para los protocolos DNS. Cuando los administradores encuentran cargas útiles de mensajes DNS más grandes, EDNS se adapta para transportar estos paquetes de datos de gran tamaño. Además de dar cabida a mensajes más grandes, EDNS también ofrece opciones como EDNS Client Subnet (ECS), que aumenta los niveles de rendimiento de las aplicaciones que a menudo se ven afectadas por problemas de latencia. 
  • La pseudosección OPT es un tipo único de registro DNS iniciado por EDNS. Lleva información útil sobre transacciones, pero no datos DNS estándar. La pseudosección OPT se incluye en la sección "datos adicionales" de los mensajes DNS. Proporciona detalles como versiones de EDNS, indicadores y el tamaño máximo de paquete para el Protocolo de datagramas de usuario (UDP), un formato de consulta de uso común. 
  • Los sistemas operativos Linux y ciertos sistemas similares a Unix dependen del archivo de configuración etc/resolv.conf para notificar al sistema que active sus rutinas de resolución para encontrar direcciones IP para los nombres de host correspondientes. El contenido de este archivo incluye las direcciones IP de los servidores DNS, listas de dominios para buscar, nombres de dominio locales y opciones que le permiten determinar las acciones de resolución. Estas acciones pueden incluir opciones globales, que son configuraciones que los administradores pueden aplicar unilateralmente. 
  • Los sistemas similares a Unix que realmente no usan DNS a menudo contienen una página de manual. Esta página sirve como documentación que describe los datos definidos sobre un archivo de comando, llamada al sistema o archivo de configuración en particular. Las páginas Man proporcionan un sentido general del contexto sobre los archivos y herramientas del sistema, centrándose en información como el nombre del comando o programa, sinopsis, descripción y opciones.
Soluciones relacionadas
IBM NS1 Connect

IBM NS1 Connect es un servicio en la nube totalmente gestionado para DNS empresarial, DHCP, gestión de direcciones IP y dirección de tráfico de aplicaciones.

Explore NS1 Connect
Soluciones de red

Las soluciones de redes en la nube de IBM proporcionan conectividad de alto rendimiento para potenciar sus aplicaciones y su negocio.

Explore las soluciones de nube de IBM
Servicios de apoyo en red

Consolida el soporte del centro de datos con IBM Technology Lifecycle Services para cloud networking y más.

Servicios de redes cloud
Dé el siguiente paso

Refuerce la resiliencia de su red con IBM NS1 Connect. Comience con una cuenta de desarrollador gratuita para explorar soluciones de DNS gestionado o programe una demostración en directo para ver cómo nuestra plataforma puede optimizar el rendimiento y la fiabilidad de su red.

Explore los servicios DNS gestionados Reserve una demostración en vivo