DNS «Domain name System», como funciona y se configura.
El DNS «Domain name System», sistema de nombres de dominio en español, es un sistema de nomenclatura descentralizado y jerárquico para equipos conectados a internet, a redes IP e incluso a redes privadas. Consiste en bases de datos que asocian nombres de dominio a IPs, es decir, traduce nombres de dominio, inteligibles para los humanos «URLs» a identificadores binarios asociados con los equipos conectados a la red «direcciones IP».
Esto es necesario porque cada dispositivo conectado a Internet tiene una dirección IP única que otros dispositivos necesitan para poder encontrarlo.
Los servidores DNS evitan la necesidad de que, cuando queremos acceder a una web, memoricemos direcciones IP tales como 174.30.101.254 si utilizamos el protocolo «Internet Protocol version 4» o «IPv4»(binarias) o direcciones IP aun más complejas si el protocolo es la version 6 «IPv6» como 2001:0db8:85a3:0000:1319:8a2e:0370:7344 (Hexadecimales).
El DNS, como base de datos, es capaz de asociar otros tipos diferentes de información a cada nombre, además de la asignación de nombres de dominio a direcciones IP, también se ocupa de la localización de los servidores de correo electrónico de cada dominio.
Veámoslo de una forma más clara. Si queremos acceder a la página de google, todos ponemos en el navegador «www.google.com» y no su IP. La aplicación consulta primero a la cache de nuestro equipo, por si la tiene de una anterior búsqueda, y si no la tiene consultará los DNS que tenemos configurados en nuestro S.O. o en nuestro router. A nadie se le ocurre poner en el navegador 216.58.210.163 para ir a Google, eso lo resuelve el DNS.
El nombre de dominio, además de ser más fácil de recordar, es más fiable. La dirección IP puede cambiar por variadas razones sin que tenga que cambiar el nombre del sitio web.
Sumario
- Un poco de historia
- Estructura del sistema
- Como funciona el sistema
- Tipos de registros DNS
- Configuración de un DNS en una DMZ privada
Un poco de historia
El DNS nació por la necesidad de recordar los nombres de los servidores conectados a internet.
Inicialmente esta asociación de nombres de máquina y dirección se guardaba en un fichero llamado «hosts». Actualmente, en sistemas Linux, podemos utilizar este fichero para conectar equipos en una red privada por ssh, por ejemplo.
El aumento de equipos en internet hizo que este sistema se quedara obsoleto para tantos y tantos equipos. Por ello en 1983 Jon Postel da un primer paso en el planeamiento RFC 881. A partir de este momento se suceden los cambios en el sistema, varios ese mismo año y luego en 1984 y 1987 se definió lo que hoy en día se ha convertido en el DNS.
En esta época inicial había un servidor maestro asistido por más servidores esclavos. Estos últimos se tenían que actualizar constantemente con el problema que esto suponía.
Con los años se fue mejorando el sistema con las transferencias incrementales entre los servidores, con la definición de cambios dinámicos que permitían cambios en los registros, y la inclusión de caracteres de otros idiomas.
Existen 13 servidores raíz en todo Internet, cuyos nombres están formados por una letra de la A a la L del siguiente modo: letra.root-servers.net. Originalmente 10 estaban en EUA y los otros tres en Estocolmo, Amsterdam y Tokio. Actualmente hay copias redundantes en muchas localizaciones geográficas.
Todo el sistema está supervisado por «DNS Root Server System Advisory Committee», dependiente de la ICANN, no obstante, la zona raíz está controlada por el Departamento de Comercio de Estados Unidos.
Estructura del sistema
El sistema de nombres de dominio se conforma de tres componentes principales
- El Cliente: En nuestra máquina se ejecuta un programa que genera las peticiones al DNS. Cuando solicitamos la página www.weblinus.com, este programa pregunta a los servidores DNS cual es la IP asociada a este dominio.
- Los servidores DNS: Reciben la consulta de los clientes y facilitan la IP correspondiente. Cuando este primer servidor no tiene la información solicitada tiene la capacidad de hacer la consulta a otro servidor (recursividad). Más adelante veremos como funciona.
- Las Zonas de Autoridad: Cada servidor es responsable de unas zonas sobre las que tiene autoridad. En estas zonas habrán muchos dominios y subdominios.
Para entender la sintaxis que utiliza, un nombre de dominio esta formado por dos o más partes denominadas etiquetas, separadas por puntos «.». Por ejemplo, www.weblinus.com. Estas etiquetas se leen de derecha a izquierda.
- com: Es el dominio de nivel superior «TLD» Top Level Domain.
- weblinus: Cada etiqueta hacia la izquierda define un subdominio del TLD. Es una dependencia relativa, que puede tener hasta 127 niveles, conteniendo etiquetas de hasta 63 caracteres, pero restringido a que el nombre del dominio no exceda los 255 caracteres.
- www: Es el nombre de host «hostname». El nombre de la máquina. Todo lo demás es la ruta hasta este equipo.
Todo esto está estructurado en forma jerárquica, donde cada dominio o subdominio tiene una zona de autoridad que contiene la información sobre los inferiores.

Como vemos al inicio de la jerarquía están los servidores raíz (root) que se representan por un punto, aunque este punto no es necesario ponerlo. Así el nombre de dominio completo de este blog (FQDN) «Fully Qualified Domain Name», sería www.weblinus.com. , donde el último punto representa el dominio raiz.
Como funciona el sistema
La resolución de nombres se realiza de forma transparente para el usuario por las aplicaciones del cliente como son: navegadores, clientes de correo y otras aplicaciones que usan Internet. Los usuarios no se comunican directamente con el servidor DNS.
Cuando realizamos una petición que requiere intervención del DNS, el primer paso es consultar el DNS de nuestro sistema local. El S.O. comprueba si tiene los datos en memoria cache y si no los tiene, realizará la consulta a los servidores DNS configurados en el sistema operativo o, casi siempre, a los establecidos en nuestro router por la ISP que nos presta los servicios. Esto se puede cambiar y usar servicios de resolución de nombres de dominio gratuitos o de pago si buscamos rapidez y seguridad.

El procedimiento se repite. Si el servidor consultado no tiene la información, iniciará la búsqueda de manera recursiva, bajando el árbol invertido, hasta encontrar al que por fin la tenga. Cuando sea así servirá la respuesta. Esto se llama búsqueda recursiva.
Para el transporte de las peticiones y respuestas se utiliza el protocolo UDP, por ser más rápido, aunque en ocasiones específicas se emplea el protocolo TCP.

Tipos de consultas
En la práctica, la consulta de un host a un DNS local es recursiva, mientras que las consultas que realiza el DNS local son iterativas. Las consultas iterativas sólo se realizan en caso de que el servidor DNS local no posea los datos correspondientes en caché. En resumen, el proceso de resolución normal se lleva a cabo de la siguiente manera:
- El servidor DNS local recibe una consulta recursiva desde el resolver del host cliente.
- El DNS local realiza las consultas iterativas a los servidores correspondientes.
- El servidor DNS local entrega la resolución al host que solicitó la información.
- El resolver del host cliente entrega la respuesta a la aplicación correspondiente.
Tipos de registros DNS
El sistema de nombres de dominio constituye una base de datos de información para recursos de red. Estos datos se recogen estructurados en varios tipos de registros. Los más utilizados son:
A | Dirección (address). Registro que se usa en IPv4 para traducir nombres de hosts a direcciones IPv4. |
AAAA | Dirección (address). Registro que se usa en IPv6 para traducir nombres de hosts a direcciones IPv6. |
CNAME | Nombre canónico (canonical Name). Registro para crear nombres de servidores de alojamiento adicionales, o alias, para los servidores de alojamiento de un dominio. Se usa cuando tenemos varios servicios (como FTP y servidor web) en un servidor con una sola dirección IP. Cada servicio tiene su propia entrada de DNS (como ftp.weblinus.com. y www.weblinus.com.). Esto también es muy útil cuando tenemos varios servidores web, con diferentes nombres, en el mismo host. Se escribe primero el alias y luego el nombre real. |
NS | Servidor de nombres (name server). Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. |
MX | Intercambio de correo (mail exchange). Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. |
PTR | Indicador o puntero (pointer). También conocido como «registro inverso», funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. Lo utilizamos en el fichero de configuración de la zona DNS inversa. |
SOA | Autoridad de la zona (start of authority). Proporciona información sobre el servidor DNS primario de la zona. |
SRV | Service record (SRV record). |
ANY | Toda la información de todos los tipos que exista. (No es un tipo de registro, sino un tipo de consulta) |
Otros registros menos utilizados
CAA | Es el registro de «autorización de autoridad de certificación»; permite que los propietarios de un dominio especifiquen qué autoridades de certificación pueden emitir certificados para ese dominio. Si no existe ningún registro CAA, entonces cualquiera podrá emitir un certificado para ese dominio. Estos registros también los heredan los subdominios. |
DNSKEY | El registro «DNS Key» contiene una clave pública que se utiliza para verificar firmas de extensiones de seguridad del sistema de nombres de dominio (DNSSEC). |
CERT | El «registro de certificados» almacena certificados de claves públicas. |
RRSIG | El «registro de recursos de firma» almacena firmas digitales utilizadas para autenticar registros de conformidad con el DNSSEC. |
Configuración de un DNS en una DMZ privada
Veamos como se configura un servidor DNS en una DMZ. Una red privada compuesta por un cortafuegos, un proxi inverso, un DNS y varios servidores web Apache.

En este ejemplo no se realizan consultas a DNS externos. Nuestro DNS servirá para identificar los servidores web requeridos para servir su contenido. Todas las peticiones externas vendrán a una única IP pública y el DNS resolverá cual es el servidor web al que ha sido solicitado su contenido.
Puedes ver como se despliega esta infraestructura en la sección dedicada a Paperless de este blog.
En este caso esta implementado con un servidor Debian y bing. La ruta a los ficheros de configuración es /etc/bind.
Los ficheros de configuración del DNS que encontramos en esta ruta son:
named.conf | Este fichero es el encargado de llamar a los ficheros .db, que son en los que definimos las zonas DNS. |
named.conf.default | Aquí se añaden las zonas por defecto como por ejemplo localhost. |
named.conf.options | Para establecer algunas opciones. No es necesario tocarlo para que funcione. |
Luego debemos configurar las zonas DNS en los ficheros:
Zona interna
named.conf.local En las siguientes capturas vemos como se se declaran las zonas internas y establece el fichero de cada zona.

ficheros db.*.in En estos ficheros, uno por cada dominio, se configuran los registros que hemos visto más arriba para la zona interna.

Como vemos, en este caso, los datos más importantes son:
- $ORIGIN es el dominio original al que se añadirán los subdominios de la zona
- $TTL es el tiempo de vida de los registros
Los demás registro ya los hemos visto. Esta configuración define el comportamiento del servidor apuntando a los servidores que tenemos en la DMZ. Como podemos apreciar se determina la IP de cada servidor, tenemos un registro CNAME que apunta al servidor ftp y establecemos el registro NS que define la asociación que existe entre el nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio.
Zona Externa
named.conf.ext En las siguientes capturas vemos como se se declaran las zonas externas y establece el fichero de cada zona.

ficheros db.*.ext En estos ficheros, uno por cada dominio, se configuran los registros que hemos visto más arriba para la zona externa.

Esta configuración define el comportamiento del servidor apuntando al exterior de la DMZ para servir los contenidos solicitados. Como vemos aquí todos los registros son CNAME que apuntan al ns-server que tiene nuestra IP pública.
De esta manera, cuando llega una solicitud con un nombre de dominio a nuestra única IP pública, el DNS determina en que servidor está y que IP privada tiene. Y cuando un servidor ofrece la información solicitada, el DNS establece que esta ha de ser dirigida al servidor con IP pública. Es la forma de tener múltiples servidores, con variados dominios, bajo una sola IP pública.
NOTA: El dominio startupfp.es. ya no existe, por lo tanto no es accesible y es la razón de no ocultar las IPs.
Si tienes algún comentario que hacer sobre este artículo, al pie del post tienes un formulario para hacerlo.
Si quieres contactar conmigo por cualquier otro asunto relacionado con el sitio, en la página de contacto, tienes un formulario más adecuado.
Y para suscribirte y recibir las novedades publicadas, tienes un enlace en el pie de la página o desde aquí mismo.