Curso Bases del DNS, instalación y configuración moderna

Módulo 3: DNS Recursivos.

Capítulo 1: Introducción y Arquitectura.

Los DNS recursivos, o resolvers, son el otro lado de la moneda del sistema DNS. Los
autoritativos mantienen el árbol, pero no sirve de nada sin alguien que sea capaz de
recorrerlo y llegar a la respuesta final.

En este módulo veremos las particularidades del DNS recursivo, en qué fijarse al
configurarlo, y algunas funciones avanzadas.

La definición que usaremos acá de un DNS recursivo es lo que se llama un "full

resolver" en el RFC de Terminología del DNS. Se trata del servicio que realiza
recursión en el árbol autoritativo del DNS, buscando la respuesta final a la consulta
de sus clientes, manteniendo un caché local de toda la información que maneja.

Lo principal es primero diferenciarnos de los DNS autoritativos, pero también indicar

que no es lo mismo que un DNS "stub", que funciona a nivel de un sistema operativo
y no responde solicitudes externas; y que un DNS "forwarder" que atiende solicitudes
externas, maneja un caché, pero no hace recursión a los autoritativos sino que deriva
las consultas a otro DNS.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 1

En cierto sentido podemos decir que los DNS recursivos son más simples de operar,
porque al contrario de un autoritativo que debe estar abierto y atender a toda la
Internet, un recursivo solo atiende a sus clientes. Un recursivo no debe estar abierto
a toda Internet, sino solo a los usuarios de la empresa, organización, o proveedor de
Internet que atiende. Esto nos permite optimizar de mejor manera su funcionamiento,
y detectar de forma simple cualquier bug o malfuncionamiento, ya que es nuestra
propia red. Este servicio que entrega un resolver a sus clientes se le llama el
"downstream".

Sin embargo, esta aparente simpleza se termina cuando consideramos el "upstream"

de un resolver. Un resolver debe ser capaz de contactar a todos los autoritativos de
Internet, cuando está en búsqueda de una respuesta. Es en esta función cuando es
posible también encontrarse con muchas implementaciones defectuosas o bloqueos.
Creo que lo más complejo en implementar un resolver es la parte de la robustez, ser
capaz de detectar y en cierta forma esquivar los problemas, para finalmente llegar a
obtener la respuesta que necesita el usuario.

Existe una discusión filosófica desde hace muchos años de cuánto es conveniente
alejarse del estándar frente a autoritativos que no se comportan bien. Hay una escuela
de pensamiento que dice que lo importante es obtener la respuesta, sea como sea.
Esto es, llenar los resolvers de casos de borde y atajos para ser capaces de
enfrentarse a la internet salvaje. Pero por otro lado, hay otros que piensan que hay
que castigar ejemplificadoramente a los autoritativos que no cumplen las reglas, y
negarse a resolver sus nombres. Tiene que existir un límite a lo mal configurado que
un servicio pueda estar. Porque en el momento que renunciamos al estándar y
aceptamos comportamientos errados, eso nunca se solucionará. La Internet funciona
porque todos aceptamos regirnos por ciertas reglas, y los que no las quieren seguir,
deben aceptar las consecuencias, que en este caso quiere decir que sus nombres no
serán resolvibles.

En lo personal simpatizo con esta última vertiente, pero creo que debe ser un proceso
gradual y coordinado. Es por esto que se han realizado hasta el momento dos "DNS
flag days", unas campañas coordinadas entre los desarrolladores de software de
resolutores y grandes servicios públicos, donde entre todos se decide qué es lo más

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 2

grave que ocurre, se coordina una acción a tomar en forma conjunta, se hace una
campaña de educación, y en un día se cambia el comportamiento de los resolvers.
Es importante estar atentos a estos flag days, que seguirán ocurriendo, porque
demuestran la forma correcta de ir mejorando la Internet.

En una sección más adelante veremos los detalles de estos DNS flag days.

Arquitectura de recursivos
Lo más importante al dimensionar un servicio de resolvers es la cantidad de clientes
que tendrá. De eso depende no solo el tráfico ni la carga, sino sobre todo el uso del
caché del resolver. Un resolver con un caché muy pequeño pasará mucho tiempo
lleno, y tendrá que hacer mucha resolución completa en Internet. Un resolver con un
caché grande será capaz de almacenar muchas de las respuestas, y por ende liberará
de carga en la resolución en Internet, dando un servicio muy rápido a sus clientes. El
caché lo es todo, lo que significa capacidad de memoria.

Sin embargo, dicho todo esto, no son grandes números de los que estamos hablando,
y además es posible ir escalando en forma simple una vez que se esté llegando a
síntomas de agotamiento.

Yo tengo un full resolver en mi laptop, que me funciona sin problemas desde hace
años.

Hay oficinas pequeñas de 100 personas que funcionan con un resolver virtualizado,
con 8GB de RAM, con resultados perfectos.

Un resolver debe tener un acceso a Internet ojalá lo más limpio posible, sin
limitadores, ni cortafuegos, ni controladores de estado. Solo se permite tráfico de
salida, con las respuestas respectivas. Hacia adentro, el llamado "downstream",
puede estar bloqueado vía cortafuegos y la configuración propia del resolver, para
que solo escuche y atienda a sus propios clientes.

En lo posible hay que tener al menos dos resolvers, ojalá en redes distintas, para
estar cubiertos frente a caídas de uno de ellos. Todos los clientes aceptan más de 1
resolver, y realizan algún tipo de balance entre ellos.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 3

Para mayor robustez se puede también utilizar anycast en pequeña escala, dentro de
la misma red, que permite mantener una IP única para la configuración de los clientes,
y utilizar trucos de ruteo para que respondan varias máquinas en forma redundante.

Otra arquitectura típica en el servicio de resolvers es presentar a los usuarios unos

resolvers más cercanos a ellos que solo hacen caché y derivan la resolución completa
a otros resolvers, ubicados en el borde de la red de la empresa, hacia Internet. Estos
resolvers que solo hacen caché se llaman "forwarders", porque derivan la resolución
a otro que sí es un resolver completo.

Capítulo 2: Algunos software recursivos de código abierto

Acá tenemos a los mismos fabricantes de DNS autoritativos, pero esta vez en su
versión de recursivos.

Como contamos antes, Bind de ISC fue uno de los primeros y por mucho tiempo el
estándar de facto. El mismo servicio de autoritativo de Bind puede funcionar como
recursivo, y realizar las dos labores al mismo tiempo. Sin embargo como también
vimos antes, no es recomendable mezclar las dos funciones. Incluso si quiere utilizar
Bind para las dos funciones, es mejor que los tenga en máquinas distintas, o dos
instancias separadas, para no mezclar los cachés.

Dicho esto, las otras empresas que mantienen solo DNS autoritativos, también tienen
otro software para los recursivos. Acá los tenemos. La gente de Power DNS tiene a
"Power DNS Recursor", la de NSD tiene a "Unbound", y los de Knot DNS tienen a
"Knot resolver". Cualquiera de ellos es una buena elección, y los invito a revisar sus
particularidades que son bastante similares a lo indicado en la sección de
autoritativos. En especial podría recomendar fuertemente revisar Unbound, que
debido a su simpleza en la configuración y especialización en lo recursivo podría ser
preferible a otros más complejos.

En estos capítulos utilizaremos Bind, al igual que en los ejemplos en los autoritativos.
Todas las funciones tienen su equivalente en los otros softwares.

Mención aparte acá, en vez de hablar de software de DNS recursivo privado, son los
llamados "resolvers públicos", que mantienen ciertas empresas. Estos son servicios

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 4

abiertos a todo Internet que dan el servicio de recursivo. Los más conocidos son los
llamados "quad-DNS", porque escogieron números IP significativos. Uno de los
primeros famosos fue Google DNS, el 8.8.8.8. Luego tenemos a Cloudflare con su
1.1.1.1, y Quad9 con 9.9.9.9. Hay otros servicios más antiguos que además del
servicio de resolución daban bloqueos vía DNS de tipo parentales o anti-amenazas,
como OpenDNS, CleanBrowsing, AdGuard, OpenNIC, Yandex, etc.
¿Es conveniente usar un resolver público? Pese a los argumentos a favor, como su
posible rapidez y estabilidad, hay dos grandes problemas. El primero es de privacidad.
Un resolver es capaz de almacenar mucha información de navegación de sus
usuarios, lo que puede ser inconveniente. Por lo mismo, es mejor confiar en su propio
proveedor de Internet, sea un ISP o su empresa, porque de todas formas ellos ya
tienen su información de navegación. No está filtrando nada nuevo. Muchas de las
empresas que proveen DNS recursivo público tienen jurisdicción en otros países,
sujetos a leyes y normas que podrían afectar a los usuarios. Y hay también algunas
que -abiertamente o no- pueden estar en su derecho de vender los datos a compañías
de publicidad o análisis de datos. Los usuarios en cambio tienen ya contratos de
servicios o legislación local que les permite defenderse de mejor forma frente a
abusos de su propio resolver dependiente de la empresa de conectividad local.

El segundo inconveniente tiene que ver con eficiencia. Hay bastantes servicios de
caché de contenido web, como los CDN, que utilizan a los resolvers para elegir la
ubicación más cercana al usuario. Si yo utilizo el resolver de mi ISP, ese resolver
muchas veces está optimizado para ante una consulta por un proveedor de video, por
ejemplo YouTube, me envíe como respuesta una IP que está dentro del propio ISP,
logrando que obtenga un servicio muy cercano. Si, sin embargo, utilizo un resolver
externo fuera de mis redes, puede que al acceder al mismo video sea enviado a una
IP lejana, que ya no tendrá la misma velocidad de servicio.

Por lo mismo, mi recomendación es que siempre se utilice un resolver lo más cercano

posible, y de su mismo proveedor de Internet. Por supuesto que hay casos especiales
en que este resolver funciona mal, o hay prácticas de seguridad y bloqueos que
puedan impedir la navegación, en cuyos casos el último resorte que queda es pasar
a un DNS público. Pero siempre debe ser la excepción y no la regla, y debe re-
evaluarse cada cierto tiempo.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 5

Del punto de vista del uso de forwarders, también es una práctica cuestionable. Se
puede considerar que una empresa que otorga el servicio de Internet, debería
entregar el servicio de resolución DNS en conjunto. Y esta resolución debiera ser
completa, no delegarla en un servicio externo con una jurisdicción completamente
distinta, con la que no se tiene ningún tipo de contrato o acuerdo. Puede haber
violaciones de privacidad que sean importantes, dependiendo de la legislación en
cada caso.

Capítulo 3: Configuración en Bind.

Ahora veremos lo más importante a tener en cuenta en la configuración de un servidor
recursivo.

Un recursivo necesita dos cosas para funcionar: la lista de IPs de los root servers del
árbol DNS, y la llave pública DNSSEC de la raíz. Con esos dos datos es suficiente
para partir y comenzar a dar servicio. Como vimos, las direcciones IPs de la raíz se
llaman "root hints", y es generalmente un dato que viene de paquete en el software,
pero que se puede configurar a mano por el operador. Es muy raro que un root server
cambie sus IPs, pero ha ocurrido de vez en cuando. En estos casos se hace con
mucho cuidado, avisando con años de anticipación, y siempre se cuida de mantener
la IP antigua también por varios años más, para ir de a poco analizando si hay
resolvers retrasados.

La llave DNSSEC de la raíz es un poco más delicada. En la historia hemos tenido solo
dos. La primera fue la original del año 2004, y la única rotación hasta el momento fue
el año 2018, momento en que comenzó a operar la segunda llave y la primera se
retiró. El momento de esa rotación fue complejo, por ser la primera vez que se hizo,
y no se estaba seguro de cuántos resolvers no tendrían la nueva. Existe un
mecanismo automatizado, dentro del mismo DNS, que permite que las llaves se "auto-
roten". Sin embargo, lo que se vió en esa primera experiencia es que además de ese
mecanismo, son los propios desarrolladores de software los que se preocupan de
distribuir la nueva llave con actualizaciones de sus servicios, y avisar en sus propios
canales a sus usuarios. De todas formas, una rotación de la llave raíz es un evento lo
suficientemente importante como para estar atentos, y seguir las instrucciones que
defina su distribución de software.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 6

Es importante la configuración de quiénes tienen acceso a la recursión. Esto no debe
ser abierto a todo el mundo, solo a sus clientes, por temas de seguridad y evitar
ataques de envenenamiento de caché.

El formato es indicando el bloque IP y la acción. En el ejemplo vemos que se define

una regla ACL con las IPs internas de los clientes, y luego en la sección options se
permite solo recursión en esa ACL.

Esto me asegura que solo se dará servicio de recursión a los clientes de mi red. El
resto de clientes que hagan consultas recursivas recibirán una respuesta REFUSED.
Además por supuesto es posible hacer bloqueos a nivel de firewall para que ni
siquiera puedan acceder al puerto 53 de mi resolver desde redes externas.

Tamaño de buffer
Uno de los puntos que ha ganado bastante atención es el tamaño máximo del buffer
UDP que se debe utilizar, tanto desde el resolver hacia el "upstream", es decir los
autoritativos que contacta; como desde el resolver a su "downstream", es decir los
clientes que atiende. Para ambos casos es necesario declarar el tamaño de buffer
máximo, y así evitar la fragmentación de paquetes UDP.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 7

En el caso de un resolver hacia el upstream, en Bind existe la directiva edns-udp-size.
Este indica que al hacer una consulta a un autoritativo, se incluirá el tamaño máximo
de respuesta que se acepta. Acá hay una cifra recomendada, que viene por defecto
en Bind: 1232 bytes. Se ha estudiado que es una cifra que es bastante segura para
toda Internet, y es la recomendada en el “DNS Flag Day” del año 2020. No se
recomienda cambiarla, pero sí es posible definirla para servidores que tienen algún
problema y no soportan este tamaño. En ese caso es posible reducir el edns-udp-size
por IP de autoritativo.

Para el caso de downstream se utiliza la directiva max-udp-size, que define cuál es el

máximo paquete UDP de respuesta que daremos a nuestros clientes. En este caso
podemos también utilizar el valor por defecto de 1232, pero acá ustedes mismos
tienen la respuesta según la arquitectura de su propia red. Si sus clientes se
encuentran todos en redes internas que soportan paquetes más grandes sin
fragmentación, entonces es recomendable que lo aumenten a la cifra que más les
acomode. Aprovechar el máximo de paquete UDP les permite mejorar tiempos de
respuesta y evitar el paso a TCP. Bind tiene como máximo 4096 bytes para el buffer
UDP.

Validación DNSSEC
La validación DNSSEC es recomendada en todo resolver. En Bind es tan simple como
activar la directiva dnssec-validation con el valor "auto". De esta manera se utiliza la
llave de la raíz configurada por defecto dentro de Bind, incluida su cambio cuando hay
rotación de la llave raíz. Es el valor más seguro para DNSSEC.

Al activar validación DNSSEC, nuestro resolver verificará que las firmas RRSIG que
vienen con las zonas firmadas sean criptográficamente válidas. Incluirá la descarga
de las llaves de la zona, utilizando la delegación de registros DS desde el padre al
hijo. Si alguna de estas firmas es inválida, el resolver enviará una respuesta
SERVFAIL al cliente, lo que lo protege de recibir una respuesta inválida.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 8

Podemos revisar que la validación está funcionando si vemos el bit "ad" de "Authentic
Data" en el header de la respuesta, al consultar un nombre de dominio firmado.

Como vemos en el ejemplo, ese bit "ad" que incluye el resolver en su mensaje indica
que la respuesta ha sido validada correctamente usando DNSSEC.

Para probar la protección que DNSSEC nos entrega frente a un dominio incorrecto,
podemos revisar un nombre de dominio que intencionalmente está mal firmado, como
www.dnssec-failed.org.

En este caso, el status es SERVFAIL y no existe respuesta (ANSWER es igual a 0).

El resolver nos está protegiendo gracias a DNSSEC.

Si estamos haciendo debugging y queremos estar seguros que este SERVFAIL es

debido a DNSSEC, podemos incluir el bit "Checking Disabled" en nuestra consulta,

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 9

con lo cual le pedimos al resolver que por favor nos de la respuesta incluso si es
incorrecta, como vemos acá.

Si además le indicamos con “+dnssec“ que queremos los registros RRSIG, podemos
revisar en dónde está el problema.

Excepciones por dominios mal firmados

Uno de los principales problemas de DNSSEC en sus comienzos, y que de paso es
un problema de cualquier tecnología de seguridad nueva, es qué hacer cuando un
resolver activa DNSSEC y se encuentra con una zona mal firmada.

Lo que dice el protocolo es que esa zona no debe ser resuelta, pero ¿qué pasa si es
un dominio muy famoso? ¿Un dominio que sí funciona en un resolver que no valida?
Existía el miedo que por ser "demasiado seguros", dejáramos fuera un servicio
importante para nuestros clientes.

Este miedo fue resuelto hace muchos años atrás cuando se activó la validación
DNSSEC en forma simultánea en muchos operadores, para que de esa forma no
existiera esta supuesta "desventaja" al tener activo este modo de seguridad. Es así
como hoy todos los resolvers públicos quad-8, quad-1, quad-9, etcétera, todos validan
con DNSSEC. Si un dominio, por importante que sea, expira sus firmas, entonces
efectivamente quedará fuera de Internet. Ya no se puede culpar al resolver, porque el
que cometió la falta es el operador de la zona.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 10

Sin embargo, poniéndonos en el papel de operadores, siempre existen las
excepciones y podría ser necesario "desactivar" la validación DNSSEC para un
dominio en particular, en el caso que este dominio esté mal firmado, pero por la
importancia a nuestros clientes, podríamos querer dar respuesta igual.

Para eso existe la directiva validate-except en Bind, que acepta nombres de dominio
donde bajo ellos se desactivará la validación, sin importar si sus firmas son
incorrectas. De todas formas, por supuesto que esta técnica debe usarse con mucho
cuidado y siempre como excepción en casos bien analizados, y reevaluados
constantemente. Desactivar DNSSEC es muy peligroso porque sería imposible para
un cliente diferenciar una excepción de un ataque.

Capítulo 4: Técnicas avanzadas.

Quería mencionar otras dos técnicas avanzadas que utilizan los resolvers para
mejorar privacidad y robustez.

La primera de ellas se llama "qname minimisation". Esta técnica se utiliza para evitar
divulgar demasiada información a los DNS autoritativos sobre la consulta que nuestro
cliente realiza.

En el DNS tradicional, si un cliente buscaba el nombre "www.example.com", el

resolver comenzaba a iterar por el árbol DNS enviando la consulta completa a la raíz.
Luego la raíz nos derivaba al autoritativo de .com, a quien también le enviábamos la
consulta completa "www.example.com". Esta práctica se consideró que era
demasiado divulgadora de información privada, por lo que se inventó "qname
minimisation", que evita enviar la consulta completa mientras se recorre el árbol DNS.

De esta manera, un resolver que usa qnamemin, le enviará a la raíz solo la consulta
por ".com", y a los servidores de .com solo la consulta por "example.com",
minimizando de esta forma la información divulgada.

Esta técnica tiene sus problemas, porque hay veces donde un autoritativo sí tiene
información a varios niveles por debajo, lo que ocasiona muchas consultas repetidas
que podrían resolverse de una vez. Por eso la técnica qnamemin no está libre de

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 11

dificultades. De todas formas se considera que es una buena práctica activarla
siempre, pero estar atentos a posibles fallas.

Actualmente Bind usa por defecto un valor "relajado" de qnamemin que le permite
esquivar ciertos problemas. También se puede activar en modo estricto, mediante una
configuración manual.

La segunda técnica a mencionar es "NSEC agresivo". Acá lo que buscamos es evitar

tener que perseguir respuestas que podemos derivar de otra información que ya
tenemos. Se origina en ciertos ataques de DoS que consultaban en forma ilimitada a
un resolver por nombres inexistentes, una y otra vez. Hay ataques donde clientes
consultan por el nombre "aaa.example.com", "aab.example.com",
"aac.example.com", así hasta el infinito. Lamentablemente el protocolo DNS original
nos obligaba a seguir cada una de esas consultas yendo al autoritativo del dominio,
una y otra vez. Sin embargo, con DNSSEC activo, ahora tenemos la certeza, mediante
el registro "NSEC", que entre un nombre y otro, no hay nada.

Así por ejemplo, la primera vez que consultemos por "aaa.example.com", el

autoritativo nos dirá "aaa.example.com no existe, y la demostración es porque acá te
envío un NSEC que dice que entre el naked domain example.com y
www.example.com ¡no hay nada!". Un resolver puede almacenar en su caché este
NSEC, y la próxima vez que un cliente le pregunte por aab.example.com, le puede
responder de inmediato que no existe, sin necesidad de gastar recursos acudiendo al
autoritativo.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 12

Esta práctica por supuesto requiere que el resolver esté validando con DNSSEC, y
viene activo por defecto en Bind.

Capítulo 5: Filtros y bloqueos.

Una técnica que se puede aplicar a un DNS recursivo es el llamado "Response Policy
Zones" (RPZ), que es llamado también "bloqueos" de nombres, o "filtros" de nombres,
o comercialmente como "Firewall DNS".

Lo que permite esta técnica es modificar ciertas respuestas DNS a criterio del
operador del recursivo.

No entraremos acá a discutir si el filtrado y modificación de respuestas es censura

indebida, o es una violación al protocolo. Lo que asumimos acá es que un operador
puede tener perfecto derecho e incluso obligación legal de hacerlo, y existen
bastantes casos legítimos donde uno esperaría que así lo hiciera.

Un ejemplo típico de filtrado es evitar que nuestros clientes caigan víctimas de

malwares. Hay listas que publican dominios maliciosos, y una técnica posible es
agregar estos dominios en nuestros resolvers para que cualquier resolución de
nuestros clientes no llegue al destino real, sino por ejemplo obtenga un SERVFAIL, o
mejor incluso una página interna con información del bloqueo.
Otro uso posible es para control parental, evitando la resolución de dominios con sitios
de adultos, o apuestas.

Por último, hay ocasiones en que un juez o tribunal nos podría exigir dejar de resolver
un nombre, y para ello también se puede aplicar esta técnica.

La forma de operar las RPZ es creando zonas, al mismo estilo de las zonas normales
autoritativas, pero con nombres y acciones que tienen prioridad sobre la resolución
normal.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 13

Se declara su uso con la directiva response-policy donde se declaran distintas zonas.

Y cada zona RPZ puede tener los nombres que queramos bloquear, apuntando a la
IP que queramos en un registro A, o bien apuntando con un CNAME a la raíz en caso
de bloqueo con respuesta NXDOMAIN

Existen también servicios que entregan zonas listas con dominios para bloquear
mediante RPZ, como SpamHaus, ThreatStop, Infoblox, etcétera. Estos permiten que
uno declare una zona secundaria, que descarga los datos desde ellos como primarios,
y vienen con dominios ya preparados para bloquear. En dnsrpz.info pueden buscar
más información.

Capítulo 6: Monitoreo y flushing.

Como hemos visto antes, las variables más importantes a considerar al mantener un
DNS recursivo en operación es su uso de memoria RAM, y la tasa de ocupación del
caché.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 14

El uso de memoria puede irse monitoreando con herramientas estándar del sistema
operativo. Para el caché, Bind utiliza por defecto hasta el 90% de la memoria física
disponible.

Mirando las estadísticas de Bind con el comando "rndc stats" es posible inferir la
utilización de caché comparando la cantidad de queries marcadas como "recursion",
que requirieron hacer la recursión completa, versus las queries respondidas en total.

Por último, también es muy importante monitorear el tiempo de respuesta desde el

cliente de las consultas. Acá lo ideal es tener algunas sondas en lugares cercanos a
los clientes reales, que realicen consultas por nombres conocidos, y tener estimado
el tiempo de respuesta. Cualquier variación importante es una señal a tener en
consideración para entregar una experiencia de usuario correcta al cliente final.

Una técnica de operación que puede ayudarnos en algunas ocasiones especiales, es

el de borrar algún nombre del caché, lo que se llama hacer "flush" de un nombre.

Ha ocurrido ocasiones donde debido a un error de un operador de una zona, es

necesario realizar un "flush" inmediato, para evitar que el resolver siga respondiendo
con una respuesta en su caché que está incorrecta. Los operadores de zona
normalmente tienen canales donde solicitan a los grandes operadores de resolver que
hagan flush de sus zonas después de una falla.

En Bind el comando es "rndc flushname example.com", lo que ocasiona que el

resolver invalide inmediatamente todo lo que tenga en su caché bajo el nombre
"example.com", y vuelva a hacer la recursión completa cuando lo necesite.

Curso Bases del DNS, instalación y configuración moderna / Módulo 3 15