Conociendo el DNS

Qué es el DNS

DNS es la sigla en inglés de Domain Name System (Sistema de Nombres de Dominio, en español), responsable de transformar los nombres de los dominios de los sitios web que las personas escriben en los navegadores web en números IP.
El DNS opera principalmente a través de dos funciones: examinar y actualizar bases de datos y resolver nombres de dominios en direcciones de red.

El sistema de distribución de nombres de dominio comenzó en el año 1984, y a través de él se hizo posible que los nombres de hosts residentes en una base de datos pudieran ser distribuidos entre varios servidores, disminuyendo así la carga en cualquier servidor.
El DNS se basa en nombres jerárquicos y permite la inscripción de varios datos digitales, además del nombre del Host y del IP (Internet Protocol).

Debido a que la base de datos es distribuida, el tamaño es prácticamente ilimitado y el rendimiento no disminuye cuando entran nuevos servidores.

El servidor DNS traduce nombres en direcciones IP y viceversa. Y la división clásica entre primario (donde se edita la zona) y secundario (que recibe una copia por transferencia de zona) sigue siendo válida: el registro.br, por ejemplo, exige al menos dos servidores respondiendo por su dominio.

¿Qué es el DNS inverso?

El DNS inverso resuelve la dirección IP, buscando el nombre de dominio asociado al host. Es decir, cuando tenemos disponible la dirección IP de un host y no sabemos la dirección del dominio (nombre dado a la máquina u otro equipo que acceda a una red), intentamos resolver la dirección IP mediante el DNS inverso que busca qué nombre de dominio está asociado a esa dirección. Los servidores que utilizan el DNS inverso conseguem verificar la autenticidad de direcciones, comprobando si la dirección IP actual corresponde a la dirección IP informada por el servidor DNS. Esto evita que alguien utilice un dominio que no le pertenece para enviar spam, por ejemplo.

Concepto básico

El DNS inverso transforma 66.249.71.47 en dominio.com.es, es decir, una dirección IP en un nombre. El camino clásico para la resolución es: DNS resolver ➜ root servers ➜ ARIN (North American IP registry) ➜ Local ISP ➜ Acme Inc. DNS servers.

Quienquiera que sea su proveedor de IPs debe o bien añadir sus entradas en sus servidores de DNS o delegar la autoridad de sus entradas de inverso en sus servidores de DNS. Las entradas de DNS inverso utilizan hostname con una dirección de IP inversa con “.in-addr.arpa” añadido al mismo. Por ejemplo, “124.168.184.200.in-addr.arpa”.

El DNS estándar utiliza entradas del tipo “A Records” mientras que el DNS inverso utiliza “PTR records” que se parecen a “124.168.184.200.in-addr.arpa. PTR host.example.com” (mientras que un DNS estándar sería algo como “host.example.com. A 66.249.71.47”).

Funcionamiento del DNS estándar

Es común que muchas personas solo conozcan el “estándar” de DNS para la resolución de nombres de host en direcciones IP que transformaría dominio.com.br en 66.249.71.47. Este proceso comienza con el registro de un dominio; en Brasil, registro.br es una de las entidades (registrar) en las que podemos crear nuevos dominios. Existen cientos de registrars en todo el mundo.

Al crear un dominio debes informar tus servidores de DNS que serán los responsables de apuntar el nuevo dominio a una dirección IP y, por otro lado, registro.br envía esa información a los servidores raíz (técnicamente hablando, el servidor padre para tu TLD). De esta forma, cualquier persona en el mundo puede acceder a tus dominios y puedes enviarles cualquier dirección IP que desees. Tienes control total sobre tus dominios e incluso puedes enviar direcciones IP que no te pertenezcan; en ese caso necesitarías el permiso del verdadero dueño de la IP que tus servidores DNS devuelven como resultado de una resolución.

Los tipos de registro que vas a usar

Una zona DNS es una lista de registros, cada uno con un tipo. Estos son los que aparecen en el día a día:

Si administras correo electrónico, tres de ellos definen si tu mensaje llega o va al spam: MX, el PTR de la IP de salida y los TXT de SPF, DKIM y DMARC. El tema se detalla en La historia de Postfix.

Consultando en la práctica: el dig

Toda la teoría anterior se verifica con un comando. El dig viene en el paquete dnsutils (Debian/Ubuntu) o bind-utils (Fedora/RHEL):

# o básico: qual o IP deste nome?
dig +short exemplo.com.br

# um tipo específico
dig exemplo.com.br MX +short
dig exemplo.com.br TXT +short
dig exemplo.com.br NS +short

# DNS reverso
dig -x 203.0.113.10 +short

# perguntando a um resolvedor específico, ignorando o seu
dig @1.1.1.1 exemplo.com.br
dig @8.8.8.8 exemplo.com.br

# perguntando direto ao servidor autoritativo, sem cache no meio
dig @ns1.provedor.com.br exemplo.com.br

# a resolução inteira, passo a passo: raiz → TLD → autoritativo
dig +trace exemplo.com.br

O +trace es el comando que enseña DNS de verdad: muestra en pantalla la misma cadena de preguntas descrita en este post, una línea por etapa.

Para el día a día, dos atajos:

host exemplo.com.br          # resposta curta e legível
resolvectl query exemplo.com.br   # o que o systemd-resolved está usando
resolvectl status            # quais servidores a sua máquina consulta
resolvectl flush-caches      # limpar o cache local

TTL: por qué el cambio tarda en “aplicarse”

Todo registro lleva un TTL — el tiempo, en segundos, que los resolvedores de todo el mundo pueden guardar esa respuesta en caché. Es la explicación a la pregunta más común de quien cambia de servidor: “cambié la IP y el sitio sigue abriendo en el antiguo”.

# ver o TTL restante (sem o +short)
dig exemplo.com.br | grep -A1 "ANSWER SECTION"

La regla de oro de la migración: baja el TTL a 300 segundos con al menos 24 horas de antelación, haz el cambio, confirma que todo está correcto y solo entonces vuelve a subir el TTL a 3600 o más. Quien olvida este paso convive con un día entero de tráfico dividido entre el servidor viejo y el nuevo.

Lo que ha cambiado desde 2017: DNSSEC y DNS cifrado

El DNS se diseñó en 1983 sin ninguna preocupación por la seguridad — la respuesta llega en texto plano y sin firma. Se crearon dos capas para tapar agujeros diferentes, y es común confundirlas:

• DNSSEC resuelve la autenticidad: firma criptográficamente los registros, de modo que el resolvers detecta si alguien manipuló la respuesta en el camino. No oculta nada, solo prueba que vino de quien debía. En .br es compatible desde 2009 y se habilita en el panel de registro.br.
• DoT (DNS sobre TLS, puerto 853) y DoH (DNS sobre HTTPS, puerto 443) resuelven la privacidad: cifran la consulta para que el proveedor de internet y quien esté en medio del camino no vean qué sitios buscas. No dicen nada sobre si la respuesta es correcta.

Uno complementa al otro. En systemd-resolved, el DoT se conecta así:

sudo tee /etc/systemd/resolved.conf.d/dot.conf >/dev/null <<'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=allow-downgrade
EOF

sudo systemctl restart systemd-resolved
resolvectl status | grep -E "DNSOverTLS|DNSSEC|Current DNS"

# conferir se um domínio está assinado com DNSSEC
dig exemplo.com.br +dnssec | grep -E "RRSIG|flags:"
# a flag "ad" (authenticated data) na resposta indica validação bem-sucedida

Cuando algo no se resuelve

Guion de diagnóstico, de lo más probable a lo menos probable:

1. ¿Es caché? resolvectl flush-caches y prueba de nuevo. Compara con dig @1.1.1.1, que ignora su resolvedor.
2. ¿Responde el autoritativo? dig @ns1.provedor.com.br o-dominio. Si el autoritativo no responde, el problema no es suyo.
3. ¿Está correcta la delegación? dig o-dominio NS +trace — comprueba si los NS que publicó el registrador son los mismos de la zona.
4. ¿Sigue valiendo el TTL antiguo? Si acabas de cambiar, espera a que expire el TTL anterior.
5. ¿DNSSEC roto? Una firma caducada derriba el dominio entero para quien valida. dig +cd deshabilita la validación: si funciona con +cd y falla sin, has encontrado al culpable.
6. ¿Es tu máquina? resolvectl status muestra qué servidor se está utilizando realmente — muchas veces no es lo que usted ha configurado.

Cómo funciona Internet

Serie realizada por Nic.br sobre cómo funciona Internet, en caso de que esté creando o administrando un Servidor de Correo, Sitios, DNS, deténgase un momento y vea estos 4 vídeos de Nic.br.

• Parte 1: El protocolo IP
• Parte 2: Sistemas Autónomos, BGP, PTTs
• Parte 3: DNS
• Parte 4: Gobernanza de Internet
• La importancia del DNS en las redes

Enlaces

• registro.br — donde se registran dominios .br y se configura DNSSEC
• root-servers.org — el mapa en vivo de las instancias de servidores raíz
• DNSViz — visualiza la cadena DNSSEC de un dominio y señala dónde se rompe

Aquí en el blog: La historia de Postfix explica por qué MX, PTR y SPF决定 la entrega de tu correo; Sobre el archivo hosts muestra el atajo que existía antes del DNS — y que todavía se consulta primero; y la Serie Servidores Linux pone todo esto en práctica.