Diferencia entre DNS Autoritativo y Recursivo

En un sistema de nombres de dominio (DNS), existen dos tipos principales de servidores: autoritativos y recursivos. Cada uno cumple un rol fundamental en la resolución de nombres de dominio en Internet.

DNS Autoritativo

Un servidor DNS autoritativo es aquel que tiene la autoridad sobre un dominio específico. Es el responsable de almacenar y proporcionar las respuestas oficiales sobre los registros DNS de un dominio.

Características del DNS Autoritativo:

Almacena registros DNS de manera oficial (A, AAAA, MX, NS, TXT, etc.).
Responde con datos definitivos y no necesita consultar a otros servidores.
Ejemplo: Si consultas el dominio example.com, el DNS autoritativo de example.com te dirá cuál es la dirección IP asociada.

Tipos de DNS Autoritativos:

Primario (Master): Contiene los registros DNS originales y permite modificaciones.
Secundario (Slave): Obtiene copias del primario mediante transferencia de zona (AXFR) y actúa como respaldo.

Ejemplo de consulta a un DNS Autoritativo:

dig NS example.com @ns1.example.com

Casos de uso:

Servidores de nombres de proveedores de hosting.
Administradores de dominios públicos y privados.

DNS Recursivo

Un servidor DNS recursivo actúa como intermediario entre los clientes y los servidores DNS autoritativos. Su función es buscar la respuesta preguntando a otros servidores hasta encontrar la información.

Características del DNS Recursivo:

No almacena registros definitivos, sino que los consulta según sea necesario.
Hace múltiples consultas en caso de no tener la respuesta en caché.
Ejemplo: Cuando escribes example.com en tu navegador, tu ISP consulta un servidor recursivo para encontrar la dirección IP correcta.

Ejemplo de consulta a un DNS Recursivo:

dig example.com @8.8.8.8

Casos de uso:

Resolución de nombres en proveedores de Internet (ISP).
Caché de respuestas DNS para mejorar velocidad.
Protección mediante filtros de seguridad (RPZ, listas negras).

Comparación entre DNS Autoritativo y Recursivo

Comparación de DNS Autoritativo vs. Recursivo
Característica	DNS Autoritativo	DNS Recursivo
Propósito	Almacenar y responder con información oficial del dominio	Resolver consultas preguntando a otros servidores
Modifica registros	Sí, administra zonas DNS	No, solo consulta
Caché	No almacena respuestas temporales	Puede almacenar respuestas para optimizar consultas
Fuente de datos	Base de datos propia del dominio	Otras fuentes como servidores raíz y autoritativos

Tutorial de Troubleshooting de Delegación en DNS

Este tutorial explica cómo verificar la delegación de un dominio usando servidores DNS padres, como a.lactld.org, y herramientas como dig.

Concepto de Delegación en DNS

La delegación en DNS ocurre cuando una zona de nivel superior (como com.ar) apunta a los servidores de nombres responsables de una subzona (como eltonga.com.ar).

Para validar si un dominio está correctamente delegado, se siguen estos pasos:

Identificar los servidores DNS padres que administran la zona superior.
Consultar directamente a estos servidores para verificar si la delegación es correcta.

Atención

Para realizar cualquier tipo de troubleshooting en los DNS, no se deben usar los típicos servidores 8.8.8.8 o 1.1.1.1, ya que estos pueden modificar los resultados, ocultando respuestas como SERVFAIL o NXDOMAIN. En su lugar, siempre consulta los servidores autoritativos o del registrar correspondiente.

Paso 1: Obtener los Servidores Padres

dig NS com.ar

Nos da como resultado:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> ns com.ar
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35644
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5fd95c77c522a1c70100000067abac058f8c94d25791aa63 (good)
;; QUESTION SECTION:
;com.ar.                                IN      NS

;; ANSWER SECTION:
com.ar.                 6685    IN      NS      f.dns.ar.
com.ar.                 6685    IN      NS      c.dns.ar.
com.ar.                 6685    IN      NS      e.dns.ar.
com.ar.                 6685    IN      NS      d.dns.ar.
com.ar.                 6685    IN      NS      a.lactld.org.

;; ADDITIONAL SECTION:
a.lactld.org.           67759   IN      A       200.0.68.10
c.dns.ar.               1092    IN      A       200.108.148.50
d.dns.ar.               1092    IN      A       192.140.126.50
e.dns.ar.               1092    IN      A       170.238.66.50
f.dns.ar.               1092    IN      A       130.59.31.20
a.lactld.org.           69915   IN      AAAA    2801:14:a000::10
c.dns.ar.               1572    IN      AAAA    2801:140:10::10
d.dns.ar.               1572    IN      AAAA    2801:140:dddd::50
e.dns.ar.               1572    IN      AAAA    2801:140:eeee::50
f.dns.ar.               1572    IN      AAAA    2001:620:0:ff::20

;; Query time: 0 msec
;; SERVER: 190.185.105.10#53(190.185.105.10) (UDP)
;; WHEN: Tue Feb 11 16:59:01 -03 2025
;; MSG SIZE  rcvd: 379

Paso 2: Consultar la Delegación del Dominio

dig NS eltonga.com.ar @a.lactld.org

Nos da como resultado:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> NS eltonga.com.ar @a.lactld.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13822
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0300b2c01968a8d60100000067abaca7e3f42645a49647e6 (good)
;; QUESTION SECTION:
;eltonga.com.ar.                        IN      NS

;; AUTHORITY SECTION:
eltonga.com.ar.         7200    IN      NS      globaldns1.planisys.net.
eltonga.com.ar.         7200    IN      NS      globaldns2.planisys.net.

;; Query time: 128 msec
;; SERVER: 200.0.68.10#53(a.lactld.org) (UDP)
;; WHEN: Tue Feb 11 17:01:43 -03 2025
;; MSG SIZE  rcvd: 133

Paso 3: Verificar con el Registrar

Para comprobar si el dominio está correctamente delegado en su registrar, ejecutamos:

whois -h whois.nic.ar eltonga.com.ar

Ejemplo de salida:

domain:         eltonga.com.ar
registrant:     XXXXXXXXXXXXXXXX
registrar:      nicar
registered:     2022-10-21 13:55:54.125063
nserver:        globaldns1.planisys.net ()
nserver:        globaldns2.planisys.net ()

Paso 4: Verificar la Resolución Completa

Para asegurarnos de que los servidores delegados responden correctamente:

dig A eltonga.com.ar @globaldns1.planisys.net

Si el servidor responde con una dirección IP válida, la delegación es correcta.

Paso 5: Verificación de Propagación DNS

A veces, los cambios en la delegación pueden tardar en propagarse. Para verificarlo:

Usar herramientas web: - https://dnschecker.org/ - https://www.whatsmydns.net/
Consultar desde múltiples servidores: - Google DNS:
dig eltonga.com.ar @8.8.8.8
- Cloudflare DNS: .. code-block:: bash
  
  dig eltonga.com.ar @1.1.1.1

Paso 6: Verificación del Registro SOA

Para asegurarnos de que el dominio tiene un registro SOA válido, podemos ejecutar:

dig SOA eltonga.com.ar @globaldns1.planisys.net

Errores comunes en la delegación DNS

Si la delegación de un dominio no está configurada correctamente, se pueden recibir errores como:

NXDOMAIN: Indica que el dominio no existe.
SERVFAIL: Problemas en la configuración del servidor DNS autoritativo.
REFUSED: El servidor DNS no permite consultas externas.
No response: El servidor DNS no está respondiendo correctamente.

Conclusión

Consultar primero a los servidores de la zona superior para verificar la delegación.
Si la delegación es correcta, los servidores listados en la AUTHORITY SECTION deberían responder consultas sobre el dominio.
Verificar la propagación y la configuración en el registrar para evitar problemas.
Revisar registros SOA, A, AAAA, MX y TXT para garantizar un funcionamiento adecuado.

Este método permite diagnosticar problemas de delegación y validar si un dominio está correctamente configurado en su jerarquía DNS.