[LACNIC/Seguridad] [lacnog] Thomas Ptacek: Against DNSSEC

Carlos M. Martinez carlosm3011 en gmail.com
Mar Ene 26 19:10:47 BRST 2016


En realidad, sobre el costo impuesto podemos charlar. Nosotros operamos
zonas firmadas desde hace 4 años y, la verdad, no sufrimos nada.

La clave es automatizar lo más posible y ser prolijos con la gestión de
los rollovers.

Disclaimer: las zonas nuestras son 'fáciles', ya que o bien son chicas,
o son zonas reversas de algunos varios miles de registros pero que
cambian relativamente poco entre publicación y publicación.

Acá en esta lista hay gente de varios ccTLDs de la región que han
firmado sus zonas y que no no se ve que hayan sufrido de gran manera
(han seguro trabajado mucho para firmar, pero despues de logrado, es
algo mantenible)

Creo que los temores sobre costo o peso de DNSSEC se basan en las
primeras experiencias donde no habían herramientas que permitieran
automatizar y había en general mucha menos experiencia.

s2

-Carlos

On 1/26/16 5:58 PM, Iván Arce wrote:
> no me genera temor,  me genera rechazo. No veo qué valor agrega a DNS o,
> para ser más preciso, creo que el valor que agrega es ínfimo comparado
> con el costo que impone. Por eso, entre otras cosas, es que coincido con
> el diagnóstico de Ptacek. Como explique antes, me parece una cuestión de
> necesidad política y de negocios no una solución tecnológica adecuada
> para un problema concreto.
> 
> ..por lo menos así lo veo yo...
> 
> 
> saludos,
> 
> -ivan
> 
> 
> 2016-01-26 13:52 GMT-03:00 Christian O'Flaherty
> <christian.oflaherty en gmail.com <mailto:christian.oflaherty en gmail.com>>:
> 
>     >
>     > Sinceramente, yo ya hace años que perdí todo interés en debatir sobre las
>     > cualidades técnicas de DNSSEC, considero su despliegue como algo ya
>     > imparable, una desgracia inevitable, con la misma certeza del envejecimiento
>     > y la muerte de todo lo viviente.
> 
>     no debería generar temor si pensamos a DNSSEC como un adicional que
>     agrega valor al DNS. Solo será necesario cambiar algo para los que
>     necesitan esa funcionalidad. Puede ser una minoría la que necesite
>     DNSSEC, pero puede ser muy útil para esos.
> 
>     El lado bueno de DNSSEC, es que esa funcionalidad adicional (confiar
>     en la respuesta) te puede habilitar nuevos servicios. DANE es un buen
>     ejemplo (y que el dueño de un dominio pueda publicar un certificado).
>     Lamentablemente esto fue en contra de las CA y lograron frenarlo para
>     HTTPS (los browser no lo incorporaron). Habrá otros usos para DANE...
> 
>     Los algoritmos usados ahora pueden ser débiles pero DNSSEC en eso es
>     abierto...
>     Coincido con las posibilidades de DoS adicionales. Seguramente tendrán
>     solución a medida que aparezcan los problemas. También habrá que estar
>     atentos a las posibilidades de amplificación de tráfico.
> 
>     Con respecto a la "centralización" de la raíz, y mirando el tema con
>     optimismo... DNSSEC podría ayudar. Por que necesitamos servidores
>     raíz? Qué tal si distribuimos la zona usando rsync, ftp, scp, http,
>     etc. y cuando instalamos un BIND o similar nos ocupamos de configurar
>     esa actualización del archivo raiz (no tiene que ser muy seguido).
>     Teniendo la zona (bien) firmada por IANA uno podría confiar en el
>     archivo aunque venga por bittorrent :-)
> 
>     Christian
> 
>     > Me involucré en este thread porque me pareció que podia aportar una visión
>     > un poco distinta que enriquezca la discusión... y porqué sé que Fernando,
>     > que es un pillo,  mandó ese post original para provocarme :P
>     >
>     >
>     > saludos,
>     >
>     > -ivan
>     >
>     >
>     > 2016-01-25 17:43 GMT-03:00 Carlos M. Martinez <carlosm3011 en gmail.com <mailto:carlosm3011 en gmail.com>>:
>     >>
>     >>
>     >> Tomando un poquito de distancia, también hay un facilismo importante en
>     >> quejarse a posteriori de las cosas. Es re-fácil criticar con el diario
>     >> del lunes. Seguro que hay cosas para mejorar en DNSSEC (y en el 100% de
>     >> los protocolos y estándares técnicos), pero todos estos estándares y
>     >> protocolos son construcciones iterativas e incrementales.
>     >>
>     >> El "perfecto enemigo de lo bueno" es uno de las principales cosas que
>     >> hay que evitar, porque conduce inevitablemente a la parálisis.
>     >>
>     >> s2
>     >>
>     >> C.
>     >>
>     >>
>     >
>     > _______________________________________________
>     > Seguridad mailing list
>     > Seguridad en lacnic.net <mailto:Seguridad en lacnic.net>
>     > https://mail.lacnic.net/mailman/listinfo/seguridad
>     >
>     _______________________________________________
>     Seguridad mailing list
>     Seguridad en lacnic.net <mailto:Seguridad en lacnic.net>
>     https://mail.lacnic.net/mailman/listinfo/seguridad
> 
> 
> 
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
> 



Más información sobre la lista de distribución Seguridad