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:
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:
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.
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.
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.
Los registros más importantes usados en el archivo de zona son:
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.
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.
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 |
El registro MX dirige el correo a un servidor de correo electrónico.
Tipo | Nombre | Prioridad | Contenido | TTL |
---|---|---|---|---|
MX | @ | 5 | mx1.srvcorreo.es | 14400 |
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.
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.
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 |
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.
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.
Los más comunes son dig, nslookup y host. A continuación algunos ejemplos con ellos.
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.
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.
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:
exit
para finalizar
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
.
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.