Solución de Problemas Comunes de Errores de Configuración de DNS

DNS (Sistema de nombres de dominio) puede no ser conocido por la mayoría de las personas que usan Internet, pero es la verdadera fuerza invisible que impulsa Internet, sin la cual todos estarían viendo números e IPs. Todo el significado de los nombres de dominio existe hoy en día solo gracias a DNS.

Introducción

La forma más sencilla de explicar DNS en una línea es mapear el nombre de dominio a la dirección IP. No estoy seguro de cuántos sabrían que cuando alguien escribe un nombre de dominio en IE/firefox, el navegador reenvía la solicitud DNS pidiendo la dirección IP al resolvedor del ISP (Proveedor de ISP) y el resolvedor contacta a los servidores raíz y luego recupera sistemáticamente la dirección IP en cuestión de unos pocos milisegundos.

Entender DNS y su funcionamiento es uno de los temas más difíciles de la ingeniería informática y, sin embargo, la mayoría de los administradores de red experimentados luchan en este tema cuando se trata de escribir archivos de zona DNS.

Antes de continuar con este artículo, los siguientes son los puntos MÁS IMPORTANTES que debes recordar, de lo contrario no entenderás nada.

Puntos a Recordar

Un registro A debe CONTENER SIEMPRE la dirección IP (mapear host a IP)

Siempre que especifiques un registro A, debe contener la dirección IP en el lado derecho. El registro A es tan importante en DNS, sin el cual el significado de mapear nombres de host a IP sería absurdo. ¡Así que recuerda esto!

CNAME (Alias) debe contener nombres de host. No IPs aquí
Los registros NS y MX deben contener nombres de host. No se permiten IPs.
Usa el PUNTO al final, siempre que especifiques un nombre de dominio en el archivo de zona DNS. Este PUNTO es tan importante y si olvidas esto, tendrás pesadillas con tu configuración de DNS.

Por ejemplo

example.com. IN NS ns1.example.com.

¿Por qué el PUNTO? simplemente porque indica que la consulta debe comenzar desde los servidores raíz (denotados por el punto)

Los registros MX (para servidores de correo) deben contener nombres de host NO IPs.

Términos Comunes de DNS y sus Significados

(i) Registros Glue

Los registros glue son registros A que están asociados con registros NS para proporcionar información de “arranque” a los registros de nombres del servidor NS. (ver sección 2.3 de RFC 1912)

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 11.33.55.77
ns2 IN A 22.44.66.88

En el ejemplo anterior estamos mapeando cada registro NS a la dirección IP (registro A), vinculando así los servidores de nombres a la IP (es decir, pegándolos).

(ii) Delegación de Servidor de Nombres LAME

Un servidor de nombres que da una respuesta no autoritativa se llama generalmente ‘LAME’. Cada dominio debe tener al menos 2 servidores de nombres y si pregunto a cada uno de ellos, y si tienen información de zona del dominio, recibiré una respuesta autoritativa. Si no, es una ‘delegación lame’. Consulta la sección 2.8 de RFC 1912.

Un ejemplo de delegación lame es

domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net

ns1.domain.com está configurado para tener información de zona sobre el dominio, pero ns2.exserver.net no fue configurado correctamente y no tiene información sobre el dominio. Así que ns1 responderá autoritativamente mientras que ns2 no lo hará, lo que será ‘lame’ hasta que se configure correctamente.

Para obtener una comprensión más profunda, usemos la herramienta dig para example.com.

Primero encontramos los servidores de nombres de example.com:

 dig example.com NS

;; SECCIÓN DE RESPUESTA:
example.com. 158240 IN NS a.iana-servers.net.
example.com. 158240 IN NS b.iana-servers.net.

Dado que hemos recibido 2 servidores de nombres, preguntamos a cada uno de ellos si dan una respuesta autoritativa. Si es autoritativa, la bandera ‘aa’ en el encabezado se establecerá en la respuesta recibida (‘aa’ es respuesta autoritativa).

dig @b.iana-servers.net example.com NS
dig @a.iana-servers.net example.com NS

;; Obtuvo respuesta:
;; ->>ENCABEZADO<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; SECCIÓN DE PREGUNTA:
;example.com. IN NS

;; SECCIÓN DE RESPUESTA:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Mira las banderas.

flags: qr aa rd

Dado que ‘aa’ está establecido en la respuesta, entonces ambos servidores de nombres de example.com proporcionan una respuesta autoritativa. Si es una delegación lame, no obtendrás la respuesta autoritativa.

PRECAUCIÓN:

No debes usar CNAME (alias) junto con registros NS y a menudo confunde a la mayoría de los resolvedores, causando bucles y a menudo conduce a ‘delegación lame’.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net

Así que nunca uses CNAME junto con registros NS.

(iii) Servidores de Nombres Stealth

Los Servidores de Nombres Stealth (o servidores de nombres ocultos) son servidores de nombres desajustados/conflictivos que existen a nivel raíz en contra de los servidores de nombres en el dominio.

Para ilustrar esto, cuando pregunto a los servidores padres sobre tu dominio para registros NS a nivel raíz, obtengo

ns0.domain.com
ns2.domain.com
ns3.domain.com

pero cuando consulto los servidores de nombres de tu dominio para los registros NS, no son los mismos y vienen como

ns0.domain.com
ns2.domain.com
ns.example-dns.net

Dado que ns.example-dns.net y ns3.domain.com están ocultos, ambos son ‘servidores de nombres stealth’. Aunque no hay nada de malo en ello, se recomienda no tener ningún servidor de nombres stealth tanto a nivel raíz como en tu servidor DNS.

Puedes usar el comando dig para buscar registros NS a nivel de servidor raíz.

 dig +trace @K.root-servers.net example.com NS

y para preguntar a uno de los servidores de nombres del dominio.

 dig @ns0.domain.com example.com NS

Busca cualquier desajuste de NS entre las dos consultas. Si falta un servidor de nombres a nivel raíz, agrega el servidor de nombres que falta a tu registrador de dominio. Si falta el servidor de nombres a nivel de dominio, agrega el servidor de nombres al archivo de zona del dominio y actualiza todos tus servidores de nombres secundarios.

(iv) Servidor DNS Abierto

Ejecutar el servidor DNS ‘abierto’ es un gran riesgo de seguridad, ya que responde a consultas recursivas tanto desde dentro como desde fuera de tu red. Esto significa que cualquiera puede consultar tu servidor para obtener la dirección IP y tu servidor DNS les responderá.

Para ilustrar esto, tenemos dos servidores de nombres ejecutando bind para el dominio example.com.

ns1.example.com
ns2.example.com

Le pedimos a ns1.example que resuelva el dominio externo google.com y si obtenemos la dirección IP (registro A) en la sección de respuesta, entonces significa que es un ‘servidor DNS abierto’.

dig @ns1.example.com google.com
dig @ns2.example.com google.com

;; opciones globales: printcmd
;; Obtuvo respuesta:
;; ->>ENCABEZADO<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; SECCIÓN DE PREGUNTA:
;google.com. IN A

;; Tiempo de consulta: 32 mseg

Dado que no hay sección de RESPUESTA o dirección IP, ambos servidores de nombres no constituyen un servidor DNS abierto.

Si te sucede ejecutar bind8 o posterior, todo lo que tienes que hacer es establecer ‘recursion no’ dentro de las opciones para deshabilitar que el servidor DNS responda a consultas recursivas.

options {
….
recursion no;
}

(v) Transferencias de Zona (solicitud AXFR)

Las transferencias de zona son realizadas por servidores de nombres secundarios para recuperar la información de zona más reciente y actualizada para el dominio desde el servidor de nombres maestro o primario. Las transferencias de zona solo deben estar disponibles para servidores de nombres secundarios y no para el mundo abierto, ya que es un gran riesgo de seguridad y puede exponer los internos de tu red al atacante.

Para solicitar una transferencia de zona para example.com, primero necesitamos preguntar al servidor de nombres maestro. Consulta el siguiente ejemplo con dig.

 dig @ns1.example.com example.com

Si ves la salida con el archivo de zona completo, entonces debes deshabilitar la transferencia de zona. En la mayoría de los casos verás conexión fallida o REFUSED, lo que significa que la transferencia de zona no está permitida y es algo bueno.

Errores Comunes de DNS en la Escritura de Archivos de Zona

1. No hay CNAME apuntando a registros NS

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net —–> INCORRECTO

Colocar CNAME junto con NS hará que todos los servidores de nombres fallen y resultará en una delegación lame. ¡No lo hagas!

Consulta RFC1912 2.4 y RFC2181 10.3.

2. Evitar ejecutar servidores DNS en IPs en la misma subred (/24) o en el mismo servidor.

El propósito de DNS es que los servidores de nombres estén distribuidos en diferentes ubicaciones geográficas para que si uno falla, el otro funcione. Aunque es una práctica muy común ejecutar ambos servidores de nombres en el mismo servidor o subred, no proporcionará tolerancia a fallos. Si el servidor falla, tus servidores de nombres fallarán y tu sitio no se cargará.

ns1 IN A 75.33.22.xx —–> misma subred /24
ns2 IN A 75.33.22.xx —–> misma subred /24

3. GLUE adecuado

Siempre agrega glue a tus registros NS a las direcciones IP usando el registro A, de lo contrario uno de tus servidores de nombres fallará.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 —–> GLUE
ns2 IN A 2.4.6.9 —–> GLUE

Consulta RFC1912.

4. No duplicar registros MX

domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com —-> DUPLICADO

5. Permitir el Puerto 53 para conexiones UDP y TCP

Si usas un firewall, asegúrate de no bloquear el puerto 53 para solicitudes DNS tcp y udp. Por defecto, las búsquedas DNS utilizan el protocolo UDP, mientras que las transferencias de zona y notificaciones utilizan el protocolo TCP del puerto 53.

Puerto 53 UDP = Solicitudes Dns
Puerto 53 TCP = Transferencias de zona

6. Los CNAME no pueden coexistir con hosts MX.

No especifiques CNAME o alias apuntando a registros MX.

domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ———-> INCORRECTO

En su lugar, usa el registro A para mapear directamente a la dirección IP.

mail IN A 11.33.55.77 —> CORRECTO

Consulta RFC1912.

7. Los registros MX no deben contener direcciones IP

domain.com. IN 10 MX mail.domain.com. —-> CORRECTO
domain.com. IN 20 MX 11.22.33.44 —–> INCORRECTO

La forma correcta de hacer esto es pegar el host mx al registro A.

domain.com. IN MX 10 mail.domain.com. —–> CORRECTO
mail IN A 11.33.55.77 ———-> CORRECTO

8. Los registros NS NO deben contener direcciones IP

Siempre especifica servidores de nombres para tu dominio con registros NS. Debe ser un nombre y no una dirección IP.

domain.com. IN NS dns0.domain.com. —–> CORRECTO
domain.com. IN NS 75.xx.xx.xx ———–> INCORRECTO

DNS INVERSO PARA ENTREGA DE CORREO

Para una entrega de correo adecuada, los siguientes métodos anti-spam son muy importantes para asegurarse de que el correo electrónico se entregue a la bandeja de entrada de los usuarios. La mayoría de los proveedores de servicios de correo electrónico públicos como yahoo, hotmail y gmail utilizan estos parámetros para marcar el correo electrónico como spam o no.

(i) Configurar IP Inversa para tu servidor de correo con PTR en DNS (necesita IP dedicada)
(ii) Configurar Registro SPF en tu DNS
(iii) Configurar Claves de Dominio

He visto en muchas ocasiones que si usas un plan de alojamiento compartido, la mayoría de los correos terminan en la carpeta de spam/bulk en la bandeja de entrada de los usuarios. Así que usa un servidor dedicado.

Configurar IPs inversas para IPs de Servidor de Correo

Para configurar IP inversa, primero necesitarás hacer una solicitud a tu proveedor de alojamiento (ya que ellos poseen la dirección IP) y pedirles que configuren una IP inversa para tu servidor de correo. Una vez hecho esto, debes colocar una línea usando PTR en tu archivo de zona de dominio.

Para probar la búsqueda de IP inversa:

 host

mostrará la salida de dns inverso.

Configurar registro SPF

El registro SPF se configura usando el registro TXT en tu archivo de zona DNS. Se ve como lo que se muestra a continuación. Visita http://openspf.org para más información sobre configuración y configuración.

domain.com. IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”

Para consultar el registro SPF usando dig:

 dig domain.com TXT

Claves de Dominio

Básicamente contiene 2 registros (con y sin selector) colocados bajo TXT usando guion bajo junto con la clave pública generada.

El ‘sel’ es un selector y puede ser el nombre del selector.

Cómo configurar servidores de nombres DNS para tu dominio usando BIND9

Simplemente ve a tu consola de linux y escribe los siguientes comandos.

yum install bind

Crea un nuevo archivo de zona para tu dominio e inserta el archivo de zona de muestra (ver abajo). Debes cambiar domain.com, serial y parámetros de correo electrónico.

nano /var/named/domain.com.db

Abre /etc/named.conf y coloca las siguientes líneas:

zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};

Guarda los cambios en el archivo y reinicia bind.

service named restart

Archivo de Zona DNS de Muestra para BIND

Usa este archivo para configurar tus dominios y servidores de nombres en BIND9:

;=================================================================
;MUESTRA DE ARCHIVO DE ZONA DNS BIND
;para CUALQUIER Dominio (Solo cambia domain.com por tu sitio)
;================================================================

; Antes de comenzar NO OLVIDES EL PUNTO Y EL INCREMENTO SERIAL

$TTL 14400
$ORIGIN domain.com.

; Registro SOA
; Especificar servidor de nombres primario ns1.domain.com
; El serial debe incrementarse en cada actualización
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. ( 2009092902 ; Serial en YYYYMMDDXX (XX es incremento)
10800; segundos de actualización
3600; reintentar
604800; expirar
38400; mínimo
);
; Dirección IP del sitio web especificada en el registro A

IN A xx.xx.xx.xx

; Mínimo 2 nombres de servidor DNS

IN NS ns1.domain.com.
IN NS ns2.domain.com.

; Mapeo de todos los Servidores de Nombres y sus IPs correspondientes (GLUE)

ns1 IN A xx.xx.xx.xx
ns2 IN A xx.xx.xx.xx

; Especificar cualquier subdominio y entrada www aquí usando el registro CNAME

www IN CNAME domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.

; Configurar registro MX (intercambiador de correo con prioridad)
domain.com. IN MX 10 mail.domain.com.

; establecer registro A para correo
mail IN A xx.xx.xx.xx;====================================

Sobre el Autor

El Sr. Balakrishnan es un emprendedor de Internet y administrador de Linux con intereses en programación PHP y aplicaciones de Linux. Se le puede contactar en su sitio de blog corpocrat.com o en su página de twitter.