Respuestas DNS REFUSED: ACLs y políticas que te bloquean (y cómo corregirlo)

REFUSED es el equivalente en DNS a que alguien con una lista te haga un gesto para que no entres. El paquete llegó. El servidor entendió lo que pediste.
Simplemente decidió que no estás invitado.

Eso hace que REFUSED sea a la vez más fácil y más molesto que un timeout: probablemente tu red esté bien, tu cliente probablemente esté bien, y tu servidor está muy intencionalmente
negándose a ayudar. El truco es averiguar qué política está rechazando la solicitud y si está correcta.

Qué significa realmente REFUSED (y qué no significa)

En términos DNS, REFUSED es un RCODE (código de respuesta) que indica: «No voy a responder esta consulta por política local».
No significa «no lo sé», ni «el nombre no existe», ni «estoy roto». Política.

Las dos confusiones más comunes:

• REFUSED no es NXDOMAIN. NXDOMAIN significa que el servidor hizo el trabajo y concluyó que el nombre no existe.
  REFUSED significa que el servidor ni siquiera lo intentará (o no divulgará el resultado) para ti.
• REFUSED no es SERVFAIL. SERVFAIL es «lo intenté, algo falló». REFUSED es «no, intencionalmente».

Un buen modelo mental: REFUSED es el portero del servidor DNS aplicando la lista de invitados. Tu consulta puede ser perfectamente válida.
Incluso podrías obtener una respuesta del mismo servidor si consultas desde otra IP, por otra interfaz, usando la clave TSIG correcta,
o con recursión habilitada para tu red.

Dónde lo ves

Verás REFUSED en herramientas como dig como status: REFUSED, a menudo con una respuesta pequeña y sin sección de respuestas.
Algunos clientes lo ocultan tras mensajes vagos como «server refused» o «DNS name does not exist» (que es incorrecto, por cierto).

Por qué deberías importarte

REFUSED suele ser seguridad funcionando según el diseño: sin resolvers abiertos, sin transferencias de zona para todo el mundo, sin recursión para redes aleatorias,
sin fugas de datos entre vistas de split-horizon. El incidente ocurre cuando esa política bloquea a las personas equivocadas, o cuando tu arquitectura depende
de un comportamiento (recursión, reenvío, transferencia, actualización) que en realidad nunca fue permitido.

Una idea parafraseada de Gene Kim (autor sobre operaciones/fiabilidad): haz el trabajo visible y reduce la incertidumbre, porque las colas ocultas y las sorpresas provocan fallos.
REFUSED a menudo es «política oculta» hecha visible.

Datos interesantes y contexto histórico

• Los RCODEs son antiguos: los códigos de respuesta DNS provienen de los diseños iniciales de DNS en los años 80, cuando el concepto de «rechazo por política» ya existía.
• Los resolvers abiertos se convirtieron en un problema global: el abuso generalizado de resolvers recursivos abiertos para ataques de reflexión/amplificación empujó a los operadores
  a negar la recursión por defecto para clientes no confiables.
• Los valores por defecto de BIND cambiaron con el tiempo: configuraciones antiguas y fragmentos copiados de blogs pueden dejar la recursión inesperadamente abierta o cerrada,
  según la versión y el empaquetado de la distro.
• Split-horizon DNS precede al “zero trust”: servir respuestas diferentes según el cliente es una vieja táctica empresarial para ocultar nombres internos y dirigir tráfico.
• EDNS(0) cambió el juego: al permitir respuestas UDP más grandes se expusieron nuevos puntos de política: tamaños de búfer, retroceso a TCP y filtrado
  de clientes EDNS «extraños».
• DNSSEC aumentó la complejidad del resolver: los fallos de validación normalmente aparecen como SERVFAIL, pero muchos entornos añaden capas de política (firewalls, RPZ)
  que convierten algunas consultas en REFUSED a propósito.
• RPZ popularizó respuestas dirigidas por política: las Response Policy Zones permiten a los resolvers reescribir o bloquear respuestas (NXDOMAIN, CNAME a walled garden, o comportamiento similar a REFUSED).
• Anycast hizo real «misma IP, política distinta»: con anycast DNS, dos usuarios pueden llegar a instancias diferentes con ACLs distintas, haciendo que REFUSED parezca intermitente.

Guion rápido de diagnóstico

Si no recuerdas nada más, recuerda este orden. Está optimizado para incidentes reales: circuitos cortos, alta señal, y mínima conjetura.

1) Confirma qué está rechazando: qué servidor, qué ruta, qué protocolo

• ¿Recibes REFUSED del stub local (systemd-resolved), de un resolver corporativo o de un servidor autoritativo?
• ¿Es solo UDP? ¿Solo TCP? ¿Solo por VPN? ¿Solo en una subred?
• ¿Es un nombre, una zona o todo?

2) Compara el comportamiento desde dos IPs origen

Misma consulta, redes cliente distintas. Si una funciona y otra recibe REFUSED, casi siempre es una ACL, una vista, o «recursión permitida para A pero no para B».

3) Determina si hay recursión involucrada

Consulta un nombre externo (como algo que no esté en tus zonas) directamente contra el servidor que sospechas. Si lo rechaza pero responde nombres internos,
estás ante controles de recursión o restricciones de reenvío.

4) Busca motores de política (RPZ, firewall DNS, vistas, reglas geográficas)

Si el rechazo es específico por nombre (solo ciertos dominios), asume política. Si es específico por cliente (ciertas subredes), asume ACL/vista/enlace de interfaz.

5) Revisa los logs al final—pero revísalos correctamente

Los logs pueden confirmar la ruta de decisión, pero en muchos entornos están rate-limited, muestreados, o solo en el nodo que rechazó dentro de una flota anycast.
Usa los logs para validar una hipótesis, no para generarla.

Broma #1: La política DNS es como el café de la oficina: todo el mundo depende de ella, nadie la posee, y cuando es mala, la productividad se viene abajo.

Dónde se genera REFUSED: resolver vs autoritativo vs middleboxes

Resolvers recursivos

Los resolvers recursivos rechazan consultas cuando están configurados para hacerlo según la IP del cliente, la interfaz o el tipo de consulta. Casos comunes:

• Recursión deshabilitada o restringida: el servidor responderá autoritativamente para sus propias zonas, pero rechazará recursión para externos.
• ACL deniega al cliente: «access-control» (Unbound) o «allow-query/allow-recursion» (BIND) bloquea la fuente.
• Zona de política / firewall DNS: RPZ u equivalente rechaza (o reescribe) según el dominio.
• Limitación por tasa / controles de abuso: algunos stacks rechazan cuando superas umbrales.

Servidores autoritativos

Los servidores autoritativos rechazan cuando la consulta está fuera de lo que sirven, cuando las vistas restringen quién puede preguntar, o cuando se intenta una operación especial:

• AXFR/IXFR rechazado: las transferencias de zona comúnmente se rechazan sin allow-transfer explícito y a veces TSIG.
• Actualización dinámica rechazada: las actualizaciones RFC2136 requieren allow-update y normalmente TSIG. De lo contrario: rechazo.
• ACL de consulta: algunas implementaciones autoritativas restringen quién puede consultar zonas internas.

Reenviadores y “DNS en el medio”

REFUSED también puede venir de un forwarder (como CoreDNS, dnsmasq, systemd-resolved, o un proxy DNS en la nube) que aplica reglas antes de reenviar,
o que reenvía un REFUSED que recibió aguas arriba.

Luego están los middleboxes: firewalls que inspeccionan DNS, «pasarelas de seguridad» que responden en nombre del DNS, o balanceadores con lógica de health-check.
Pueden generar un comportamiento similar a REFUSED que parece una decisión del servidor DNS pero es realmente un aparato de red con un mal día.

Las políticas que te bloquean: ACLs, controles de recursión, RPZ, vistas, TSIG y aliados

1) ACLs de cliente: “allow-query” y “allow-recursion” (BIND)

En BIND, las dos perillas que la gente confunde son allow-query y allow-recursion. No son intercambiables.

• allow-query: quién puede hacer preguntas en absoluto (para las zonas servidas, y a veces globalmente).
• allow-recursion: quién puede usar recursión (obtener respuestas desde otros sitios).

Un servidor puede estar dispuesto a responder autoritativamente para corp.example pero rechazar recursión para nombres de Internet. Eso es normal y bueno.
El problema ocurre cuando despliegas «un resolver para gobernarlos a todos» y olvidas que la mitad de tus clientes no están en la lista de subredes permitidas.

2) access-control de Unbound: deceptivamente simple

Unbound tiende a ser más claro: defines reglas access-control por subred y acción (allow/refuse/deny).
Pero «más claro» no significa «difícil de estropear».

Si agregas una regla amplia refuse antes de una allow más específica (o malinterpretas la precedencia), puedes bloquear una región.
Y en una flota anycast, puedes bloquear solo los nodos que aplicaron ese cambio.

3) Vistas y split-horizon: buena idea, bordes afilados

Las vistas (BIND) o constructos similares permiten respuestas diferentes según la dirección de origen. Son geniales para:

• registros internos vs externos
• zonas privadas solo accesibles vía VPN
• migraciones en la nube donde diriges ciertas redes a nuevos endpoints

También generan un patrón clásico de REFUSED: los clientes caen en la «vista equivocada» y reciben REFUSED porque esa vista no tiene recursión,
no tiene acceso a la zona, o tiene ACLs más estrictas.

4) RPZ / firewall DNS: cuando el servidor rechaza porque el nombre es “malo”

Muchas empresas ejecutan Response Policy Zones o funciones similares de firewall DNS. Según la política, un dominio bloqueado podría devolver:
NXDOMAIN, una IP de walled-garden, o ocasionalmente un comportamiento parecido a refusal (o un REFUSED de un motor de política aguas arriba).

Si REFUSED es específico de un dominio y consistente entre clientes, sospecha RPZ o un resolver de seguridad aguas arriba. Si es específico de dominio e inconsistente,
sospecha múltiples resolvers con versiones de política distintas.

5) Transferencias de zona (AXFR/IXFR): el rechazo es por defecto

Si intentas un AXFR desde una estación de trabajo aleatoria y obtienes REFUSED: felicidades, alguien hizo al menos una cosa bien.
Las transferencias deben permitirse explícitamente a las secundarias, a menudo con TSIG.

6) Actualizaciones dinámicas: TSIG o no sucede

Las actualizaciones RFC2136 son potentes y peligrosas. Un rechazo aquí normalmente significa falta de clave, clave equivocada, algoritmo incorrecto, o una update-policy mal configurada.

7) Enlace a interfaz y sorpresas de IP de origen

Las ACLs DNS se evalúan contra la IP de origen. En NAT, VPN, Kubernetes y balanceadores en la nube, la «IP de origen que crees tener»
a menudo no es la IP de origen que el servidor DNS ve.

REFUSED aparece tras un cambio de red porque la ACL no cambió con él.

8) DNS sobre TCP / EDNS / fragmentación: política por accidente

Algunos entornos restringen TCP/53 o bloquean respuestas UDP grandes. Cuando un resolver intenta UDP, recibe truncamiento, reintenta con TCP y TCP está bloqueado,
normalmente ves timeouts. Pero algunos middleboxes y proxies responden con REFUSED o un fallo inmediato.

No asumas que REFUSED es puramente un «problema de configuración DNS». Puede ser «seguridad de red piensa que DNS debe ser siempre 512 bytes».

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto durante incidentes. Cada una incluye el comando, un fragmento realista de salida, qué significa y qué decisión tomar.
Úsalas como un guion repetible de investigación, no como un ritual único.

Task 1: Reproducir con dig y capturar el RCODE claramente

cr0x@server:~$ dig @10.20.30.40 www.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @10.20.30.40 www.example.com A +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59821
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.                IN      A

;; Query time: 2 msec
;; SERVER: 10.20.30.40#53(10.20.30.40) (UDP)
;; WHEN: Tue Dec 31 11:02:18 UTC 2025
;; MSG SIZE  rcvd: 56

Qué significa: El servidor DNS respondió rápidamente con REFUSED. La ruta de red está bien.

Decisión: Deja de depurar enrutamiento y firewalls primero. Empieza a mirar ACLs/política en ese servidor o en la capa que está delante.

Task 2: Comprobar si la recursión es el problema (misma consulta con recursión deseada)

cr0x@server:~$ dig @10.20.30.40 www.example.com A +recurse

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 3452
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: El rechazo ocurre independientemente del bit RD. Probablemente se trate de «cliente no permitido» en lugar de «recursión no disponible».

Decisión: Valida ACLs de cliente y vistas. Si esperabas respuestas autoritativas, confirma que estás consultando el servidor correcto.

Task 3: Verificar que el servidor responde a cualquiera (comparar desde una subred conocida buena)

cr0x@server:~$ dig @10.20.30.40 www.example.com A +short
93.184.216.34

Qué significa: Desde este host funciona. Por tanto el servidor puede responder; el rechazo es específico del cliente o de la ruta.

Decisión: Compara IPs de origen y NAT. Identifica qué IP ve el servidor DNS para el cliente que falla.

Task 4: Confirmar qué resolver está usando realmente tu cliente

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.53
       DNS Servers: 127.0.0.53

Qué significa: systemd-resolved está en juego; tu «servidor DNS» podría ser un stub que reenvía a otro sitio.

Decisión: Consulta al resolver upstream directamente, no solo a 127.0.0.53, o inspecciona los upstream de resolved con resolvectl dns.

Task 5: Identificar servidores DNS upstream configurados en el host (y sorpresas)

cr0x@server:~$ resolvectl dns
Global:
Link 2 (ens192): 10.20.30.40 10.20.30.41
Link 3 (tun0): 172.16.0.53

Qué significa: La interfaz VPN proporciona su propio resolver. REFUSED podría ocurrir solo cuando la VPN está activa y cambian prioridades de ruta.

Decisión: Reprueba apuntando a cada IP de resolver directamente. Decide si las reglas de split-DNS están mal aplicadas.

Task 6: Determinar si estás golpeando un servidor solo autoritativo

cr0x@server:~$ dig @10.20.30.40 corp.example SOA +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11906
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
corp.example.     3600    IN      SOA     ns1.corp.example. hostmaster.corp.example. 2025123101 7200 3600 1209600 3600

Qué significa: El servidor es autoritativo para corp.example (flag AA). Podría rechazar recursión para todo lo demás por diseño.

Decisión: Si los clientes usan esto como resolver general, corrige la arquitectura: apunta a resolvers recursivos, no a autoritativos únicamente.

Task 7: Probar explícitamente la disponibilidad de recursión con una consulta tipo hints de root

cr0x@server:~$ dig @10.20.30.40 . NS +recurse

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41223
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: Este servidor rechaza la recursión (o te rechaza a ti). Consultar la raíz debería ser respondible por un resolver recursivo.

Decisión: Revisa ajustes de recursion y ACLs de cliente. Confirma si este servidor tiene que recurrir para tu IP de origen.

Task 8: Comprobar el match de vistas y ACLs en BIND (lado servidor)

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,120p'
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-recursion { 10.20.0.0/16; 127.0.0.1; };
        allow-query-cache { 10.20.0.0/16; 127.0.0.1; };
};

view "internal" {
        match-clients { 10.20.0.0/16; };
        recursion yes;
};

view "external" {
        match-clients { any; };
        recursion no;
};

Qué significa: Clientes fuera de 10.20.0.0/16 caen en la vista «external» con recursión deshabilitada; pueden ver REFUSED para búsquedas recursivas.

Decisión: O amplía match-clients para incluir las redes deseadas (VPN, rangos NAT), o asegúrate de que esos clientes usen el resolver correcto.

Task 9: Comprobar zonas locales en Unbound

cr0x@server:~$ sudo unbound-control list_local_zones
name type
. transparent
corp.example. transparent
blocked.example. static

Qué significa: Pueden existir zonas locales y políticas. No todos los rechazos son «ACL»; algunos son «política local».

Decisión: Inspecciona unbound.conf para access-control: y zonas de política; confirma el comportamiento esperado para los dominios bloqueados.

Task 10: Inspeccionar líneas access-control de Unbound rápidamente

cr0x@server:~$ sudo grep -nE '^(access-control|interface|do-tcp|do-udp)' /etc/unbound/unbound.conf
12:interface: 10.20.30.40
23:do-udp: yes
24:do-tcp: yes
41:access-control: 10.20.0.0/16 allow
42:access-control: 0.0.0.0/0 refuse

Qué significa: Por defecto se niega a todo el mundo excepto 10.20.0.0/16. Si tus clientes ahora están en 10.21.0.0/16, están bloqueados.

Decisión: Añade la(s) nueva(s) subred(es) como allow, o arregla el NAT para que los clientes aparezcan desde una IP permitida.

Task 11: Comprobar si REFUSED es en realidad “AXFR denegado”

cr0x@server:~$ dig @10.20.30.53 corp.example AXFR

; Transfer failed.

Qué significa: Las transferencias están bloqueadas (como deben por defecto). Algunos servidores devuelven REFUSED; dig solo informa fallo.

Decisión: Si configuras una secundaria: implementa allow-transfer en la primaria y TSIG entre ellas. No «abrir temporalmente a cualquiera».

Task 12: Validar permisos de transferencia en BIND (lado servidor)

cr0x@server:~$ sudo named-checkconf -p | grep -n 'allow-transfer' -n
248:        allow-transfer { key "xfr-tsig"; 10.20.30.54; };

Qué significa: Las transferencias están permitidas solo para 10.20.30.54 y solo con una clave TSIG. Si la IP de tu secundaria cambió, será rechazada.

Decisión: Actualiza la lista de direcciones permitidas y rota la clave TSIG correctamente. Trátalo como un cambio controlado, no como un apaño de emergencia.

Task 13: Comprobar rechazo de actualización dinámica por falta de TSIG

cr0x@server:~$ nsupdate -v <<'EOF'
server 10.20.30.53
zone corp.example
update add test01.corp.example 60 A 10.20.40.10
send
EOF
update failed: REFUSED

Qué significa: El servidor rechaza actualizaciones sin la autenticación adecuada. Bien hecho.

Decisión: Usa TSIG y update-policy. Si esto debía funcionar, el cliente no usa la clave correcta o estás golpeando la vista equivocada.

Task 14: Revisar logs del servidor por la razón explícita de “denied” (ejemplo BIND)

cr0x@server:~$ sudo journalctl -u bind9 -n 20 --no-pager
Dec 31 11:02:18 ns1 named[1442]: client @0x7f9a64012a00 10.21.5.18#43812 (www.example.com): query (cache) 'www.example.com/A/IN' denied
Dec 31 11:02:18 ns1 named[1442]: client @0x7f9a64012a00 10.21.5.18#43812 (www.example.com): query failed (REFUSED) for www.example.com/IN/A at query.c:7750

Qué significa: El servidor negó explícitamente una consulta de caché (recursiva) desde 10.21.5.18.

Decisión: Añade 10.21.0.0/16 a allow-recursion / allow-query-cache (o enruta esos clientes al resolver correcto).

Task 15: Probar desajuste NAT/IP de origen (captura en el servidor)

cr0x@server:~$ sudo tcpdump -ni any port 53 and host 10.21.5.18 -c 3
tcpdump: data link type LINUX_SLL2
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:02:18.412345 ens192 In  IP 192.0.2.45.53512 > 10.20.30.40.53: 59821+ A? www.example.com. (32)
11:02:18.412912 ens192 Out IP 10.20.30.40.53 > 192.0.2.45.53512: 59821 Refused 0/0/1 (56)

Qué significa: El «cliente» 10.21.5.18 está realmente NATeado a 192.0.2.45 desde la perspectiva del servidor DNS.

Decisión: Arregla las ACLs para incluir el rango de egress NAT, o ajusta el enrutamiento para preservar la IP original del cliente (si es factible).

Task 16: Verificar si un forwarder devuelve REFUSED desde upstream

cr0x@server:~$ dig @10.20.30.10 www.example.com A +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 51001
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: El forwarder indica que la recursión está disponible (RA), pero aún así rechaza. Eso suele apuntar a política (RPZ/seguridad) o rechazo aguas arriba.

Decisión: Consulta al upstream del forwarder (si se conoce) o revisa la configuración del forwarder para bloqueos de dominio y ACLs.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El outage causado por una suposición equivocada

Una empresa mediana tenía dos servidores BIND por datacenter. Estaban etiquetados como «DNS1/DNS2» en el inventario y todos los trataban como intercambiables.
Un par era autoritativo para zonas internas y también hacía recursión para clientes. El otro par era solo autoritativo para varias zonas delegadas usadas
por una plataforma legacy.

Durante una renovación de red, un equipo actualizó los scopes DHCP y accidentalmente apuntó una gran subred de oficina al par que era autoritativo-only.
Los síntomas fueron extrañamente selectivos: los nombres internos en corp.example resolvían bien, porque los auth servers eran autoritativos.
Todo lo demás—logins SaaS, repositorios de paquetes, APIs externas—comenzó a devolver REFUSED.

Los primeros respondedores persiguieron firewalls y enlaces ISP. Vieron «REFUSED» e interpretaron que «DNS remoto nos bloquea».
Mientras tanto, los servidores DNS hacían exactamente lo que fueron construidos para hacer: «Soy autoritativo para estas zonas; no soy tu resolver recursivo».

La solución fue aburrida: corregir las opciones DHCP y añadir monitorización que compruebe la recursión en el VIP del resolver, no solo «puerto 53 abierto».
La lección fue más aguda: no nombres servidores con ambigüedad de rol. «DNS1» no es un rol; es una confesión.

Mini-historia 2: La optimización que salió mal

Otra organización quiso reducir la carga del resolver. Alguien propuso un enfoque «inteligente»: enrutar oficinas remotas a un forwarder regional,
luego a resolvers centrales. Parecía ordenado en diagramas: menos saltos, más cache en el edge.

Implementaron un forwarder dnsmasq en routers de sucursal con cache agresiva y una ACL mínima: permitir solo la subred de la sucursal.
Luego se desplegó una VPN. Portátiles remotos entraron en la red de la sucursal por túnel, pero sus IPs de origen venían de un pool distinto.
El dnsmasq del router vio «origen desconocido» y devolvió REFUSED inmediatamente.

El incidente fue doloroso porque era intermitente: algunos usuarios estaban en Wi‑Fi (NATeados a un espacio permitido), otros en cable (no NATeados),
otros remotos (tunneled). Mismo portátil, distinta hora del día, distinto resultado.

Lo arreglaron removiendo cache y política del router por completo: los clientes de sucursal usaban resolvers centrales directamente sobre la VPN,
y el router solo proporcionaba DHCP. La optimización no era mala; simplemente movió el control de política al lugar más frágil del sistema.

Mini-historia 3: La práctica aburrida y correcta que salvó el día

Una empresa global ejecutaba resolvers recursivos anycast con ACLs estrictas y RPZ. También tenían una práctica que parecía burocrática:
todo cambio de política de resolver requería un «diff de política» adjunto al ticket de cambio, además de un despliegue canario a un sitio.

Un día, un ingeniero actualizó los rangos de clientes permitidos para incluir una nueva VPC en la nube. El cambio era correcto en intención pero erróneo en un detalle:
añadió el CIDR de la VPC en un archivo de entorno pero no en el ACL generado para producción.

El sitio canario mostró inmediatamente REFUSED para clientes en esa VPC. El runbook tenía una comprobación específica: ejecutar una consulta desde una instancia en la VPC,
confirmar que golpea el nodo canario y confirmar status: NOERROR para recursión.
El ingeniero detectó la discrepancia antes del despliegue a toda la flota.

Sin drama. Sin bridge call ejecutivo. Simplemente revirtieron el cambio y lo reemitieron con la generación correcta. Lo aburrido ganó otra vez.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente específica. El consejo genérico provoca outages genéricos.

1) Síntoma: REFUSED para nombres externos, nombres internos funcionan

• Causa raíz: el cliente usa un servidor autoritativo-only; recursión deshabilitada; o el cliente cae en una vista sin recursión.
• Solución: apunta los clientes a resolvers recursivos; o habilita recursión para la vista correcta y configura allow-recursion correctamente.

2) Síntoma: REFUSED solo para usuarios VPN

• Causa raíz: las ACLs no incluyen el pool VPN; split-DNS mal configurado; la VPN empuja un resolver distinto con política más estricta.
• Solución: incluye el CIDR VPN en allow-recursion/access-control; asegura que los clientes VPN usen el resolver previsto; valida el comportamiento NAT.

3) Síntoma: REFUSED solo para un dominio (o categoría de dominios)

• Causa raíz: RPZ/firewall DNS; resolver de seguridad upstream; dominio puesto en bloque estático de «local-zone».
• Solución: confirma la intención de la política; añade una excepción; despliega la política de forma consistente; documenta quién es responsable de la decisión de bloqueo.

4) Síntoma: REFUSED tras mover resolvers detrás de un load balancer

• Causa raíz: cambia la IP de origen (SNAT), por lo que las ACLs ya no coinciden; los health-checks vienen de un rango no confiable y son rechazados.
• Solución: preserva la IP de origen donde sea posible; si no, añade los rangos de egress del LB a las ACLs; establece un «allow» explícito para las fuentes de health-check.

5) Síntoma: AXFR/IXFR falla con “Transfer failed” o REFUSED

• Causa raíz: falta allow-transfer; IP de secundaria cambió; TSIG mismatch; mismatch de vista (la secundaria golpea la vista equivocada).
• Solución: añade allow-transfer para las IP correctas; usa TSIG; verifica que ambos extremos concuerden en nombre/algoritmo de clave; asegura que match-clients incluya la secundaria.

6) Síntoma: Actualizaciones dinámicas devuelven REFUSED

• Causa raíz: nsupdate sin TSIG; update-policy no permite el nombre; el servidor no es primario para esa zona; vista equivocada.
• Solución: configura TSIG en el cliente; ajusta update-policy con privilegio mínimo; envía actualizaciones al primario; valida la selección de vista.

7) Síntoma: Algunos sitios anycast rechazan; otros responden

• Causa raíz: despliegue de config/política inconsistente; ACLs locales por sitio; forwarders upstream distintos; replicación incompleta de RPZ.
• Solución: aplica convergencia de configuración; añade smoke tests por sitio; identifica qué nodo sirvió la consulta vía CHAOS TXT o etiquetado de instancia.

8) Síntoma: picos de REFUSED solo bajo carga

• Causa raíz: rate limiting configurado para rechazar; detección de abuso; upstream rechazando por comportamiento del resolver (demasiados clientes detrás de un NAT).
• Solución: ajusta el rate limiting; arregla fan-in de NAT; añade más IPs de egress; verifica que no estés actuando accidentalmente como una botnet.

Broma #2: Si «temporalmente» permites recursión para any, Internet te RSVP inmediatamente.

Listas de verificación / plan paso a paso

Paso a paso: aislar la capa que está rechazando

1. Consulta con dig contra el resolver configurado. Registra IP del servidor, status, flags, UDP/TCP.
2. Evita el stub. Si se usa systemd-resolved, consulta las IPs upstream reales directamente.
3. Consulta el mismo nombre desde dos redes. LAN de oficina vs VPN, o un pod vs una VM. Anota diferencias.
4. Consulta una zona autoritativa que esperes. Confirma que aparece el flag AA donde corresponde; confirma el rol correcto del servidor.
5. Comprueba la recursión explícitamente. Consulta la raíz o un dominio claramente externo con +recurse.
6. Revisa los logs del servidor por «denied/refused». Confirma la IP de origen que el servidor ve.
7. Valida NAT y enrutamiento. Captura paquetes en el servidor si es necesario para revelar la dirección verdadera del cliente.
8. Identifica capas de política. RPZ, vistas, firewall DNS upstream, cadenas de reenvío.
9. Corrige con el privilegio mínimo. Expande ACLs con precisión; evita abrir recursión a rangos amplios.
10. Prueba de regresión. Prueba desde un conjunto representativo de clientes. Luego monitoriza exposición de resolver abierto.

Checklist: cambios seguros que reducen incidentes REFUSED sin debilitar seguridad

• Define roles explícitos para resolvers: recursivo-only, autoritativo-only, o mixto (y documenta).
• Mantén un inventario de CIDRs de cliente permitidos para recursión; actualízalo con tickets de cambio de red.
• Para VPN y nube: decide si la IP de origen se preserva o se NATea; escribe ACLs que coincidan con la realidad.
• Para anycast: aplica convergencia de config y añade un indicador por nodo de «versión de política».
• Para RPZ: establece un proceso de excepciones y un propietario claro para decisiones de política.
• Monitorea aumentos en la tasa de REFUSED y desglósalos por subred cliente y tipo de consulta.
• Prueba AXFR/IXFR y actualizaciones desde secundarias/automatización tras cada cambio DNS.

Checklist: qué no hacer (a menos que disfrutes del pager)

• No habilites recursión para any para «hacer que funcione». Así te conviertes en un incidente de resolver abierto.
• No ejecutes enforcement de política en routers de sucursal a menos que puedas actualizarlos y auditarlos como producción.
• No asumas que la «IP de cliente» es la que el servidor ve; verifica con logs o tcpdump.
• No mezcles roles autoritativos y recursivos a la ligera; si lo haces, documenta la intención y aplica vistas.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre REFUSED y NXDOMAIN?

NXDOMAIN significa que el servidor respondió y el nombre no existe en el espacio de nombres que comprobó. REFUSED significa que el servidor se negó a responder por política.

2) ¿Puede un servidor autoritativo devolver REFUSED para consultas normales?

Sí. Los servidores autoritativos pueden restringir quién puede consultar ciertas zonas (solo internas), y comúnmente rechazan AXFR/IXFR y actualizaciones dinámicas sin permiso.

3) ¿Por qué recibo REFUSED solo desde ciertas subredes?

Eso casi siempre es un problema de ACL o de match de vista. O esas subredes no están en allow-recursion/access-control, o caen en una vista con recursión deshabilitada.
NAT puede hacer que esto parezca aleatorio si la IP aparente de origen cambia según la ruta.

4) ¿Por qué dig muestra “ra” (recursion available) pero el estado es REFUSED?

«RA» es una bandera de capacidad; no significa que la recursión esté permitida para tu origen. Muchos resolvers son capaces de recursión pero la niegan a clientes no autorizados.
Algunos forwarders también pasan RA mientras aplican su propia política.

5) ¿REFUSED siempre es una mala configuración?

No. REFUSED frecuentemente es una postura de seguridad correcta: negar recursión al internet, negar transferencias de zona ampliamente, negar actualizaciones sin firma.
Se convierte en un problema cuando la política y los usuarios previstos se separan.

6) ¿Cómo se relacionan RPZ y firewalls DNS con REFUSED?

RPZ es un mecanismo de política que puede bloquear o reescribir respuestas DNS según el nombre o la respuesta. Dependiendo de la implementación y la elección de política,
los clientes pueden ver NXDOMAIN, un registro de walled-garden, o un rechazo propagado desde un resolver de política aguas arriba.

7) ¿Por qué los pods de Kubernetes a veces ven REFUSED cuando los nodos no?

Los pods suelen consultar CoreDNS, que reenvía a resolvers upstream. El upstream puede ver la IP del nodo, una IP NAT, o una IP de gateway NAT en la nube.
Si las ACLs de recursión no incluyen esa IP aparente, obtienes REFUSED. Otra causa: plugins de política de CoreDNS o configuraciones de stub-domain.

8) ¿Cuál es la forma más segura de “arreglar” REFUSED para clientes legítimos?

Identifica el rango exacto de IPs de origen del cliente tal como lo ve el servidor que rechaza, luego añade la regla allow más estrecha necesaria (allow-recursion/access-control),
idealmente en la vista correcta. Valida que no has creado un resolver abierto. Prueba desde múltiples redes.

9) ¿Puede DNSSEC causar REFUSED?

Los fallos de validación DNSSEC típicamente llevan a SERVFAIL, no a REFUSED. Pero capas de política alrededor de DNSSEC (resolvers de seguridad, firewalls DNS) pueden decidir rechazar
ciertos comportamientos o clientes. Trata DNSSEC como un factor que complica, no como el culpable por defecto de REFUSED.

10) ¿Debo devolver REFUSED o abandonar paquetes para clientes bloqueados?

Devolver REFUSED es operativamente más agradable: los clientes fallan rápido y puedes diagnosticarlo. Abandonar paquetes puede parecer un outage de red.
Si estás bloqueando tráfico abusivo a gran escala, los drops pueden ser apropiados, pero para enforcement de política interna, REFUSED normalmente reduce el tiempo de incidente.

Conclusión: siguientes pasos que realmente reducen incidentes

REFUSED no es un código misterioso. Es una decisión de política, y DNS está lleno de políticas: quién puede recursar, quién puede transferir, quién puede actualizar,
qué nombres se bloquean, qué clientes reciben qué vista. Cuando REFUSED te afecta, suele ser porque la realidad de tu red cambió más rápido que tu política DNS.

Haz esto a continuación:

1. Mapea los roles de los resolvers (recursivo vs autoritativo) y deja de apuntar clientes al servidor equivocado.
2. Inventaría los rangos de origen permitidos tal como los ve el resolver (incluyendo NAT y pools VPN).
3. Añade una prueba de regresión que ejecute dig desde cada entorno cliente principal y alerte sobre picos de REFUSED.
4. Trata la política como código: configs diffables, despliegue canario y un propietario claro para reglas RPZ/firewall DNS.

El objetivo no es eliminar REFUSED. El objetivo es hacer los rechazos intencionales, documentados y predecibles—para que lo único que se bloquee sea el tráfico malicioso,
no tu propio negocio.