¿Qué es dig + trace?

Mujer sentada delante de un ordenador

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 rastrea completamente la cadena de delegación del dominio en cuestión. Puede ir desde los servidores de nombres raíz hasta los servidores de dominio de nivel superior (TLD) y los 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 un fallo 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 prolongar los tiempos de consulta más allá de la paciencia humana normal.

El tiempo medio 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 novedades sobre tecnología, respaldadas por conocimientos de expertos

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

¡Gracias! Se ha suscrito.

Su suscripción se enviará en inglés. Encontrará un enlace para darse de baja en cada boletín. 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 es necesario utilizar dig +trace?

En un comando dig normal, su servidor DNS, que actúa como el solucionador de su 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 ocurre en una situación ideal, cuando todo sale según lo previsto. 

Los administradores recurren a dig +trace cuando necesitan ir "bajo el capó". Por lo general, debe omitir el proceso de consulta habitual porque algo ha ido mal. Hay una parte de la cadena de enrutamiento que no funciona correctamente. Por lo tanto, los administradores deben poder diseccionar y estudiar partes de esa cadena y sus diversos vínculos para descubrir qué no funciona correctamente.

Cuando los equipos utilizan dig +trace, hacen caso omiso de lo que se ha almacenado anteriormente en caché, por lo que pueden ejecutar una consulta nueva e iterativa sin que se les dirija por rutas antiguas y obsoletas.

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

NS1 Connect

IBM NS1 Connect

Refuerce la resiliencia de su red con IBM NS1 Connect. En este vídeo, 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 en realidad se reduce a cuatro pasos.

1. Tipos de usuario en un nombre de dominio

Si el usuario ha introducido previamente ese nombre de dominio y el ordenador ha almacenado en caché su dirección IP, el símbolo del sistema (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 ejecuta 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 TLD para descubrir los servidores de nombres autorizados para un dominio en particular.

4. Consulta de servidor de nombres autoritativo

A continuación, 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 apto para humanos a 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 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 la investigación a lo largo de esa ruta, los administradores reciben mensajes de output que les permiten 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” que le informa de que no ha habido incidentes en esta fase de la prueba. (Nota: ese mensaje no indica el éxito o fracaso operativo general y no debe malinterpretarse. Aunque es útil, está limitado en la información que transmite.)

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

13 servidores de nombres raíz lógicos

El sistema de nombres de dominio utilizado por Internet se compone de diferentes servidores raíz de nombres que operan a varios niveles. De primordial importancia son los 13 servidores de nombres raíz lógicos que funcionan en el nivel superior, cuyos nombres corresponden a las 13 primeras letras del alfabeto.

Cada uno de estos 13 servidores de nombres raíz lógicos no se refiere a ordenadores 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. Por lo tanto, cuando hablamos de "Servidor A", nos referimos a la designación de Servidor A, que puede cubrir un número ilimitado de servidores DNS individuales.

También debemos señalar que los 13 servidores de nombres raíz se delegan en un grupo variado de entidades: diversas empresas con fines de lucro mezcladas con organizaciones universitarias y militares. Y aunque 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 ido reequilibrando 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: Universidad del Sur de California (ISI). El Instituto de Ciencias de la Información de la USC estudia tecnología avanzada de informática 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: la Universidad de 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 servicios de redes 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: Network Information Center (NIC) del Departamento de Defensa de EE. UU., que también es responsable de gestionar el plan de direcciones IPv6 del Departamento de Defensa.
  • Servidor H (h.root-servers.net): Operador: Laboratorio de Investigación del Ejército de EE. UU. (ARL), anteriormente conocido como Ballistics Research Laboratory (BRL). 
  • Servidor I (i.root-servers.net): Operador: Netnod, una organización sueca sin ánimo de lucro de infraestructura de Internet conocida principalmente por sus servicios de interconexión en 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 Centre (RIPE NCC), un registro regional de Internet (RIR) sin ánimo de lucro dedicado a Europa, Oriente Medio y Asia. 
  • Servidor L (l.root-servers.net): Operador: Internet Corporation for Assigned Names and Numbers (ICANN), una organización sin ánimo de lucro que comenzó mediante un contrato gubernamental de EE. UU. pero que ahora existe como una entidad separada y centrada en el ámbito global.
  • Servidor M (m.root-servers.net): Operador: el WIDE Project, 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 se trata principalmente de 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 esas cifras son conjeturas fundamentadas. Es un número tan grande que realmente no se puede calcular.

Temas relacionados

Hay varias cuestiones relacionadas tangencialmente que también deben abordarse:

  • Una forma de obtener aún más servicios de DNS es mediante el uso de mecanismos de extensión para DNS (EDNS). EDNS es una colección de mejoras para protocolos DNS. Cuando los administradores encuentran una mayor carga de mensajes DNS, el EDNS se adapta para transportar estos paquetes de datos sobredimensionados. Además de admitir mensajes más grandes, EDNS también ofrece opciones como EDNS Client Subnet (ECS), que mejora los niveles de rendimiento de las aplicaciones que suelen verse 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 las versiones EDNS, los 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. 
  • Linux y ciertos sistemas tipo Unix dependen del archivo de configuración etc/resolv.conf para notificar al sistema que active sus rutinas de resolver para encontrar direcciones IP para 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 utilizan DNS suelen contener una página de manual (o "página manual"). Esta página sirve como documentación que describe los datos definidos sobre un archivo de comandos, una llamada al sistema o un archivo de configuración en particular. Las páginas de manual proporcionan una idea general del contexto sobre los archivos y las herramientas del sistema, y se centran en información como el nombre del comando o programa, la sinopsis, la descripción y las 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 del 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 red en la nube
Servicios de soporte de redes

Consolide el soporte de los centros de datos con IBM Technology Lifecycle Services para redes en la nube y más.

Servicios de redes en la nube
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 Solicite una demostración en directo