Verificador de Archivo de Zona

El Zone File Linter valida la sintaxis de archivos de zona BIND y detecta problemas comunes de configuración DNS antes del despliegue. Pega el contenido de tu archivo de zona y la herramienta ejecuta pasadas de validación sintáctica, semántica y estructural, reportando errores con números de línea y recomendaciones específicas de corrección. A diferencia de los mensajes crípticos que BIND produce cuando se niega a cargar una zona, este linter proporciona retroalimentación clara y accionable.

Entendiendo la validación de archivos de zona

Los archivos de zona DNS son engañosamente simples. Parecen archivos de texto directos con registros listados uno por línea, pero contienen un número sorprendente de formas de introducir errores que causan caídas. Un punto final faltante en un target externo crea silenciosamente un hostname sin sentido. Un CNAME colocado en el apex de la zona o junto a otros tipos de registro viola la especificación DNS y causa comportamiento impredecible del resolver. Registros duplicados desperdician espacio y confunden las auditorías. Una dirección IP inválida en un registro A produce una zona que carga exitosamente pero devuelve basura a los clientes.

La retroalimentación estándar que recibes de BIND cuando un archivo de zona tiene errores frecuentemente no es útil. Mensajes como "zone example.com/IN: loading from master file failed: bad owner name" no te dicen qué línea está mal o qué específicamente tiene de malo. Terminas haciendo búsqueda binaria a través del archivo, comentando secciones hasta que el error desaparece. Esto es lento, frustrante y completamente innecesario si validas el archivo antes de intentar cargarlo.

Este linter realiza tres pasadas sobre tu archivo de zona. La pasada sintáctica verifica cada línea para formato correcto: conteos de campos correctos, formatos de valores válidos, paréntesis balanceados y sintaxis de directivas apropiada. La pasada semántica verifica que los valores tengan sentido: las direcciones IP son válidas, los hostnames siguen las reglas RFC, los TTLs están dentro de rangos razonables y los targets están correctamente calificados. La pasada estructural examina el archivo de zona como un todo: los registros SOA y NS requeridos están presentes, se identifican los conflictos de CNAME, se señalan los duplicados y se detectan los targets huérfanos. Cada problema se reporta con su número de línea, nivel de severidad y una descripción específica de qué está mal y cómo corregirlo.

Cómo hacer lint de un archivo de zona DNS

1. Pega el contenido de tu archivo de zona BIND en el campo de entrada
2. El linter ejecuta las pasadas de validación sintáctica, semántica y estructural
3. Revisa la lista de errores, advertencias y mensajes informativos con números de línea
4. Corrige los problemas reportados y vuelve a validar hasta que el archivo de zona pase limpiamente

Errores comunes de archivos de zona detectados

Ejemplo de lint de archivo de zona

Archivo de zona de entrada

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
        2024010101 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        86400 )    ; minimum
@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.
@       IN  CNAME  www.example.com.
www     IN  A      203.0.113.10
www     IN  A      203.0.113.10
mail    IN  A      203.0.113.20
smtp    IN  CNAME  mail
smtp    IN  MX     10 mail
api     IN  A      192.168.1.500

Salida del linter

Line 10: ERROR - CNAME at zone apex (@) conflicts with SOA and NS records
Line 12: WARNING - Duplicate record: www IN A 203.0.113.10
Line 15: ERROR - CNAME and MX records cannot coexist for name "smtp"
Line 16: ERROR - Invalid IPv4 address in A record: 192.168.1.500 (octet > 255)

Cuándo usar el Zone File Linter

• Antes de desplegar cambios de zona -- Detectar errores que causarían que BIND rechace la zona o sirva respuestas incorrectas
• Después de editar manualmente archivos de zona -- Las ediciones manuales frecuentemente introducen erratas, puntos faltantes o errores de sintaxis
• Validar zonas generadas por scripts -- Los scripts de generación automatizada de zonas pueden producir salida sutilmente inválida
• Durante migraciones DNS -- Los archivos de zona exportados de una plataforma DNS pueden necesitar ajustes de sintaxis para otra
• Revisión de código para cambios de infraestructura -- Incluir el linting de archivos de zona en tu checklist de revisión para pull requests de DNS
• Capacitación y aprendizaje -- Entender por qué ciertas construcciones de archivos de zona son inválidas ayuda a profundizar el conocimiento de DNS

Cómo funciona la validación de archivos de zona

El linter realiza tres pasadas de validación, cada una detectando diferentes clases de problemas:

Validación sintáctica

Verifica el formato crudo de cada línea:

• Conteos de campos de registro: Cada tipo de registro espera un número específico de campos (por ejemplo, los registros A necesitan un nombre, clase, tipo y dirección IPv4)
• Formatos de valores: Direcciones IP, hostnames, valores TTL y números de prioridad se verifican para formato válido
• Sintaxis de directivas: Las directivas $TTL, $ORIGIN e $INCLUDE deben seguir las reglas de sintaxis de BIND
• Registros multilínea: Los registros entre paréntesis (como SOA) deben tener paréntesis de apertura y cierre coincidentes
• Manejo de comentarios: Los comentarios con punto y coma se eliminan antes de la validación

Validación semántica

Verifica que los valores tengan sentido en contexto:

• Rangos de TTL: Los valores deben estar entre 60 segundos y 1 semana para la mayoría de los registros; el linter señala TTLs irrazonables
• Validez de hostname: Todos los hostnames referenciados en registros se verifican contra el RFC 1123
• Calificación de targets: Los targets externos deben estar completamente calificados (punto final); los targets relativos deben existir dentro de la zona
• Validez de direcciones: Las direcciones de registros A deben ser IPv4 válidas; los registros AAAA deben ser IPv6 válidos

Validación estructural

Verifica el archivo de zona como un todo:

• Registros requeridos: El apex de la zona debe tener al menos un registro SOA y al menos dos registros NS
• Conflictos de CNAME: Los nombres con registros CNAME no pueden tener ningún otro tipo de registro
• Restricciones del apex: Los registros CNAME no pueden aparecer en el apex de la zona
• Detección de duplicados: Los registros idénticos (mismo nombre, tipo, clase y datos) se señalan
• Detección de huérfanos: Los targets de CNAME o MX que apuntan a nombres no definidos en la zona generan una advertencia

Linting de archivos de zona en la práctica

El hábito más valioso que puedes construir alrededor de la gestión de archivos de zona es hacer lint antes de cada despliegue. Toma segundos y detecta el tipo de errores que causan caídas que duran minutos u horas. Un pipeline CI/CD que incluya linting de archivos de zona como una puerta pre-despliegue es aún mejor, porque previene que archivos de zona rotos lleguen a producción. Trata tus archivos de zona como código: deben pasar por revisión, validación y pruebas antes del despliegue.

Los errores que causan más dolor operacional no son los que BIND rechaza directamente. BIND se negará a cargar una zona con un error de sintaxis, y aunque eso es disruptivo, al menos sabes inmediatamente que algo está mal. Los errores peligrosos son los que BIND acepta pero que producen comportamiento incorrecto: un punto final faltante que crea un target CNAME erróneo, un registro duplicado que causa respuestas inconsistentes dependiendo de qué servidor autoritativo responda, o un conflicto CNAME que hace que un tipo de registro funcione mientras otro falla silenciosamente. Este linter detecta todos estos.

Al depurar un archivo de zona que el linter señala, comienza con los errores y corrígelos antes de abordar las advertencias. Los errores indican condiciones que causarán que la resolución DNS falle o produzca resultados incorrectos. Las advertencias indican condiciones que son técnicamente válidas pero probablemente no intencionadas, como registros duplicados o TTLs inusualmente cortos o largos. Los mensajes informativos señalan cosas que están bien pero vale la pena conocer, como el uso de nombres relativos que el linter resolvió usando el origin de la zona.

Preguntas frecuentes

¿El linter verifica si los hostnames realmente resuelven?

No. El linter valida la sintaxis y corrección estructural del archivo de zona sin realizar consultas DNS en vivo. Verifica que los hostnames sigan las reglas RFC y que el archivo de zona sea internamente consistente, pero no verifica si los nombres externos referenciados existen en DNS.

¿Por qué importa un punto final faltante?

En los archivos de zona BIND, los nombres sin punto final se tratan como relativos al $ORIGIN (apex de la zona). Si tu zona es example.com y escribes target.other.com sin punto final, BIND lo interpreta como target.other.com.example.com -- casi seguramente no es lo que pretendías. Los nombres externos completamente calificados siempre deben terminar con un punto.

¿Puede el linter corregir errores automáticamente?

No. El linter reporta problemas pero no modifica el archivo de zona. Las correcciones automáticas podrían introducir nuevos errores, especialmente con conflictos de CNAME y problemas estructurales que pueden tener múltiples resoluciones válidas. El linter proporciona información lo suficientemente específica para que tú hagas la corrección correcta.

¿Qué es la restricción de CNAME-en-el-apex?

El RFC 1034 prohíbe registros CNAME en el apex de la zona porque CNAME no puede coexistir con otros tipos de registro, y el apex debe tener registros SOA y NS. Si necesitas aliasing en el apex, muchos proveedores DNS ofrecen alternativas propietarias como registros ALIAS o CNAME flattening, pero los archivos de zona BIND estándar no soportan esto.

¿Debo hacer lint de archivos de zona generados por scripts?

Sí, absolutamente. La generación automatizada de zonas es una de las fuentes más comunes de archivos de zona sutilmente inválidos. Un script puede producir salida correcta para la mayoría de las entradas pero fallar en casos extremos: hostnames con caracteres inusuales, direcciones IPv6 en formatos inesperados, o registros que crean conflictos CNAME. Hacer lint de la salida de tus scripts de generación detecta estos problemas antes de que lleguen a producción.

¿Cómo manejo registros SOA multilínea?

Los registros SOA comúnmente abarcan múltiples líneas usando paréntesis. El linter maneja registros multilínea rastreando los paréntesis de apertura y cierre y uniendo las líneas antes de la validación. Los paréntesis faltantes o no coincidentes se señalan como errores de sintaxis.

Herramientas relacionadas

• BIND Zone A/AAAA Generator - Genera registros A y AAAA de zona BIND desde CSV
• BIND Zone CNAME Generator - Genera registros CNAME de zona BIND desde CSV
• Hostname Validator - Valida hostnames según los estándares RFC 1123
• DNS Record Set Deduper - Encuentra y elimina registros DNS duplicados
• SPF Record Builder - Construye registros SPF con sintaxis correcta