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@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp