Un how-to atrevido, porque todo lo que signifique adulterar el sistema clásico de servicios DNS supone atrevimiento.
Sobre BIND
El estándar de facto a la hora de montar un servidor DNS es BIND (Berkeley Internet Name Domain). Con orígenes que se rempotan a los albores de los 80, con los primeros trabajos realizados por los investigadores del DARPA (Defense Advanced Research Projects Agency), BIND fue creado en 1988, momento en el que Paul Vixie, trabajador de DEC (Digital Equipment Corporation), se hizo cargo del mantenimiento original del proyecto esbozado por DARPA.
Recientemente, el histórico de problemas de seguridad de BIND obligó a su reescritura completa. Apareció BIND 9, con mejoras importantes añadidas, como DNSSEC (DNS Security Extensions), TSIG, notificación DNS, nsupdate, IPv6, rndc flush, sopore multiprocesador y mejoras en la arquitectura, ahora más portable que nunca. El equipo de desarrollo de ISC, institución que mantiene el proyecto, cubre dos ramas en la actualidad: la 9.x y la 8.x, siendo las versiones más actuales en este momento la 9.3.2 y la 8.4.7
Alternativas a BIND
Todo lo que sea proporcionar alternativas a BIND es atrevido, muy atrevido. En el código libre hay, como decía, muchos estándares de facto sobre los cuales nadie se atreve tan siquiera a rechistar. Podríamos hablar de «vacas sagradas» como Apache, squid-cache o en este caso, de BIND cuyo uso mayoritario es aplastante, con cuotas de uso elevadas propiciadas por la excelente calidad de los productos.
Me ha llamado poderosamente la atención el how-to Running A MySQL-Based DNS Server: MyDNS, en el cual se plantea un formato alternativo para ofrecer servicios DNS. Según los autores, MyDNS es un servidor DNS que se abastece de un soporte SQL donde van consignados los datos del servicio, en vez de ir en ficheros de texto plano como sucede en BIND. La ventaja que promulgan sus autores es obvia, la posibilidad de invocación de la SQL mediante interfaz web, lo que simplificaría la administración del servidor DNS. La replicación de servicios se hace mediante replicación SQL.
¿Merece la pena?
Me recuerda al proyecto PowerDNS, con una arquitectura idéntica pero con un backend en PostgreSQL. Creo que tiene el mismo talón de aquiles. Introducir un elemento adicional al servicio, en este caso la base de datos relacional, es meter una nueva variable en la ecuación de la (in)seguridad. MyDNS implica mantener no sólo la solución propia, sino el servidor SQL. Idem para PowerDNS.
Para mí, las ventajas que puede aportar el backending SQL no compensan a los riesgos introducidos por la dependencia de más productos. Pienso igual para los costes de mantenimiento y de despliegue.
Por cierto, yo en vez de BIND suelo optar por djbdns, y es que cuando se tienen herramientas libres de calidad disponibles, elegir cómo hacer las cosas es sencillo, salvo que nos queramos complicar la vida claro :)
Dos vulnerabilidades moderadas en BIND
Al hilo de BIND, comentar que han aparecido ayer mismo (21 de enero) dos vulnerabilidades en BIND. Afectan a BIND 9.3.0, BIND 8.4.4 y 8.4.5. Ambos problemas pueden conducir a que usuarios malintencionados ejecuten ataques de denegación de servicio. La criticidad de ambos problemas es moderada.
Disculpad, me llegó información no actualizada. Este problema descrito es del año pasado. No hay decretadas vulnerabilidades de BIND actualmente.