Resumen

  • RPZ convierte una zona DNS en vehículo para disparadores y acciones. La autenticidad del traslado identifica la versión y al productor, pero no acredita que un indicador sea correcto ni que su medida sirva para todos los clientes.
  • La respuesta nace de decisiones del operador: orden de zonas, precedencia, sobrescritura de acciones, alcance por cliente, tratamiento de DNSSEC, TTL, caché y diagnóstico. El suscriptor no es un mensajero neutral.

Una universidad contrata una lista contra dominios maliciosos. El proveedor incorpora la dirección de un servidor autoritativo usado por una campaña de fraude. Esa misma máquina aloja DNS para decenas de proyectos académicos. Una regla NSIP produce NXDOMAIN para todo lo servido desde allí. La zona llegó sin alteraciones; el efecto, demasiado amplio, fue local.

El ejemplo es hipotético. La superficie técnica no lo es. Una coincidencia por servidor de nombres no juzga si todos los dominios bajo esa infraestructura comparten riesgo. El resolutor recibe un indicador y luego decide cuánto poder darle.

La documentación vigente de BIND define RPZ como formato abierto y neutral respecto del proveedor: reglas de cortafuegos DNS expresadas en registros de una zona y distribuidas con AXFR, IXFR y NOTIFY. Unbound y PowerDNS Recursor ofrecen implementaciones propias del mismo patrón.

No es correcto atribuirle rango normativo que no tiene. draft-vixie-dnsop-dns-rpz-00 es un borrador individual expirado; la página dice expresamente que carece de posición formal en el proceso de estándares del IETF. Su historial registra que quedó dormido en 2020. Sirve para entender la semántica compartida, no para afirmar que existe un RFC RPZ.

El borrador separa dos actos que suelen confundirse. El productor publica datos de política mediante transferencia de zona. La configuración del suscriptor promueve esos datos al plano de control de su resolutor. TSIG puede proteger la relación de transferencia; no certifica que un dominio sea dañino ni que bloquearlo sea proporcional.

Los cinco disparadores revelan por qué esa distinción importa. RPZ puede mirar la IP del cliente, el QNAME, una IP que habría aparecido en la respuesta, el nombre de un servidor autoritativo o su dirección. Cada uno captura un objeto distinto y se evalúa en otra fase. La coincidencia QNAME es específica al nombre. NSDNAME y NSIP pueden abarcar infraestructuras compartidas. Una regla correcta sobre un servidor usado por atacantes puede ser incorrecta para vecinos inocentes.

Las seis acciones también expresan decisiones distintas. NXDOMAIN inventa que el nombre no existe. NODATA conserva el nombre y niega el tipo solicitado. DROP deja al cliente sin respuesta. TCP-only obliga a reintentar por TCP. Los datos locales pueden devolver un CNAME a un portal. PASSTHRU impide que se aplique una política posterior. Cada opción cambia los síntomas, la capacidad de diagnóstico y el comportamiento de las aplicaciones.

La precedencia decide qué síntoma gana. La referencia de BIND prioriza primero la zona situada antes en response-policy; dentro de ella ordena CLIENT-IP, QNAME, IP, NSDNAME y NSIP, además de especificidad de nombre o prefijo. Unbound procesa zonas en orden y considera PASSTHRU una coincidencia completa: si aparece antes, las listas posteriores ya no actúan.

Por eso BIND recomienda una RPZ interna antes de los proveedores externos. Allí pueden vivir excepciones para socios y activos que la organización conoce mejor que el editor de inteligencia. No se trata de “debilitar” el feed. Se trata de conservar la autoridad sobre la consecuencia donde también reside el conocimiento del servicio.

PowerDNS agrega una advertencia: el orden exacto de evaluación cambió entre versiones y no siempre reproduce literalmente toda la precedencia del borrador, por razones de privacidad y rendimiento. Puede consultar la dirección del cliente y el nombre antes de completar resolución, y otros disparadores durante o después. Dos resolutores con los mismos archivos pueden no producir el mismo ganador.

Además, el operador puede cambiar lo que la lista pide. BIND permite imponer a una zona entera NXDOMAIN, NODATA, DROP, TCP-only, PASSTHRU o un CNAME. Unbound puede conservar los disparadores y reemplazar todas las acciones por una redirección local. PowerDNS ofrece políticas predeterminadas como Custom, NoAction, Drop o Truncate. En ese punto, la frase “el proveedor devolvió NXDOMAIN” ya es técnicamente falsa: lo hizo la configuración del suscriptor.

La observación previa es otra potestad. Unbound puede cargar una RPZ como disabled, registrar coincidencias y dejar que continúe la siguiente zona. PASSTHRU no funciona igual: sí cuenta como coincidencia y detiene las posteriores. BIND dispone de su propio modo deshabilitado. Los nombres se parecen, pero el efecto debe verificarse en código activo.

DNSSEC marca una frontera más dura. El borrador RPZ denomina a la respuesta modificada un resultado deliberadamente distinto de la verdad autoritativa. BIND, de forma predeterminada, evita la modificación cuando el cliente pide DNSSEC y existen registros firmados. break-dnssec yes permite reescribir, pero el producto advierte que el resultado no puede validarse.

RFC 4035 explica que un conjunto que debería encadenar hasta una ancla de confianza y no lo hace se considera Bogus. También reconoce que el resolutor recursivo aplica política local. DNSSEC autentica RRsets del servidor autoritativo; no presta esa firma a una respuesta sintética. Del mismo modo, TSIG protege la entrada RPZ, no la afirmación NXDOMAIN que sale hacia el usuario.

La caché amplifica errores. RFC 2308 exige tratar las respuestas negativas con TTL: NXDOMAIN puede reutilizarse para el mismo nombre y clase; NODATA depende también del tipo. BIND limita el TTL de su política con una decisión local. PowerDNS controla TTL sintetizado e invalidación de caché. Retirar una regla en el origen no borra automáticamente cada negativo ya almacenado.

También conviene decir por qué se alteró la respuesta. RFC 8914 reserva EDE 15 para política interna del operador, 16 para requisito externo, 17 para filtrado pedido por el cliente y 18 para rechazo a un cliente no autorizado. Esa taxonomía evita presentar como decisión de seguridad propia lo que quizá sea orden de un tercero o preferencia del usuario.

EDE sólo aporta contexto. El RFC prohíbe que cambie el procesamiento del RCODE y advierte que el dato puede no estar autenticado. Un buen registro operativo une el código a la versión del feed, la zona ganadora, el disparador, la acción, el cliente y el TTL. Si no existe esa unión, el código es una etiqueta sin cadena causal.

La retirada de falsos positivos es parte del producto. El borrador expirado pide minimizar la latencia tanto para nuevas amenazas como para políticas erróneas u obsoletas. PowerDNS puede conservar un volcado de la última versión y usarlo como semilla al arrancar. BIND permite decidir si responder SERVFAIL mientras las zonas no están listas. Todas esas opciones obligan a fijar edad máxima, comportamiento con carga parcial y autoridad para volver atrás.

La doctrina de Heng Lu sobre código en ejecución, especificación inicial mínima y decisión futura localizada y capas de realidad ayuda a no confundir símbolos. La lista es una capa de evidencia. La configuración es una capa de decisión. La respuesta observada es la capa operativa. Ninguna sustituye a las otras.

El control defendible conserva todo el recorrido: productor, serial, autenticación de transferencia, admisión local, orden efectivo, sobrescritura, disparador ganador, acción, TTL, EDE y consulta desde clientes representativos. Sólo entonces se puede atribuir el resultado. La lista llegó intacta; la inexistencia, sin embargo, se decidió aquí.