Un primario oculto y dnsdist: bastionar el DNS autoritativo

El DNS autoritativo es un amplificador para los atacantes y un objetivo frecuente de inundaciones. Dos decisiones de diseño hacen la mayor parte del trabajo de hacerlo resiliente: mantener oculto el primario, y poner un balanceador que entienda DNS delante de cada servidor público. Así se hace, con las reglas que consideramos el mínimo.

Oculte el primario

El servidor donde se editan las zonas, viven las claves y reside la copia maestra de los datos no debería responder nunca a internet. En su lugar, replica a secundarios públicos por una red solo interna, y solo los secundarios aparecen en los registros NS.

Eso le da tres cosas. El servidor más valioso no está expuesto a inundaciones ni exploits. Los servidores públicos pasan a ser desechables: si uno es atacado o falla, sus pares siguen adelante y se puede reconstruir desde el primario. Y puede repartir los secundarios entre redes, sedes y plataformas distintas, de modo que ningún dominio de fallo único tire el dominio.

Tanto si la replicación es el clásico AXFR con NOTIFY como si es replicación de base de datos por debajo de PowerDNS, la propiedad que hay que proteger es la misma: la dirección del primario nunca debe aparecer en un registro NS o SOA público. Compruébelo:

dig +short NS example.com
dig +short SOA example.com      # the MNAME field should not be your hidden primary

Por qué un balanceador genérico no basta

Un balanceador TCP o UDP puede repartir consultas, pero no puede leerlas. Casi toda defensa útil de DNS depende de entender la consulta: su tipo, la zona por la que pregunta, si es un UPDATE, cuántos fallos está generando un origen. dnsdist, del proyecto PowerDNS, se sitúa delante del nameserver, ocupa el puerto público y toma esas decisiones antes de que la consulta llegue al backend. El propio servidor autoritativo escucha entonces solo en localhost.

Las reglas de dnsdist que consideramos el mínimo

-- backend listens on localhost only
newServer({address="127.0.0.1:5300", name="auth"})
setLocal("0.0.0.0:53")
addLocal("[::]:53")

trusted = newNMG(); trusted:addMask("10.0.0.0/8")   -- your internal replication network
ourZones = newSuffixMatchNode(); ourZones:add("example.com.")

-- ANY queries are an amplification tool; refuse them
addAction(QTypeRule(DNSQType.ANY), RCodeAction(DNSRCode.REFUSED))

-- no dynamic updates or notifies from the internet
addAction(AndRule({OpcodeRule(DNSOpcode.Update), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))
addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))

-- only answer for zones we actually serve
addAction(NotRule(SuffixMatchNodeRule(ourZones)), RCodeAction(DNSRCode.REFUSED))

-- cap queries per source address
addAction(MaxQPSIPRule(50), DropAction())

-- automatic temporary blocks for sources generating floods of failures
local dbr = dynBlockRulesGroup()
dbr:setRCodeRate(DNSRCode.NXDOMAIN, 50, 10, "NXDOMAIN flood", 60)
dbr:setRCodeRate(DNSRCode.REFUSED, 50, 10, "REFUSED flood", 60)
function maintenance() dbr:apply() end

Qué le compra cada regla:

• Rechazar ANY elimina la consulta de amplificación clásica.
• Rechazar UPDATE y NOTIFY desde fuera cierra las vías por las que el contenido de las zonas o la replicación podrían ser influidos desde internet.
• Rechazar las zonas que no sirve antes de que el backend las vea mantiene la basura aleatoria y las sondas de reflexión completamente fuera del nameserver.
• Fije los topes de tasa por origen a partir de su tráfico real, con generosidad suficiente para los resolvers grandes.
• Los bloqueos dinámicos por tasa de fallos cazan los ataques de subdominios aleatorios, que generan inundaciones de respuestas NXDOMAIN desde muchos orígenes, sin bloquear a un resolver por un mal minuto.

Añada limitación de tasa de respuestas en el backend o en dnsdist para que ni siquiera las respuestas de aspecto legítimo puedan convertirse en una inundación hacia una dirección falsificada.

DNSSEC sin baile de claves

Si sus secundarios firman las zonas por sí mismos, cada uno necesita las claves, y distribuir claves es donde los despliegues de DNSSEC se tuercen. Cuando las claves viven en la misma base de datos que se replica a los secundarios, cada servidor firma de forma idéntica por construcción. Cuando mueva un dominio firmado entre proveedores, hágalo por etapas y en orden: retire el registro DS antiguo en el registro, espere a que expiren las cachés, firme en los servidores nuevos y después publique el nuevo DS. La validación nunca se rompe.

El DNS inverso es parte del trabajo

Trate el DNS inverso como una regla: cada dirección asignada a una interfaz, servicio o host recibe un PTR en el mismo cambio, y cada zona inversa se delega a todos sus nameservers. Compruebe ambas direcciones y la delegación del padre:

dig +short -x 192.0.2.25
dig +short host.example.com A
dig +short NS 2.0.192.in-addr.arpa

Los nombres directo e inverso deben coincidir, y el conjunto NS de la zona inversa debe corresponderse con lo que el registro regional tiene archivado.

Vigile las respuestas, no solo los servidores

Un nameserver que está arriba pero sirve una zona obsoleta es peor que uno caído, porque nada alarma. Monitorice lo que importa: compare el serial SOA de cada zona entre todos los servidores, compare el número de registros, vigile el retraso de replicación y alerte si el primario oculto aparece alguna vez en datos públicos. Comprobar desde unos cuantos puntos externos que cada servidor público responde con autoridad cierra el círculo.

Su lista de comprobación

• ¿Está su primario oculto, y ausente de NS y SOA?
• ¿Están los servidores públicos detrás de un frontal que entiende DNS y rechaza ANY, UPDATE y NOTIFY externos, y zonas desconocidas?
• ¿Hay límites por origen y bloqueos dinámicos para las inundaciones de fallos?
• ¿Firman todos los servidores de forma idéntica, y está escrito su procedimiento de rollover del DS?
• ¿Tiene cada dirección asignada un PTR que coincida?
• ¿Alerta ante una discrepancia de serial entre servidores?

Operamos nuestro DNS autoritativo en PowerDNS exactamente así, y construimos clústeres dedicados para los clientes que quieren el suyo. Si quiere una revisión de su DNS, estaremos encantados de ayudar.

Hable con un ingeniero

Related

Relacionado: DNS autoritativo y DNS inverso, operados como infraestructura · DNS autoritativo y recursivo en PowerDNS · IPv6, nativo y dual-stack