Análisis de logs RPZ en bajo nivel (BIND)

Introducción

El análisis de logs en resolvers DNS con RPZ permite:

  • Detectar bloqueos (NXDOMAIN)

  • Identificar clientes (IPs origen)

  • Analizar comportamiento de tráfico

  • Detectar errores de acceso

  • Validar políticas de seguridad

Este documento está orientado al análisis práctico en entornos productivos.

Quick Start (para soporte)

Si ves en los logs:

  • NXDOMAIN → bloqueo por RPZ

  • PASSTHRU → permitido explícitamente

  • denied → problema de ACL

Comandos rápidos:

tail -F dns_rpz.log | grep -F "NXDOMAIN"
tail -F dns_rpz.log | grep -F "<IP>"
tail -F dns_rpz.log | grep -F "<dominio>"

Truco

Siempre comenzar filtrando por IP del cliente.

Flujo básico de análisis

Cliente → Resolver (BIND + RPZ) → Internet
           ↓
        Logs (dns_rpz.log)

Estructura de una línea de log RPZ

Ejemplo:

23-Feb-2026 04:50:25.520 client @0x7f136318ec00 45.191.233.142#15203 (cdn98.adtp1.xyz): rpz QNAME NXDOMAIN rewrite cdn98.adtp1.xyz/A/IN via cdn98.adtp1.xyz.planisys.threats

Desglose:

  • timestamp → fecha y hora

  • client @0x... → identificador interno de BIND

  • 45.191.233.142 → IP cliente

  • #15203 → puerto origen

  • (cdn98.adtp1.xyz) → dominio consultado

  • NXDOMAIN rewrite → acción aplicada

  • A/IN → tipo de consulta

  • via ...planisys.threats → lista RPZ aplicada

Bloqueos (NXDOMAIN)

Identificación:

rpz QNAME NXDOMAIN rewrite

Interpretación:

  • El dominio fue bloqueado por RPZ

  • Se responde NXDOMAIN de forma intencional

Impacto:

  • La aplicación puede dejar de funcionar

  • Puede romper carga parcial de sitios

  • Puede generar tickets de usuario

Ejemplo:

(ads.nexage.com): rpz QNAME NXDOMAIN rewrite ads.nexage.com/A/IN via ads.nexage.com.planisys.threats

Nota

NXDOMAIN en RPZ no es un error, es una política aplicada.

Consultas permitidas (PASSTHRU)

Ejemplo:

rpz QNAME PASSTHRU rewrite www.google.com/A/IN via www.google.com.allowlist.rpz

Interpretación:

  • El dominio coincide con una regla RPZ

  • Está permitido explícitamente

  • No se bloquea

Casos típicos:

  • Google

  • Amazon

  • servicios críticos

Consultas denegadas (ACL)

Ejemplo:

client 172.31.18.61 (...) (api16-core.tiktokv.com): query (cache) 'api16-core.tiktokv.com/A/IN' denied (allow-query-cache did not match)

Interpretación:

  • El cliente no está autorizado

  • No cumple reglas ACL (ej: trusted_blocks)

Posibles causas:

  • Cliente mal configurado

  • NAT incorrecto

  • tráfico inesperado

Advertencia

Esto no es un bloqueo RPZ, es un rechazo del resolver.

Visualización en tiempo real

tail -F dns_rpz.log

Filtros útiles:

tail -F dns_rpz.log | grep -F "NXDOMAIN"
tail -F dns_rpz.log | grep -F "<IP>"
tail -F dns_rpz.log | grep -F "<dominio>"

Uso de grep -F

El parámetro -F indica búsqueda literal (sin regex).

Ventajas:

  • Mayor velocidad

  • Menor uso de CPU

  • Coincidencias exactas

Ejemplo incorrecto:

grep "45.191.233.142" dns_rpz.log

Ejemplo correcto:

grep -F "45.191.233.142" dns_rpz.log

Truco

En logs de alto volumen, usar siempre grep -F.

Rastreo de IPs cliente

grep -F "45.191.233.142" dns_rpz.log

Dominios consultados:

grep -F "45.191.233.142" dns_rpz.log | awk -F'[()]' '{print $2}' | sort | uniq -c | sort -nr

Top dominios bloqueados

awk -F'[()]' '{print $2}' dns_rpz.log | sort | uniq -c | sort -nr | head

Top IPs que generan tráfico

awk '{print $5}' dns_rpz.log | cut -d'#' -f1 | sort | uniq -c | sort -nr | head

Uso de screen para troubleshooting

Crear sesión:

screen -S dns-debug

Comandos básicos:

Ctrl + A + C   # nueva ventana
Ctrl + A + N   # siguiente
Ctrl + A + P   # anterior
Ctrl + A + D   # detach

Reconectar:

screen -r dns-debug

Ejemplo práctico:

Ventana 1:

tail -F dns_rpz.log

Ventana 2:

tail -F dns_rpz.log | grep -F "NXDOMAIN"

Ventana 3:

tail -F dns_rpz.log | grep -F "<IP>"

Caso práctico: usuario sin acceso

  1. Obtener IP del cliente

  2. Buscar en logs:

grep -F "<IP>" dns_rpz.log

  1. Analizar:

  • NXDOMAIN → bloqueo RPZ

  • denied → problema ACL

  • sin resultados → problema externo a DNS

Detección de comportamiento sospechoso

Indicadores:

  • alto volumen de consultas

  • dominios aleatorios

  • múltiples NXDOMAIN

Ejemplo:

grep -F "<IP>" dns_rpz.log | wc -l

Consideraciones sobre logrotate

Problemas comunes:

  • pérdida de seguimiento con tail -f

  • procesos colgados

  • alto consumo de CPU

Recomendaciones:

  • usar tail -F

  • usar grep -F

  • evitar regex complejas

Errores comunes

  • interpretar NXDOMAIN como error DNS

  • no usar -F en grep

  • analizar logs sin filtrar

  • usar comandos pesados en producción

Conclusión

El análisis de dns_rpz.log permite:

  • entender bloqueos en tiempo real

  • identificar clientes

  • detectar anomalías

  • validar políticas

El uso eficiente de tail -F, grep -F y screen es clave para operar en entornos de alto volumen sin impactar la infraestructura.