[dns-esp] Mejor Practica para DNS en la nube

[Hugo Salgado-Hernández]

Hola Miguel.
En realidad técnicamente no hay problema con tener el maestro en la nube.
Son cosas operativas, como mencionas. En general uno trata de mantener
el control de los autoritativos porque permite hacer actualizaciones
en el momento que uno desee, y envía notifys a los secundarios, sin tener
que esperar que pasen los tiempos de refresh normales. Además que en
caso de ataque DoS al proveedor, uno puede rápidamente mover los secundarios
públicos a otro servicio, manteniendo el control de la zona.

Por último, las últimas recomendaciones dicen que es mejor no tener un
solo proveedor, por bueno que sea. Y para tener más de uno, el primario
se debe mantener "on-promise", coordinando ambos servicios externos:

<https://www.theguardian.com/info/developer-blog/2016/dec/23/multiple-dns-synchronising-dyn-to-aws-route-53>
<http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/>
<https://stackexchange.github.io/dnscontrol/>

Saludos,

Hugo

On 11:14 10/07, Miguel Angel Amador wrote:
>  Estimados
> Alguien tendra una guia de las mejoras practicas por el lado de
> seguridad... para colocar DNS 's en la nube? ... por aca un cliente interno
> se esta llevando el dns a cloudflare, dejando el master en la nube, aparte
> de perder la sincronizacion con el dns interno (entrar a configurar en
> ambientes separados un registro), siento que deberían tener el master
> (visible solo a los slave, pero onpremise)  y los slave en la nube, para su
> replicacion.
>  Pero necesito algún estudio que avale lo que pienso.
>  Se agradece cualquier documento que aporte alguna directriz al respecto.
> Saludos
>  Miguel Amador L.

> _______________________________________________
> dns-esp mailing list
> dns-esp en listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: no disponible
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20170711/1b0e67d8/attachment.sig>