DNS

El Sistema de Nombres de Dominio o DNS (Domain Name System) permite asociar nombres de dominios con direcciones IP. Es una base de datos con nombres y direcciones de todas las direcciones registradas en internet. Cada dominio equivale a una IP pero no a la inversa, ya que un mismo servidor puede contener varias páginas web con dominios distintos.

Cuando en el navagador introducimos un dominio, pongamos de ejemplo tallerdeapps.com, gracias al DNS se traduce o, dicho correctamente en términos de redes, se resuelve que ese dominio corresponde con la IP 185.224.137.181. Si es una página visitada anteriormente, la dirección la tendrá la caché DNS del propio navegador y ahorraremos la consulta pero, si no es la primera vez que lo usa o ha pasado un largo tiempo que se borró de la caché, comenzará un proceso complejo que puede utilizar varios servidores hasta resolverlo. El mecanismo de búsqueda está muy jerarquizado y cualquier consulta puede pasar por varios servidores hasta llegar al que realmente resuelve la IP.

Existen 2 métodos para resolución de nombres:

  • Búsqueda iterativa
  • Búsqueda recursiva

Búsqueda iterativa

Este mecanismo suele ser el más el común. De forma simplificada la explicamos con este esquema y un ejemplo:

(1) Solicitamos en un navegador que abra por primera vez la web www.tallerdeapps.com. Al tratarde de un dominio en ese momento desconocido no lo tiene en la cache y hará la consulta al llamado "DNS resolver" o sulucionador de DNS. Un DNS resolver puede ser un programa o un servidor. Normalmente es un servidor que nos hace de interfaz entre el usuario y el dominio para resolver la dirección IP. La verdadera base de datos de dominios se encuentra en otro sitio (a varios niveles de distancia). El resolver DNS lo proporciona nuestro ISP (proveedor de internet en los ajuestes del router). Si nos interesa poner otros DNS podemos hacerlo tanto en el router como en los ajustes de red de la interfaz del ordenador prevaleciendo siempre los que pongamos en la interfaz.

Existen una gran cantidad de DNS resolvers. Unos gratuitos y otros de pago. Las diferencias entre ellos son la velocidad, seguridad y privacidad. Los servidores gratuitos aunque un poco más lentos ofrecen muy buen rendimiento, seguridad y también en algunos casos prometen privacidad. No pagamos dinero por usarlos pero se lo van a cobrar de otra manera con publicidad.

Entre los DNS gratuitos más conocidos podemos citar a Google (8.8.8.8, 8.8,4,4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS Home (208.67.222.222, 208.67.220.220). La razón de que sean dos direcciones IP, una principal y otra secundaria, es para tener una alternativa en caso de que falle una poder navegar con la otra. Si no funciona ninguna de las 2 no podremos navegar por internet. Hay una amplia oferta de DNS gratuitos y privados muy fáciles de encontrar desde cualquier buscador. Los DNS de pago están indicados para empresas potentes que buscan un punto más de calidad y privacidad. Para la mayoría de usuarios, sean empresas o particulares, no hay grandes incovenientes en usar DNS públicos, ya que funcionan muy bien.

Como tercera posibilidad podemos usar un servidor DNS local usando el software de código abierto BIND. Se puede instalar en Windows Server o Linux. Su uso resulta recomendable en redes de empresas para resolver con rápidez los dominios de equipos de la intranet que prestan servicios con un nivel alto de seguridad y rápidez. No sustituye a un DNS como el 8.8.8.8 de Google o el 1.1.1.1 de Cloudfare, ya que está enfocado para servicios de intranet.

(2) Siguiendo con el ejemplo, cuando llega la consulta al DNS resolver tratará de encontrar la IP en su propia caché. Si no la tiene buscará en el Servidor Raíz (root server). Recuerda que hemos comentado que los resolver no son el sitio real donde se almacena la gran base de datos de dominios aunque como tienen una gran caché almacena una buena colección de dominios frecuentes.

(3) Los servidores raíz es el inicio o raíz de la jerarquía DNS. Tampoco es aquí donde se archivan los dominios. Su misión es redirigirnos a otro servidor según la raíz del dominio. Se le llama raíz o TLD (top level domain) a la terminación del dominio, osea los conocidos .com, .org, .info, etc. El servidor raíz se encarga de delegar la consulta al servidor asignado para la raíz correspondiente. Actualmente, hay 13 conjuntos de servidores raices ubicados en diferentes partes del mundo. Cada conjunto tiene su IP única y están siendo gestionados por 12 organizaciones tanto internacionales, gubernamentales, privados de diferente índole. Hay empresas, universidades, consorcios, NASA y Ejercito de USA. Se dice que son 13 servidores pero al estar instanciados muchas veces se trata en total de 1576 servidores en el momento de escribir esto.

https://root-servers.org/

En nuestro ejemplo, tenemos a un resolver comunicando con uno de los 13 conjuntos de servidores raíz del mundo. ¿Cual? Por cercanía geográfica o el que tenga menos latencia en ese momento. No es algo que elijamos nosotros.

(4) El servidor de raiz responderá al resolver en que servidor de nombres intermedios puede encontrar al dominio.

(5) El servidor TLD (Top Level Domain), también llamado servidor de nombres intermedios, almacena la dirección del servidor que contiene el registro donde finalmente se resolverá el dominio. No resuelve el dominio, solamente sabe en que servidor se encuentra la IP de ese dominio de la parte intermedia, es decir, tallerdeapps.com. Se llama TLD al prefijo de la derecha que forma el dominio. Los hay gTLD (g de genéricos):.com, .net, .org y un largo etc. Los hay ccTLD (cc de country code). que siempre tendrán 2 letras para indicar el país: .es, fr, .uk, etc. El último grupo de TLD es el patrocinado por una entidad específica, la cual podría ser un negocio, gobierno, u otro grupo. Se le conoce por sTLD ( s de sponsored). Actualmente hay 13 dominios sTLD siendo los más populares .gov, .edu y .mil.

(6) Salvo que que el servidor TLD tenga en la caché el dominio buscado, el servidor resolver recibirá por respuesta la dirección del servidor de nombres autoritario y procede a consultarle.

(7) El servidor de nombres autoritario, es el último eslabón. También es conocido como name server. Aquí está registrado tallerdeapps.com y todos los subdominios. Puede resolver www.tallerdeapps.com, mail.tallerdeapps.com y cualquier otro subdominio. A los servidores que guardan los registros de los dominios se les conoce como NS o Name Server. Normalmente están mantenidos por las empresas de hosting o de dominios. Por seguridad, suelen estar replicados varias veces para que si falla uno al menos otro siga operativo. En este caso particular los NS se llaman:

  • ns1.dns-parking.com
  • ns2.dns-parking.com

Como mínimo habrán 2 copias pero podrían ser 4 o más. Por norma, los NS usan como subdominio ns1, ns2, etc.

(8) Finalmente, el resolver recibe la información del dominio y pasa a informar al navegador (10). Esto sería a grosso modo la forma de trabajar de los DNS haciendo búsqueda iterativa.

Búsqueda recursiva

Este método se usa cuando no es posible usar la iteración. El orden de la búsqueda se resume en el esquema siguiente:

El flujo de resolución en búsqueda recursiva es lineal. Cada servidor DNS va preguntando al siguiente nivel si conoce el dominio y hasta que no se produce la resolución el flujo de datos no vuelve en sentido inverso. Al igual que con la búsqueda iterativa, si uno de los servidores tiene en su caché la resolución no seguirá buscando hasta el servidor de nombres autoritario.

Servidores de dominio, registros y propagación

Cuando compramos un dominio de internet para crear una página web, el "registrador de dominios" nos facilitará la manera de introducir los datos que identifiquen el dominio y su dirección IP en los servidores de nombres autoritarios.

Por norma general cada "Registrador de dominios" tiene sus propios servidores concertados pero, si lo preferimos, podemos escoger cualquiera de los muchos que hay de pago e incluso gratuitos.

De entre los DNS públicos tiene muy buena reputación https://freedns.afraid.org/ que como dice su publicidad nos permite registrar en sus servidores cualquier dominio. El inconveniente de este tipo de servicios gratuitos es que no tenemos garantizada esa gratuitidad para siempre. Intenté registrar un dominio .com para conocer la web y actualmente ese tipo de registros ya no son gratuitos. Solamente ví opción de registrar subdominios a elegir de varios cientos de dominios a elegir de una lista ofertada en la web. Y tampoco era así 100% gratis ya que para activar algunas opciones hay que pagar una tarifa. Conclusión: los recursos gratuitos no tienen garantizada su gratuitidad para siempre.

El proceso de registrar un dominio es similar en todos los DNS. Hay un conjunto de registros por cada dominio con información de que a IP apunta el dominio y los subdominios. Al conjunto de registros que definen al dominio se le llama también archivo de zona y se guarda en la llamada Zona DNS.

En el archivo definimos que dirección IP está asociado a cada dominio y cada subdominio, las direcciones de los servidores de dominio y otros datos. Teniendo un dominio en propiedad podemos usar varios host o servidores para diferentes servicios. No hay problema en que el subdominio www apunte a un servidor donde esté alojado la web y que cualquier otro subdominio como, por ejemplo mail, apunte a otro servidor para dar servicio de correo. Por ese motivo si hacemos ping a un dominio y varios de sus subdominios no tiene necesariamente que dar la misma IP. Un buen ejemplo podría ser Google que para el buscador por web y el servicio de correo utiliza servidores con IP diferente. No es una condición obligada usar direferentes IP para cada servicio. Esto solo lo hacen sitios con mucho volumen de tráfico. A nivel pequeña, mediana empresa un servidor en una sola IP podría ser suficiente para cubrir las necesidades.

ping google.com -4

Haciendo ping a google.com [142.250.184.14] con 32 bytes de datos:
Respuesta desde 142.250.184.14: bytes=32 tiempo=18ms TTL=117

ping mail.google.com -4

Haciendo ping a mail.google.com [172.217.17.5] con 32 bytes de datos:
Respuesta desde 172.217.17.5: bytes=32 tiempo=14ms TTL=117
                        

Para ver de manera muy gráfica como va la propagación de los dominios registrados en un name server hay varias web que dan este servicio. De entre ellas https://dnschecker.org/ funciona muy bien. Simplemente escribes el dominio a comprobar, seleccionas que registro quieres comprobar y pulsas [SEARCH]. Si no ajustas nada más comproborá sobre 22 servidores repartidos por el todo el mundo. Es posible seleccionar un continente o área geográfica y si repites la búsqueda lo hará sobre unos 20-30 servidores de esa zona. Además desde la misma web puedes encontrar otros servicios para comprobar DNS.

Tabla de registros DNS

Los registros más importantes usados en el archivo de zona son:

Registro A

Es el registro más importante. Indica la dirección IPv4 del dominio. La mayor parte de los dominios solo tienen un registro A, por lo que se solamente hay un servidor. En algunos dominios muy utilizados como buscadores, redes sociales y otros perfiles de alta demanda suelen ponerse varios registros para repartir la carga de trabajo por medio de la técnica llamada round robin load balancing.

Ejemplo de registro A:

Tipo Nombre Prioridad Contenido TTL
A tallerdeapps.com 0 185.224.137.181 14400

Generalmente, se sustituye en los registros tipo A el dominio por el símbolo @. La IP es la dirección serl servidor. El TTL es el intervalo de tiempo que el servidor de dominio propagará los cambios. Cuando recién hacemos una modificación puede interesarnos poner un tiempo pequeño para acelerar el proceso. Una vez se ha propagado, que puede ser un tiempo variable desde unos minutos a días podemos subir el tiempo de TTL.

Registro AAAA

Muy parecido al registro A solo que indica la dirección IPv6. En el futuro, probablemente solo existirá el registro AAAA cuando se termine de adaptar la red al protocolo IPv6.

Registro CNAME

Nombre Canónico. Se utiliza para los subdominios. Un subdominio si está registrado con CNAME debe apuntar al dominio de raiz. Se entenderá mejor con un ejemplo. Tenemos un registro A de tallerdeapps.com que apunta a la dirección x.x.x.x. Si creamos un registro CNAME para el subdominio preguntas conseguiremos que al entrar desde un navegador la dirección: preguntas.tallerdeapps.com se dirigirá a la IP de tallerdeapps.com. El servidor web verá en la URL que se trata del subdominio preguntas y nos llevará a la página correspondiente.

Tipo Nombre Prioridad Contenido TTL
CNAME preguntas 0 tallerdeapps.com 14400

El subdominio más conocido es www que además suele apuntar al mismo sitio que el dominio. De esta manera conseguimos que el navegador vaya a la misma página web sin importar si ponemos subdominio o no. Otro caso de subdominio muy común es mail para el servicio de correo.

Tipo Nombre Prioridad Contenido TTL
CNAME www 0 @ 14400

No necesariamente un subdominio y el dominio tienen que apuntar a la misma IP. Podemos tener un VPS exclusivamente para servicios web y en otro VPS tener por una tienda, blog, servidor de correo, un servidor alternativo para pruebas o lo que se nos ocurra. Si el subdominio pertenece a otra IP usaremos el registro A. En este ejemplo vpstest.tallerdeapps.com apunta a un servidor alternativo.

Tipo Nombre Prioridad Contenido TTL
A vpstest 0 184.45.55.44 14400

Registro MX

El registro MX dirige el correo a un servidor de correo electrónico.

Tipo Nombre Prioridad Contenido TTL
MX @ 5 mx1.srvcorreo.es 14400

Registro TXT

Permite almacenar etiquetas de texto legibles para humanos. Experimentalmente permite almacenar pares de valores con la forma "attribute=value" aunque este uso no está muy extendido. En la actualidad se está utilizando como medida de seguridad para evitar uso fraudolento del dominio en servidores de correo. Hay varias técnicas que ayudan a demostrar que el dominio usado es de su legítimo dueño. Una de esas técnicas es por medio de parejas de clave público-privadas alojando una de ellas en el registro TXT.

Registro NS

La entidad registradora proporciona su propio servidor de nombres autoritario donde registrar el dominio. Un mínimo de 2 aunque pueden ser 4 servidores desde donde se propagará a los servidores de nombres intermedios y servidores raiz. Al modificar o dar de alta un dominio pueden pasar de minutos a unas pocas horas para que el dominio sea conocido en internet.

Registro SOA

ejemplo

dominio tallerdeapps.com
Tipo de registro SOA
MNAME ns1.dns-parking.com
RNAME dns@hostinger.com
Serie 2022111701
Actualizar 10000
RETRY 2400
EXPIRE 604800
TTL 600
Creación de registros DNS en un registrador

Como ejemplo una captura de pantalla de como se ve un dominio registrado en Hostinger. Muchos otros registradores son muy similares en cuanto la interfaz del proceso de creación o edición del archivo de zona. Sobre el dominio que tengamos contratado podemos crear y modificar cualquier registro de manera muy cómoda a través de un panel.

Verificando los registros DNS

Por comandos desde la terminal de Windows o Linux podemos obtener muchos datos de los registros dns. Antes de comenzar a ver algunos de ellos, también nos puede interesar sacar la información por algunas de las web que ofrecen este servicio. Una muy completa es https://who.is/, se trata en realidad de un reclamo que nos pone una empresa de contratación de dominios. Desde aquí podemos obtener los registros y otras comprabaciones.

Comandos para DNS

Los más comunes son dig, nslookup y host. A continuación algunos ejemplos con ellos.

Comando host

Si entramos host sin parámetro muestra una ayuda con toda la lista de parámetros que soporta. En este artículo solo veremos algunos de ellos.

ubuntu@ubuntusrv2:~$ host
Usage: host [-aCdilrTvVw] [-c class] [-N ndots] [-t type] [-W time]
            [-R number] [-m flag] hostname [server]
       -a is equivalent to -v -t ANY
       -A is like -a but omits RRSIG, NSEC, NSEC3
       -c specifies query class for non-IN data
       -C compares SOA records on authoritative nameservers
       -d is equivalent to -v
       -l lists all hosts in a domain, using AXFR
       -m set memory debugging flag (trace|record|usage)
       -N changes the number of dots allowed before root lookup is done
       -r disables recursive processing
       -R specifies number of retries for UDP packets
       -s a SERVFAIL response should stop query
       -t specifies the query type
       -T enables TCP/IP mode
       -U enables UDP mode
       -v enables verbose output
       -V print version number and exit
       -w specifies to wait forever for a reply
       -W specifies how long to wait for a reply
       -4 use IPv4 query transport only
       -6 use IPv6 query transport only
                            

Su uso más sencillo es únicamente añadiendo como argumento el dominio a estudiar:

ubuntu@ubuntusrv2:~$ host tallerdeapps.com
tallerdeapps.com has address 185.224.137.181
tallerdeapps.com has IPv6 address 2a02:4780:8:252:0:2e80:9a24:1
tallerdeapps.com mail is handled by 10 mx2.hostinger.es.
tallerdeapps.com mail is handled by 5 mx1.hostinger.es.
                        

La respuesta incluye los registros A, AAAA y MX. En el caso de los registros MX incluye también la prioridad. Cuanto más pequeño el número mayor la prioridad.

Si añadimos el parámetro -v (v de verbose) devuelve una respuesta más detallada. El formato de salida es muy parecido al del comando dig.

ubuntu@ubuntusrv2:~$ host -v tallerdeapps.com
Trying "tallerdeapps.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 572
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tallerdeapps.com.              IN      A

;; ANSWER SECTION:
tallerdeapps.com.       14400   IN      A       185.224.137.181

Received 50 bytes from 127.0.0.53#53 in 43 ms
Trying "tallerdeapps.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10461
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tallerdeapps.com.              IN      AAAA

;; ANSWER SECTION:
tallerdeapps.com.       14400   IN      AAAA    2a02:4780:8:252:0:2e80:9a24:1

Received 62 bytes from 127.0.0.53#53 in 27 ms
Trying "tallerdeapps.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4808
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tallerdeapps.com.              IN      MX

;; ANSWER SECTION:
tallerdeapps.com.       14400   IN      MX      5 mx1.hostinger.es.
tallerdeapps.com.       14400   IN      MX      10 mx2.hostinger.es.

Received 86 bytes from 127.0.0.53#53 in 43 ms

                        
ubuntu@ubuntusrv2:~$ host -t soa tallerdeapps.com
tallerdeapps.com has SOA record ns1.dns-parking.com. dns.hostinger.com. 2022120101 10000 2400 604800 600
                        

Podemos hacer resolución inversa poniendo una ip como argumento:

ubuntu@ubuntusrv2:~$ host 162.159.24.201
201.24.159.162.in-addr.arpa domain name pointer ns1.dns-parking.com.
                        

                        
Comando dig

El comando dig actualmente es el más utilizado en Linux. Para conocer en detalle su uso desde la terminal man dig. Si entramos dig sin ningún parámetro nos devolverá lo siguiente:

ubuntu@ubuntusrv1:~$ dig

; <<>> DiG 9.16.1-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33872
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494 
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       6962    IN      NS      h.root-servers.net.
.                       6962    IN      NS      g.root-servers.net.
.                       6962    IN      NS      f.root-servers.net.
.                       6962    IN      NS      e.root-servers.net.
.                       6962    IN      NS      d.root-servers.net.
.                       6962    IN      NS      c.root-servers.net.
.                       6962    IN      NS      b.root-servers.net.
.                       6962    IN      NS      a.root-servers.net.
.                       6962    IN      NS      m.root-servers.net.
.                       6962    IN      NS      l.root-servers.net.
.                       6962    IN      NS      k.root-servers.net.
.                       6962    IN      NS      j.root-servers.net.
.                       6962    IN      NS      i.root-servers.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Dec 02 15:14:49 UTC 2022
;; MSG SIZE  rcvd: 239

                        

Lo he marcado por colores para verlo más claro. El primer bloque en color naranja contiene info de la versión del comando, cabecera y otros datos de los que no entramos en detalles.

El segundo bloque en color azul es la pregunta. Al no poner parámetros la pregunta será sobre los servidores raiz representado por un punto . y los name servers abreviado como NS. Enseguida veremos que si especificamos un dominio para consultar la pregunta cambia totalmente siendo sobre los registros tipo A de ese dominio.

El tercer bloque en color amarillo es la respuesta. En este ejemplo devuelve todos los name servers de los directorios raiz.

En el cuarto bloque tenemos que DNS usará para la consulta, fecha y hora de consulta y otros detalles estadísticos sobre tiempos de respuesta.

Si hacemos la consulta sobre un dominio:

ubuntu@ubuntusrv2:~$ dig tallerdeapps.com

; <<>> DiG 9.16.1-Ubuntu <<>> tallerdeapps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24187
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;tallerdeapps.com.              IN      A

;; ANSWER SECTION:
tallerdeapps.com.       159     IN      A       185.224.137.181

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Dec 02 16:07:20 UTC 2022
;; MSG SIZE  rcvd: 61

                        

En este segundo ejemplo también tenemos los 4 bloques. El primero con la cabecera, el segundo con la pregunta que ahora al consultar sobre un dominio utiliza la pregunta predeterminada que será sobre el registro A. Tenemos el tercer bloque con la respuesta y el último con las estadísticas y el DNS predeterminado.

Se pueden hacer consultas especificando que servidor DNS usará. Para cambiarlo se pone símbolo @seguido del DNS. Ejemplo:

dig tallerdeapps.com @8.8.8.8
                            

El comando dig permite parámetros para configurar que registro consultar. Con el parámetro -t nombre_registro seleccionamos el registro. Ejemplo: consultar el registro mx del dominio tallerdeapps.com

ubuntu@ubuntusrv1:~$ dig -t mx tallerdeapps.com

; <<>> DiG 9.16.1-Ubuntu <<>> -t mx tallerdeapps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37992
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;tallerdeapps.com.              IN      MX

;; ANSWER SECTION:
tallerdeapps.com.       7139    IN      MX      5 mx1.hostinger.es.
tallerdeapps.com.       7139    IN      MX      10 mx2.hostinger.es.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Dec 02 16:16:05 UTC 2022
;; MSG SIZE  rcvd: 97

                        

También se puede configurar el nivel de detalle de las respuestas. La respuesta estándar tiene mucha información que quizás no necesitamos y podemos eliminar.

Con el parámetro +short la respuesta es muy corta. Se limita únicamente a dar el dato que le preguntamos. Se puede combinar con otros parámetros. En este ejemplo consultamos los registros mx con respuesta corta. Se limita a darnos los servidores de correo y la prioridad.

ubuntu@ubuntusrv1:~$ dig +short -t mx tallerdeapps.com
5 mx1.hostinger.es.
10 mx2.hostinger.es.
                        

También es posible configurar cuanta información devuelva en la respuesta. Existe una larga lista de parámetros para imprimir o no ciertas partes de la respuesta. Una forma sencilla de hacerlo puede ser usar el parámetro +noall que provaca una respuesta vacía y a continuación vamos añadiendo las partes que queremos que salgan. Las combinaciones son muchas:

#Respuesta en blanco                       
dig +noall tallerdeapps.com
#Solo devuelve la respuesta
dig +noall +answer tallerdeapps.com
#Devuelve pregunta y la respuesta
ubuntu@ubuntusrv1:~$ dig +noall +question +answer tallerdeapps.com
#Que no devuelva ni comentarios ni estadísticas
dig +nocomments +nostats tallerdeapps.com
                        

La resolución inversa, encontrar un dominio a partir de la IP se hace con el parámetro -x

ubuntu@ubuntusrv1:~$ dig +short -x 8.8.8.8
dns.google.
                        
Comando nslookup

Es un comando clásico que en Linux se considera obsoleto aunque sigue funcionando muy bien. Este comando existe también en Windows por lo que conocerlo puede ser muy útil. Hay 2 modos de hacerlo funcionar:

  • Modo interactivo o modo contexto ejecutando el programa y entrando dominios y cambiando los tipos de búsqueda en tiempo real de ejecución hasta que entramos exit para finalizar
  • Modo no interactivo se ejecuta el programa desde la terminal añadiendo todos los parámetros que se estimen necesarios. Para una nueva búsqueda se debe volver a ejecutar el programa.

MODO INTERACTIVO

Vamos a verlo funcionar con ejemplos. Empezamos por el modo interactivo desde Linux entrando nslookup desde la terminal:

ubuntu@ubuntusrv2:~$ nslookup
> 
                        

El programa queda en ejecución con un prompt esperando entradas. Le ponemos un dominio y vemos que ocurre:

> tallerdeapps.com
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: tallerdeapps.com
Address: 185.224.137.181
Name: tallerdeapps.com
Address: 2a02:4780:8:252:0:2e80:9a24:1
> 
                        

La primera información que nos da es el servidor DNS local usado por Ubuntu. Ahora no es momento de profundizar en esto. Puedes mirar en https://moss.sh/es/configuracion-problematica-systemd-resolved/ donde se explica de donde sale la dirección 127.0.0.53 configurada en /etc/resolv.conf

Lo siguente que dice es que se trata de una respuesta no autoritativa. Esto quiere decir que resuelve la IP desde los datos de la caché DNS. Las respuestas autoritativas son más fiables porque es la información actualizada del archivo de zona del dominio que se guarda en los Name Servers. Recuerda que al registrar un dominio es ahí donde se graban los registros de DNS.

A continuación ya son datos del registro del dominio. De manera predeterminada devuelve los registos A y AAAA para resolución IPv4 y IPv6.

Podemos configurar el programa para que nos devuelva cualquier tipo de registro usando el comando set query=nombre_del_registro. Reemplazamos nombre_del_registro por cualquiera de los registros DNS. Probemos con soa y a partir de ahora al entrar cualquier dominio nos dará los valores de ese registro.

> set query=soa
> tallerdeapps.com
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
tallerdeapps.com
origin = ns1.dns-parking.com
mail addr = dns.hostinger.com
serial = 2022112401
refresh = 10000
retry = 2400
expire = 604800
minimum = 600
Authoritative answers can be found from:
> 
                    

Para hacer una búsqueda autoritativa debemos cambiar el name server usado por defecto por el propio que tiene registrado el dominio. El registro SOA ya nos da está información pero para ampliar los ejemplos vamos a buscar los registros ns. Para ello, tal como hemos visto pondremos set query=ns y desde este momento las consultas devolverán name servers. Una vez sabemos este dato lo fijaremos como servidor predeterminado. Los name server siempre son más de uno. Podemos usar cualquiera de ellos porque son clones.

> set query=ns
> tallerdeapps.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
tallerdeapps.com        nameserver = ns2.dns-parking.com.
tallerdeapps.com        nameserver = ns1.dns-parking.com.

Authoritative answers can be found from:
> 

Conociendo el name server lo seleccionamos con:

> server ns1.dns-parking.com

Default server: ns1.dns-parking.com
Address: 162.159.24.201#53
Default server: ns1.dns-parking.com
Address: 2400:cb00:2049:1::a29f:18c9#53
> 

Tras esto nos informa que ahora tenemos uno de los name server del dominio como predeterminado. Solo nos falta hacer la consulta que aunque da el mismo resultado ya no alerta de que se trata de una búsqueda no autoritativa.

>tallerdeapps.com
Server:         ns1.dns-parking.com
Address:        162.159.24.201#53

Name:   tallerdeapps.com
Address: 185.224.137.181
Name:   tallerdeapps.com
Address: 2a02:4780:8:252:0:2e80:9a24:1
> 

Para saber cuales son desde modo interactivo pondremos set all y nos imprimirá por pantalla que registro consultará, con cual servidor, puertos y otros detalles.

Para finalizar el modo interactivo entramos >exit.

En Windows funciona igual, la única diferencia que he encontrado es que tenemos comando help en el modo interactivo y en cambio, en Linux no está implementado. De todas maneras, no supone mucho problema porque, como siempre contamos con la ayuda de man nslookup.

Modo no interactivo

Este es el modo directo de usar el comando. Ponemos en una línea todos los parámetros que necesitemos y los muestra. Para cada búsqueda se debe ejecutar el comando.

Algunos ejemplos:

# Examinar un dominio con los registros predeterminados                                
nslookup tallerdeapps.com
# Examinar el registro txt de un dominio
nslookup -query=txt tallerdeapps.com
# Examinar un dominio con los registros predeterminados seleccionando servidor DNS                       
nslookup tallerdeapps.com 8.8.8.8
# Examinar un dominio especificando el registro txt seleccionando servidor DNS 
nslookup -query=txt tallerdeapps.com ns1.dns-parking.com
                            

Para hacer una resolución inversa inversa solamente es necesario poner la IP en lugar del dominio.

ubuntu@ubuntusrv1:~$ nslookup 8.8.8.8
8.8.8.8.in-addr.arpa    name = dns.google.