DNS (Domain Name System) es uno de los componentes cruciales que impulsan el internet. Tener una comprensión adecuada de cómo funciona el DNS puede ayudar a diagnosticar problemas con la configuración del sitio web y ampliar su comprensión de lo que está sucediendo detrás de escena.
En esta guía, hablaremos sobre algunos conceptos fundamentales de DNS para brindarle una base sólida mientras trabaja con su configuración de DNS. Esta guía también le ayudará a configurar su propio nombre de dominio o servidor DNS.
¡Comencemos!
Terminologías de dominio
Primero, necesitamos establecer una comprensión de los términos que vamos a utilizar. Es posible que ya esté familiarizado con algunos de ellos en otros contextos. Sin embargo, existen muchos términos específicos al hablar de nombres de dominio y DNS que no se discuten mucho en otras áreas de la informática.
-
Sistema de Nombres de Dominio
El sistema de nombres de dominio (DNS, por sus siglas en inglés) es un sistema de red implementado que traduce nombres de dominio amigables para los humanos en direcciones IP únicas.
-
Nombre de dominio
Un nombre de dominio se refiere al nombre amigable para los humanos que se utiliza para asociarse con un recurso de internet. Por ejemplo, “cloudsigma.com” es un nombre de dominio. Algunos pueden argumentar que solo la parte “cloudsigma” es el nombre de dominio, pero generalmente se refiere al todo.
La URL “cloudsigma.com” está asociada con los servidores propiedad de CloudSigma. Al ingresar la URL en el navegador web, este se comunica con el DNS para conectarse a la dirección IP del servidor de destino.
-
Dirección IP
Una dirección IP actúa como una dirección de red para un dispositivo conectado a la red. Cada dirección IP debe ser única dentro de la red. En el contexto de los sitios web, la red es, la mayoría de las veces, todo el internet.
Existen dos tipos de direcciones IP:
-
- IPv4: Esta es la forma más común de dirección IP. Se escribe como un conjunto de cuatro números, cada conjunto con hasta 3 dígitos. Cada conjunto está separado por un punto. El rango de IPv4 va desde 0.0.0.0 a 255.255.255.255.
-
IPv6: Es un estándar más moderno que se desarrolló para resolver el problema de el agotamiento de direcciones IPv4. IPv4 admite hasta 232 direcciones únicas, mientras que IPv6 admite hasta 2128 direcciones. Cualquier dirección IPv6 se escribe en dígitos hexadecimales. Puede contener hasta 32 dígitos, divididos en 8 secciones (4 dígitos cada sección). Cada sección está separada por dos puntos (:).
Dominio de nivel superior
Un dominio de nivel superior (TLD, por sus siglas en inglés) es la parte más general del dominio. Se refiere a la parte situada más a la derecha (separada por un punto). Algunos de los dominios de nivel superior más comunes incluyen:
-
“com”
-
“net”
-
“org”
-
“edu”
-
“io”
-
“gov”
En términos de nombres de dominio, estos dominios están en la cima de la jerarquía. La ICANN (Corporación de Internet para la Asignación de Nombres y Números) puede emitir un permiso para el control de ciertas partes sobre los dominios de nivel superior. Con el permiso, estas partes pueden distribuir nombres de dominio bajo el TLD (generalmente a través de un registrador de dominios).
-
Hosts
En el dominio, el propietario puede especificar hosts individuales, refiriéndose a máquinas/servicios separados accesibles a través de un dominio. Por ejemplo, es una práctica común hacer que los servidores web sean accesibles a través del dominio básico ( example.com) y la definición de “host” “www ( www.example.com).
Es posible tener hosts adicionales bajo el dominio general, por ejemplo, acceso a la API a través del host “api” ( api.example.com), acceso FTP a través del host “ftp” o “files” ( ftp.example.com o files.example.com).
Tenga en cuenta que los nombres de dominio pueden ser arbitrarios siempre que sean únicos dentro del dominio.
-
Subdominio
Un subdominio es un tema relacionado con los hosts. El DNS funciona en una jerarquía. Un TLD puede tener muchos dominios bajo él. Por ejemplo, “ example.com”, “ cloudsigma.com”, etc. están todos bajo el TLD “com”. En ese sentido, un subdominio es una referencia a cualquier dominio que forma parte del dominio de destino. Por lo tanto, podemos decir que “example.com” es un subdominio de “com”. Generalmente, la parte “example” se denomina SLD (dominio de segundo nivel).
Del mismo modo, un dominio puede controlar todos los “subdominios” ubicados bajo él. Esto es usualmente a lo que se refiere el término “subdominio”. Por ejemplo, “ history.example.com” es un subdominio de “ example.com”.
La diferencia clave entre un nombre de host y un subdominio es que un host define una computadora/recurso, mientras que un subdominio extiende el dominio principal. Siempre que hablemos de subdominios o hosts, puede asegurarse de ello mirando la parte más a la izquierda de un dominio, ya que es la más específica. Así es como funciona el DNS: desde lo más específico (el lado más a la izquierda) hasta lo menos específico (el lado más a la derecha).
-
Nombre de dominio completamente calificado
Un nombre de dominio completamente calificado (FQDN, por sus siglas en inglés) se refiere a un nombre de dominio absoluto. En el sistema DNS, los dominios se pueden dar de forma relativa entre sí. Esto puede generar cierta ambigüedad. Sin embargo, un FQDN es un nombre absoluto que se refiere a la raíz absoluta del sistema de nombres de dominio.
Significa que el FQDN especifica cada dominio principal, incluyendo el TLD. Un ejemplo adecuado sería “ mail.google.com”. En casos específicos, es posible que el FQDN no termine con un punto, pero debe tener un punto final (requerido por los estándares de la ICANN).
-
Servidor de nombres
Un servidor de nombres es una computadora dedicada a traducir nombres de dominio a direcciones IP. Los servidores de nombres soportan la mayor parte de la carga en el sistema DNS. Debido a que el número total de solicitudes de traducción de dominios es demasiado alto para que lo maneje un solo servidor, las solicitudes a menudo se redirigen a otros servidores de nombres para compensar la presión.
Un servidor de nombres puede ser “autoritativo”, lo que significa que solo responde a consultas sobre dominios bajo su control. Dichos servidores pueden retransmitir la solicitud a otros servidores de nombres o servir una copia en caché de los datos de otros servidores de nombres.
-
Archivo de zona
Un archivo de zona es un archivo de texto que contiene las asociaciones entre nombres de dominio y direcciones IP. Sirve como la base de datos del sistema DNS. Este es el catálogo que utiliza el DNS para buscar con qué dirección IP contactar al completar la solicitud de un usuario para un determinado nombre de dominio.
Generalmente, los servidores de nombres alojan los archivos de zona y definen los recursos disponibles bajo un solo dominio. También pueden contener información sobre a dónde ir para obtener esa información.
-
Registros
Un archivo de zona consta de numerosos registros. Aquí, un registro se define como una única asociación entre un recurso y un nombre. Los registros pueden ser la asociación de un nombre de dominio a una dirección IP, recursos disponibles bajo un dominio específico o referencias a lugares para obtener la información.
DNS en acción
Hasta ahora, nos hemos familiarizado con algunas terminologías comunes relacionadas con el DNS. Sin embargo, ¿cómo funciona realmente el sistema? El sistema puede parecer muy simple a primera vista. No obstante, profundizar en los detalles revelará su verdadera complejidad. En general, el sistema DNS es importante para la adopción generalizada de Internet.
-
Servidores raíz
El DNS, en su esencia, funciona de manera jerárquica. En la cima del sistema se encuentran los “servidores raíz”. Estos servidores están bajo el control de varias organizaciones. La autoridad de estos servidores es delegada por la ICANN (Corporación de Internet para la Asignación de Nombres y Números).
Actualmente, hay alrededor de 13 servidores raíz en funcionamiento. Sin embargo, debido a la carga, cada uno de estos servidores está replicado. Es importante tener en cuenta que todos los servidores espejo comparten la misma dirección IP que el servidor raíz. Cada vez que se realiza una solicitud al servidor raíz, la solicitud se redirige al espejo más cercano de ese servidor.
¿Cuáles son las funciones de los servidores raíz? Ofrecen información sobre los dominios de nivel superior. Cada vez que un servidor de nombres de nivel inferior no logra resolver una solicitud, esta se redirige al servidor raíz del dominio.
Sin embargo, el servidor raíz en realidad no conoce la ubicación del dominio. Solo redirige la solicitud que manejará el dominio de nivel superior específicamente solicitado. Por ejemplo, si se realiza una solicitud para “ blog.cloudsigma.com”, el servidor raíz no lo tendrá en sus registros. Buscará en sus archivos de zona pero no habrá ningún registro para él. En su lugar, reconocerá el TLD “com” y redirigirá a la entidad solicitante al servidor de nombres que maneja las direcciones “com”.
-
Servidores TLD
Continuando con nuestro ejemplo anterior, la entidad solicitante ahora enviará la solicitud a la dirección IP (proporcionada por el servidor raíz). En el caso de “ blog.cloudsigma.com”, el servidor de nombres “com” buscará en sus registros en sus archivos de zona.
No habrá un registro correspondiente a la solicitud. Sin embargo, encontrará un registro que enumera la dirección IP del servidor de nombres responsable de “ cloudsigma.com”.
-
Servidor de nombres a nivel de dominio
Ahora, la entidad solicitante tiene la dirección IP del servidor de nombres que realmente aloja la información sobre “ blog.cloudsigma.com”. Ahora enviará una nueva solicitud al servidor, pidiendo resolver “www.cloudsigma.com”.
Al igual que antes, el servidor de nombres verificará sus archivos de zona y encontrará el asociado con “ cloudsigma.com”. Dentro de este archivo residirá una entrada para el host “www”. Este registro describe dónde se encuentra el host. La respuesta final se transmite luego a la entidad solicitante.
-
Servidor de nombres resolutivo
En el ejemplo, mencionamos una entidad solicitante. ¿Qué es? En la mayoría de los casos, el solicitante será un “servidor de nombres resolutivo”. Es un servidor que está configurado para hacer preguntas a otros servidores. Actúa como un servidor intermediario para los usuarios. Almacena en caché los resultados para mejorar la velocidad.
Cualquier usuario normalmente tendrá un par de servidores de nombres resolutivos configurados en su sistema. Generalmente, los servidores de nombres resolutivos son ofrecidos por el ISP u otras organizaciones. Por ejemplo, Google ofrece servidores DNS resolutivos públicos para realizar consultas. Puede configurarlo manualmente en su sistema.
Al ingresar una URL en el navegador web, este busca la ubicación del recurso. Primero, la búsqueda se realiza localmente. Esto incluye el archivo “hosts” (y algunas otras ubicaciones). Si no se encuentra, la solicitud se envía al servidor de nombres resolutivo. Después de recibir la solicitud, el servidor de nombres resolutivo busca la respuesta en su caché. Si no la encuentra, sigue los pasos mencionados anteriormente.
Los servidores de nombres resolutivos simplifican el proceso de solicitud para el usuario final. El cliente solo tiene que preguntar a los servidores de nombres resolutivos por la ubicación de un recurso. El servidor de nombres investigará y devolverá la respuesta final.
-
Archivos de zona
Ya discutimos los conceptos de “archivos de zona” y “registros”. Bueno, ¿cómo funcionan?
Los archivos de zona actúan como la base de datos para los servidores de nombres, almacenando la información sobre los dominios que conocen. Todos los dominios que conoce un servidor de nombres se almacenarán en su archivo de zona. Sin embargo, la mayoría de las solicitudes que llegan a un servidor de nombres no se resuelven mediante el archivo de zona. Si la configuración del servidor es para manejar consultas recursivas (servidores de nombres resolutivos, por ejemplo), entonces devolverá la respuesta. De lo contrario, redirigirá a la parte solicitante a un lugar diferente para buscar a continuación.
Cuantos más archivos de zona aloje un servidor de nombres, más autoritativas serán sus respuestas. Los archivos de zona describen una “zona” DNS (un subconjunto de todo el sistema de nombres DNS). Generalmente, un archivo de zona contiene los datos de configuración de un solo dominio. Puede tener numerosos registros que definen la ubicación de los recursos del dominio en cuestión.
El parámetro $ORIGIN de una zona es igual al nivel más alto de autoridad de la zona. Por ejemplo, un archivo de zona para “ cloudsigma.com” tendrá su $ORIGIN como “ cloudsigma.com’. El valor del parámetro se puede almacenar al principio del archivo de zona o en la configuración del servidor DNS. De cualquier manera, el parámetro describe de qué zona es autoritativo el archivo.
El $TTL parámetro establece la información de “tiempo de vida” del resultado que proporciona. Se puede describir como un temporizador que un servidor de caché puede usar para realizar un seguimiento de la validez de las respuestas almacenadas en caché. Si el valor de TTL se agota, la respuesta ya no es válida y se descarta.
-
Tipos de registros
Los archivos de zona constan de numerosos registros. Ahora bien, existen diferentes tipos de registros. A continuación, repasaremos algunos de los tipos de registros más comunes (y obligatorios):
Registros SOA
El registro de Inicio de Autoridad (SOA, por sus siglas en inglés) es obligatorio en todos los archivos de zona. Debe ser el primer registro real en el archivo. Sin embargo, entradas como $ORIGIN o $TTL tienen permitido aparecer antes.
El registro SOA es uno de los tipos de registros más complejos. Su estructura se ve algo así:
|
1 2 3 4 5 6 7 |
example.com. IN SOA ns1.example.com. admin.example.com. ( 12083 ; <serial_number> 3h ; <refresh_interval> 30m ; <retry_interval> 3w ; <expiry_time> 1h ; <negative_TTL> ) |
Vamos a desglosarlo:
-
- example.com: Esta parte define la raíz de la zona. En este ejemplo, el archivo de zona es para el dominio “ example.com’. A veces, el valor puede ser reemplazado por @ (un marcador de posición para sustituir el valor de $ORIGIN).
-
IN SOA: El término “IN” significa “internet”. Lo encontrará en muchos registros. El término “SOA” indica que es un registro SOA.
-
ns1.example.com: Este valor contiene el servidor de nombres principal para el dominio “ example.com’. Los servidores de nombres pueden ser principales o secundarios. Si se configuró con DNS dinámico, entonces debe haber un servidor “principal”. Si no se configuró ningún DNS dinámico, entonces será uno de los servidores de nombres principales.
-
admin.example.com: La dirección de correo electrónico del administrador de la zona va aquí. Tenga en cuenta que el @ se reemplaza por . aquí. Si la dirección de correo electrónico original contiene un punto, entonces se reemplaza por un \. Por ejemplo, “ my.domain@example.com’ se convertiría en “ my\domain.example.com”.
-
12083: Es el número de serie del archivo de zona. Cada vez que se edita el archivo de zona, el número debe actualizarse para que el archivo se propague correctamente. Los servidores secundarios utilizan este número de serie para realizar un seguimiento de si sus propios archivos de zona están actualizados.
-
3h: Representa el intervalo de actualización de la zona. Los servidores secundarios esperarán esta cantidad de tiempo antes de buscar actualizaciones del archivo de zona.
-
30m: Este valor representa el intervalo de reintento de la zona. Si un servidor secundario no logra conectarse al servidor principal una vez que finaliza el período de actualización, esperará esta cantidad de tiempo antes de volver a consultar al principal.
-
3w: Este valor representa el período de expiración. Si un servidor secundario no logra conectarse al servidor principal durante esta cantidad de tiempo, dejará de devolver respuestas como “autoritativas”.
-
1h: Este valor representa la cantidad de tiempo que el servidor de nombres almacenará en caché un error de nombre si no se encontró en su archivo de zona.
Registros A y AAAA
Estos registros establecen una asignación entre un host y una dirección IP. Aquí, el registro “A” representa la asignación IPv4 al host y AAAA la asignación IPv6.
Esta es la estructura fundamental de los registros A y AAAA:
|
1 2 |
<host> IN A <IPv4_address> <host> IN AAAA <IPv6_address> |
En el ejemplo del registro SOA, llamamos al servidor de nombres “ ns1.exampel.com’. El servidor de nombres pertenece al dominio “ example.com’. Así es como se vería su registro A:
|
1 |
ns1 IN A 111.222.111.222 |
Observe que no tuvimos que proporcionar el nombre completo. Con solo el nombre de host (sin el FQDN), el servidor DNS puede completar el resto con el valor de $ORIGIN. Sin embargo, todavía podemos usar el FQDN:
|
1 |
ns1.example.com. IN A 222.111.222.111 |
Aquí se explica cómo definir el servidor web como “www”:
|
1 |
www IN A 111.111.111.111 |
También deberíamos incluir el mapeo al dominio base. La entrada se vería así:
|
1 |
example.com. IN A 222.222.222.222 |
Alternativamente, podemos usar el @ símbolo para denotar el dominio base (en lugar de su nombre completo):
|
1 |
@ IN A 222.222.222.222 |
Es una buena práctica incluir una entrada de comodín que permita la opción de resolver cualquier cosa bajo este dominio que no se haya definido explícitamente:
|
1 |
* IN A 222.222.222.222 |
La misma estructura se aplica a los registros AAAA. La única diferencia son las direcciones IPv6.
Registros CNAME
Los registros CNAME actúan como un alias para el nombre canónico del servidor (definido por un registro A o AAAA). Eche un vistazo al siguiente ejemplo:
|
1 2 |
server1 IN A 111.111.111.111 www IN CNAME server1 |
Aquí, usamos “server1” como un alias para definir el nombre “www”. Tenga en cuenta que tales atajos conllevan costos de rendimiento, ya que el servidor tiene que realizar consultas adicionales para obtener la respuesta final. Dependiendo del número de capas de alias, esto puede causar fácilmente un gran costo de rendimiento. Sin embargo, hay un caso específico que se beneficia del alias CNAME, por ejemplo, proporcionar un recurso fuera de la zona actual.
Registros MX
Los registros MX definen los intercambios de correo para el dominio. Ayudan a que el correo electrónico llegue correctamente al servidor. A diferencia de otros registros, los registros MX no mapean un host a algo, ya que son aplicables para toda la zona. Es por eso que los registros MX se ven algo así:
|
1 |
IN MX 10 mail.domain.com |
Observe que no hay un nombre de host al principio de la entrada. También notará que hay un valor adicional en la línea. Es el número de preferencia que ayuda a decidir a qué servidor enviar el correo (si hay varios servidores de correo definidos). Cuanto menor sea el número, mayor será la prioridad.
Un registro MX debe apuntar a un host definido por un registro A o AAAA (not por CNAME). Teniendo eso en cuenta, si hay dos servidores de correo configurados, los registros se verían así:
|
1 2 3 4 |
IN MX 10 mail1.domain.com IN MX 50 mail2.domain.com mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 |
En este ejemplo, a juzgar por el número de preferencia, “mail1” es el servidor preferible sobre “mail2”. Podemos acortar aún más el código omitiendo el nombre de dominio completo:
|
1 2 3 4 |
IN MX 10 mail1 IN MX 50 mail2 mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 |
Registros NS
Estos registros definen los servidores de nombres para la zona en particular. Ahora, la pregunta obvia es, si el archivo de zona reside dentro del servidor de nombres, ¿por qué requiere una referencia a sí mismo? Una respuesta a la pregunta son los múltiples mecanismos de almacenamiento en caché del sistema DNS. El archivo de zona en realidad puede ser una copia almacenada en caché en otros servidores.
Al igual que los registros MX, los registros NS se aplican a toda la zona. Por lo tanto, no tienen ningún host específico por defecto. Las entradas de registro NS se verán algo así:
|
1 2 |
IN NS ns1.domain.com. IN NS ns2.domain.com. |
Se recomienda tener dos servidores de nombres definidos en caso de que un servidor no funcione correctamente. Además, la mayoría de los servidores DNS rechazarán un archivo de zona si contiene un solo servidor de nombres.
También debe incluir el mapeo de los hosts con registros A o AAAA:
|
1 2 3 4 |
IN NS ns1.domain.com IN NS ns2.domain.com ns1 IN A 111.222.111.111 ns2 IN A 123.211.111.233 |
Registros PTR
Los registros PTR son el inverso de un registro A o AAAA clásico. Estos registros se utilizan para definir un nombre asociado a una dirección IP. Estos registros tienen una propiedad única, ya que comienzan en la .arpa raíz y representan al propietario de la dirección IP. Son los RIR (Registros Regionales de Internet) los que distribuyen las direcciones IP a las organizaciones y proveedores de servicios. Los RIR incluyen APNIC, AFRINIC, LACNIC, RIPE NCC y ARIN.
Por ejemplo, un registro PTR para 111.222.333.444 se vería algo así:
|
1 |
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com |
En el siguiente ejemplo de registro PTR, eche un vistazo al servidor DNS IPv6 de Google 2001:4860:4860::8888:
|
1 |
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com |
Podemos usar la herramienta dig con la opción -x para buscar el nombre DNS inverso de una dirección IP. Por ejemplo, consulte la dirección IP de DNS inverso de 8.8.4.4:
|
1 |
dig -x 8.8.4.4 |

Los servidores de Internet utilizan registros PTR para realizar un seguimiento de los nombres de dominio en las entradas de registro, tomar decisiones informadas sobre el manejo de spam y mostrar información fácil de leer sobre otros dispositivos.
Los servidores de correo electrónico de uso común buscarán el registro PTR de la dirección IP desde la que se envió el correo electrónico. Si el registro PTR está en blanco, existe una alta probabilidad de que el correo electrónico sea spam (por lo tanto, rechazado). Tenga en cuenta que la coincidencia entre el FQDN y el nombre de dominio del registro PTR no es la preocupación. El factor importante es si un registro PTR válido está asociado con un registro A directo coincidente y correspondiente.
Generalmente, los enrutadores de red en Internet tienen registros PTR que corresponden a su ubicación física. Por ejemplo, “NYC” o “CHI” son referencias válidas para enrutadores ubicados en Nueva York y Chicago. Esta técnica es beneficiosa al realizar un traceroute o MTR y revisar la ruta que toman los paquetes.
Registros CAA
Estos registros especifican las CA (Autoridades de Certificación) que pueden emitir la certificación SSL/TLS para su dominio. Desde el 8 de septiembre de 2017, todas las CA deben verificar los registros CAA antes de emitir un certificado. Si no existe ningún registro de CA, cualquier CA puede emitir un certificado. De lo contrario, solo las CA específicas tienen permitido emitir certificados. Los registros CAA se pueden aplicar a hosts individuales o a un dominio completo.
Aquí tiene un ejemplo de un registro CAA:
|
1 |
example.com. IN CAA 0 issue "letsencrypt.org" |
La parte específica de CAA de la entrada es 0 issue "letsencrypt.org". Hay tres partes involucradas en esta sección:
- Indicadores: Es un valor entero que indica cómo debe manejar una CA las etiquetas que no entiende. Si el valor del indicador se establece en 0, entonces el registro se ignorará. Si el valor es 1, entonces la CA debe negarse a emitir el certificado.
- Etiquetas: Estas son cadenas que denotan el propósito de un registro CAA. Actualmente, los valores válidos incluyen issue (que autoriza a una CA a emitir certificados para un dominio específico), issuewild (que autoriza certificados comodín), y iodef (que define una URL donde las CA informan violaciones de políticas).
- Valores: Estas son cadenas asociadas con la etiqueta del registro. Si la etiqueta es issue o issuewild, el valor generalmente será el dominio de la CA a la que le está otorgando el permiso. Si la etiqueta es iodef, será una URL de un formulario de contacto o un enlace mailto: para comentarios por correo electrónico.
Podemos usar la herramienta dig para obtener los registros CAA:
|
1 |
dig example.com type257 |

Para obtener información más detallada sobre los registros CAA, consulte RFC 6844.
Reflexiones finales
Esta guía describe varias terminologías relacionadas con el DNS. También describe cómo se integran todos los componentes. Con esta perspectiva general detallada en mente, debería tener una buena comprensión del funcionamiento del sistema DNS. Aunque la idea general es simple y fácil de entender, las complejidades se vuelven difíciles muy rápidamente. Para los administradores sin experiencia, puede resultar difícil aplicar estos conceptos y estrategias.
¿Es cliente de CloudSigma? Entonces consulte la gestión y actualización de registros de DNS inverso/PTR para su infraestructura de CloudSigma.
¡Feliz computación!
Comentarios
Aún no hay comentarios. Sea el primero.