Hola. Después del último ataque DoS a Dyn que dejó fuera varios dominios famosos, se puso de moda tener "proveedores redundantes" de DNS. O sea ya no basta lo bueno que sea cualquier proveedor, siempre puede quedar fuera con un DoS gigante. Así que la solución es tener al menos dos.
El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53:
Por supuesto que nada de esto sería problema si se estandarizara la forma de alimentar los secundarios, que... sorpresa! Existe desde hace 20 años (AXFR/IXFR) ;)
Saludos,
Hugo
On 13:36 18/01, Hugo Salgado-Hernández wrote:
El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53:
Y ServerFault, que terminaron usando Route 53 y Google Cloud luego de mediciones y análisis de performance: http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
Prometen liberar su herramienta de sincronización para marzo.
Hugo
2017-01-18 13:44 GMT-03:00 Hugo Salgado-Hernández hsalgado@nic.cl:
On 13:36 18/01, Hugo Salgado-Hernández wrote:
El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53:
23/multiple-dns-synchronising-dyn-to-aws-route-53>
Y ServerFault, que terminaron usando Route 53 y Google Cloud luego de mediciones y análisis de performance: http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
Prometen liberar su herramienta de sincronización para marzo.
Muchísimas gracias, Hugo.
*MUY* buena la nota de ServerFault.
-- Mariano Absatz - El Baby www.clueless.com.ar
On 13:44 18/01, Hugo Salgado-Hernández wrote:
On 13:36 18/01, Hugo Salgado-Hernández wrote:
El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53:
Y ServerFault, que terminaron usando Route 53 y Google Cloud luego de mediciones y análisis de performance: http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
Prometen liberar su herramienta de sincronización para marzo.
Y lo hicieron: https://stackexchange.github.io/dnscontrol/
Por el momento soporta a Bind, Google Cloud DNS, Route 53 y Name.com.
Lo interesante es Name.com es un registrar, entonces de una llamada registran el nombre (usando una API para dominios) y lo provisionan en el DNS provider!
Saludos,
Hugo
Y ahora Github sacó "OctoDNS", que hace lo mismo que el DNSControl de StackExchange: https://githubengineering.com/enabling-split-authority-dns-with-octodns/
Saludos,
Hugo
On 15:29 16/03, Hugo Salgado-Hernández wrote:
On 13:44 18/01, Hugo Salgado-Hernández wrote:
On 13:36 18/01, Hugo Salgado-Hernández wrote:
El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53:
Y ServerFault, que terminaron usando Route 53 y Google Cloud luego de mediciones y análisis de performance: http://blog.serverfault.com/2017/01/09/surviving-the-next-dns-attack/
Prometen liberar su herramienta de sincronización para marzo.
Y lo hicieron: https://stackexchange.github.io/dnscontrol/
Por el momento soporta a Bind, Google Cloud DNS, Route 53 y Name.com.
Lo interesante es Name.com es un registrar, entonces de una llamada registran el nombre (usando una API para dominios) y lo provisionan en el DNS provider!
Saludos,
Hugo
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp