djbdns vs bind [cerrado]

Soy un novato que quiere aprender a configurar un servidor de nombres DNS. ¿Debo usar djbdns, BIND u otra cosa?

Los requisitos de red actuales incluyen soporte de subdominio, SSL y servicio de correo, todo en tráfico muy ligero. Me gustaría una solución que algún día podría escalar a un tráfico más pesado y posiblemente requisitos más difíciles (como el equilibrio de carga). En este momento, ya había corrido en Linux.

He leído que BIND tiene problemas de seguridad si no está configurado correctamente, y que su configuración puede ser complicada. También he leído que djbdns es más fácil de configurar, más seguro e igual a cargas pesadas. Los argumentos para djbdns parecen plausibles, pero no tengo la experiencia para evaluarlos adecuadamente. Si BIND es mejor, agradecería una discusión de esas afirmaciones para djbdns.

Gracias.

He trabajado con djbdns en el pasado y actualmente ejecuto un montón de servidores BIND.

El mayor problema con djbdns es mejor ponerlo en la forma en que mi maestro de primer grado lo puso en mi boleta de calificaciones: "no juega bien con los demás". Simplemente no se comporta como cualquier otra cosa en una caja de Unix en todo tipo de formas muy pequeñas que pueden morderte más tarde. Utiliza una sintaxis para los archivos de zona que no verá en ningún otro lugar.

La mayor ventaja de djbdns es que fue diseñado desde cero con la seguridad como objetivo # 1.

Si iba a configurar un servidor DNS, exponerlo a Internet y luego nunca mantenerlo, djbdns sería el camino a seguir.

En el mundo real, es mejor que la mayoría de los administradores utilicen los paquetes BIND del proveedor del sistema operativo y los apliquen rápidamente cuando hay una actualización. Pero ejecutarlo con chroot es una buena idea, y mantener sus servidores DNS autorizados por separado de sus servidores DNS de resolución recursiva es una buena idea.

Si encuentra documentos para algo con DNS, se incluirá BIND y es poco probable que se incluya djbdns. Si usa dig, el formato que devuelve puede pegarse en un archivo de zona BIND y funcionar. Actúa como cualquier demonio Unix normal en lugar de algo de otro planeta.

Utilizamos algunos equilibradores de carga de hardware y equilibramos la carga de nuestros servidores BIND de resolución recursiva; Funciona genial. Solo asegúrese de que los usuarios obtengan la misma IP de origen a la que enviaron sus solicitudes y que cualquier configuración de equilibrio de carga compatible con UDP y TCP debería funcionar. Si está utilizando un DNS autorizado, el equilibrio de carga es tan simple como tener más de un servidor y publicarlos todos en la información whois; los otros servidores DNS cargarán el equilibrio de forma inteligente

Para un servicio autorizado, nsd .

Para uno recursivo, sin consolidar .

Ambos son pequeños (por lo que probablemente tengan menos agujeros de seguridad esperando ser descubiertos), mantenidos activamente y soportan todas las cosas recientes de DNS (DNSSEC, IPv6, etc.).

De lo contrario, BIND es un buen software.

djbdns es un proyecto de un solo hombre, sin mantenimiento durante mucho tiempo, no más seguro (el autor simplemente lo dice), y el sitio web oficial está lleno de errores. (Ahora, estoy seguro de que obtendré muchos votos negativos de djbboys, mi representante fue demasiado alto para mi gusto :-)

Si es por ti mismo, y si quieres aprender cómo funciona DNS, usaría djbdns.

Si desea comprender cómo todos los demás usan DNS y cómo respaldar implementaciones empresariales típicas, aprenda el enlace.

Si su objetivo es un mínimo esfuerzo y soporte, y usted es razonablemente competente, djbdns tiene una sobrecarga de soporte mucho menor.

Si está más en el lado novato de la valla, probablemente le resulte más fácil ponerse en marcha, pero tenga en cuenta que es mucho más probable que explote de formas extrañas y extravagantes.

Si aún no conociera djbdns (y bind), también buscaría en powerdns y maradns, pero dudo que para instalaciones pequeñas sea mejor que la suite djbdns.

De todos modos, incluso si usa bind para anunciar su DNS a Internet, debe ejecutar dnscache (parte de la suite djbdns) que se ejecuta en localhost para el solucionador de su sistema.

Omitir djbdns. Aunque djb es un héroe, lleva la arrogancia de un matemático al software. El hecho de que no se comporte como otro software con respecto al inicio / detención podría ser una buena demostración de una técnica inteligente de gestión de demonios. Pero tendrá que extraer la documentación si no la usa con regularidad, porque todo es muy diferente. Si lo configura en sistemas que otros también mantienen, deberá escribirles documentación clara, que deberán leer en su totalidad para realizar operaciones simples. Ejecutar cosas fuera de init es lindo, incluso inteligente. Pero también es desagradable, sorprendente y no estándar.

Además, he tenido problemas con djbdns que causan serios problemas debido a la insistencia en respetar solo los estándares y no en la interoperabilidad del software. Resolver estos problemas fue una gran pérdida de tiempo, ya que dependía de pequeñas diferencias en los paquetes DNS.

Además, djbdns tiene un comportamiento extraño en ciertos casos que hará que las personas solucionen problemas de su servidor DNS con herramientas distintas a las de djb (por ejemplo, con nslookup) para obtener resultados sorprendentes. Perderás tu tiempo explicando "en realidad, solo uso este oscuro servidor DNS llamado djbdns. El problema es que tus herramientas de diagnóstico te están dando un mensaje extraño, pero está funcionando bien. Si miras esta captura de paquetes, puedes ver . Esto no está relacionado con el problema que tuvimos hace unos meses donde djbdns no interactuaba correctamente con su servidor DNS. Tampoco está relacionado con el problema que tuvimos hace unas semanas cuando estaba fuera de la oficina y me llevó compañeros de equipo una hora para reiniciar el servidor DNS ".

Problemas similares con qmail por todas partes.

Hay un valor educativo en la configuración de djbdns, si está haciendo la pregunta y tiene tiempo para matar. También puede aprender mucho simplemente leyendo el sitio web de djb.

Hay dos conjuntos de problemas de seguridad. Agujeros de seguridad que permiten que un atacante acceda al sistema: djbdns casi definitivamente no tiene ninguno de estos. Hace algunos años, Bind descubrió bastantes cosas embarazosas en poco tiempo, lo que también revelaba un mal diseño. Esperaría que a lo largo de estos años, se haya reescrito por completo. Si realmente desea estar seguro a este respecto, ejecútelo en una máquina virtual (por ejemplo, Xen). También considere, si está ejecutando en un sistema Linux con SELinux en modo dirigido, tendrá una configuración para vincular y probablemente no se molestará con una para djbdns. El sistema bind + SELinux es potencialmente más seguro.

El otro problema es la seguridad contra el envenenamiento de caché. Supongo que djbdns era mejor cuando se lanzó, y bind probablemente sea mejor ahora debido a una mayor atención. Esta es probablemente la causa de su audiencia de que el enlace es inseguro a menos que esté "configurado correctamente". Al menos debe investigar y comprender este problema. En el proceso, probablemente descubrirá qué riesgos de configuración existen para ambos servidores DNS.

El comportamiento bajo una carga pesada es un criterio sin sentido para la mayoría de los usuarios. Tenga cuidado con el rendimiento utilizado como criterio para evaluar el software que rara vez es un cuello de botella en el rendimiento. No está alojando un servidor DNS de almacenamiento en caché para una gran base de usuarios, donde puede recibir solicitudes a un ritmo significativo. Está ejecutando DNS autorizado para proporcionar servicios que probablemente se ejecutan en el mismo sistema. Estos servicios son miles de veces más caros que los DNS. Es posible que su enlace de Internet ni siquiera sea suficiente para cargar en gran medida su servidor DNS, pero si estuviera recibiendo una carga tan pesada en los servicios que proporciona, DNS no sería un cuello de botella probable.

Es posible que desee echar un vistazo a MaraDNS , un servidor DNS con seguridad.

• Seguro. MaraDNS tiene un historial de seguridad tan bueno o mejor que cualquier otro servidor DNS. Por ejemplo, MaraDNS siempre se ha aleatorizado, utilizando un generador de números aleatorios seguro, el ID de la consulta y el puerto de origen de las consultas DNS; y nunca fue vulnerable al "nuevo" ataque de envenenamiento de caché.

• Soportado. MaraDNS tiene una larga historia de mantenimiento y actualización. MaraDNS se creó originalmente en 2001. MaraDNS 1.0 se lanzó en 2002 y MaraDNS 1.2 se lanzó en diciembre de 2005. MaraDNS se ha probado exhaustivamente, tanto con un proceso SQA como con más de cuatro años de uso en el mundo real. MaraDNS sigue siendo totalmente compatible: el lanzamiento más reciente se realizó el 13 de febrero de 2009. Deadwood, el código que pasará a formar parte de MaraDNS 2.0, se está desarrollando activamente.

• Fácil de usar. Una configuración recursiva básica solo necesita un único archivo de configuración de tres líneas. Una configuración autorizada básica solo necesita un archivo de configuración de cuatro líneas y un archivo de zona de una línea. MaraDNS está completamente documentado, con tutoriales fáciles de seguir y un manual de referencia completo y actualizado.

• Pequeño. MaraDNS es muy adecuado para aplicaciones integradas y otros entornos en los que el servidor debe utilizar el número mínimo absoluto de recursos posible. El binario de MaraDNS es más pequeño que el de cualquier otro servidor DNS recursivo mantenido actualmente.

• Fuente abierta. MaraDNS es completamente de código abierto. La licencia es una licencia BSD de dos cláusulas que es casi idéntica a la licencia de FreeBSD.

Vea la página de defensa de maraDNS donde hay una comparación de varios software de servidor DNS que pueden ayudarlo a elegir.

Si está ejecutando DNS solo para usted, djbdns es el mejor paquete de software. Fue uno de los pocos paquetes de software que identificó el principal problema de seguridad de DNS del año pasado y fue creado / parcheado para solucionarlo años antes. Para el almacenamiento en caché de DNS, instalo dnscache (parte de djbdns) en todos los servidores que no se ejecutan como servidores DNS autorizados. Realmente funciona mejor que BIND para la mayoría de los artículos, pero dado el hardware actual, el peso extra y la velocidad más lenta de BIND no son un problema.

Por experiencia, aprendería los conceptos básicos de BIND, independientemente del paquete que elija ejecutar.

Djbdns está configurado para ser realmente fácil de administrar desde la línea de comandos. Todos los cambios en los datos DNS se realizan como comandos. En BIND, edita una serie de archivos de texto.

Puede obtener paquetes para ambos. Veo la diferencia como IE frente a otros navegadores. IE viene integrado y funciona para muchas cosas y no cambia el valor predeterminado. Djbdns es diferente y requiere un conjunto diferente de compensaciones. Para un ISP, pasar de BIND a djbdns puede ser un poco complicado, porque BIND por defecto almacena en caché y sirve nombres, mientras que djbdns divide esto en dos partes. Esta solución de seguridad preferida, pero es más difícil de configurar, por lo que muchas instalaciones BIND no molestan.

Personalmente, diría que necesita aprender los conceptos básicos de BIND por motivos de referencia, pero que pasar a otra cosa lo hará un administrador de sistemas más feliz para el futuro :)

La mayoría de los lugares en los que he trabajado en la industria de ISP parecen utilizar djbdns, ya que proporciona excelentes bloques de construcción y bases para superponer servicios 'administrados': escribir scripts para generar archivos de zona es bastante trivial, lo que significa que puede almacenar todos sus datos DNS en SQL de todos modos. Maneja una cantidad ridícula de consultas por segundo y es seguro arrancar.

Si necesita escalarlo, ¡solo eche un vistazo a http://haproxy.1wt.eu y coloque algunos servidores autorizados detrás de eso! También recomiendo dividir los resolvers de los servidores autorizados en cualquier configuración que elija implementar.

Otras cosas que vale la pena leer son MaraDNS y PowerDNS.

Principalmente uso FreeBSD para este tipo de cosas y dado que viene con BIND, nunca me tomé el esfuerzo de aprender nada más. Sin embargo, encuentro que BIND es bastante fácil de configurar y, dado que FreeBSD lo mantiene en una perspectiva de seguridad, solo tengo que rastrear ese canal para detectar cualquier problema de seguridad.

Así que supongo que la mejor opción para ti es probar ambos y ver cuál es el que más te conviene, a menos que uses un sistema operativo que viene incluido con cualquiera de ellos.

Si está buscando aprender sobre DNS, una copia del libro de O'Reilly " DNS y BIND " y la última versión de bind instalada es probablemente la mejor opción.

Es cierto que BIND ha tenido más problemas de seguridad en su vida útil. dnjdns no tenía ninguno hasta el año pasado, pero tiene una arquitectura muy diferente de BIND y puede que le resulte más difícil de aprender si no está familiarizado con el funcionamiento del sistema de nombres.

Si solo está buscando aprender cómo ejecutar un servidor DNS (en lugar de aprender sobre los protocolos y demás), sería mejor elegir uno y sumergirse. Espero que encuentre paquetes binarios para ambos en la distribución * nix que elijas. Dicho esto, hay algunas ventajas de compilar desde la fuente con software que puede necesitar reconstruir si se anuncia una vulnerabilidad de seguridad.

Al igual que con cualquier servicio con conexión a Internet, el mejor camino a seguir es el sentido común y el pensamiento pragmático, independientemente del software que utilice. Si tiene que habilitar las actualizaciones dinámicas, asegúrese de que estén firmadas. Si permite transferencias de zona, restrinja quién puede realizarlas desde su servidor, etc.

ENLAZAR.

Si aprenderá cómo configurarlo (mientras lee un montón de RFC algo molestos relacionados con DNS), puede cambiar fácilmente a otro servidor DNS en el futuro (para cualquier propósito). Estoy usando BIND como servidores primarios y secundarios en todas partes en FreeBSD, Linux e incluso en la computadora portátil Vista (para hosts VMware NAT).

Por cierto, es divertido leer la fuente de BIND y descubrir cómo, por ejemplo, funciones clásicas como gethostbyname () o gethostbyaddr () funcionan.

Después de años de usar bind, finalmente me di cuenta de que la mayoría de mis servidores no necesitan ejecutar su propio demonio DNS. Puede que esto no se aplique a usted, pero piense en ello: prácticamente todos los registradores de dominios en estos días le ofrecen al servidor sus registros DNS por usted (generalmente le brindan una forma basada en la web para editar sus registros DNS). Se encargan de servir la información, administrar las secundarias, etc. Si elimina la necesidad de que su servidor responda a las consultas DNS, todo lo que queda es que su servidor realice búsquedas DNS. Para esto, apunto mi /etc/resolv.conf en 4.2.2.1 y 4.2.2.2, que son los servidores DNS "anycast" de Level3 y parecen ser bastante rápidos y confiables.

Una ventaja adicional es que la configuración del firewall para su servidor ya no tiene que permitir el ingreso de DNS. Solo necesita la regla "establecida, relacionada" para permitir que las consultas DNS de su servidor funcionen.

Bien, entonces no preguntaste si necesitabas ejecutar un demonio DNS, pero esa es la pregunta que respondí. Para completar, si encuentra que debe ejecutar uno, le recomiendo seguir con Bind porque se usa con tanta frecuencia que encontrará mucha documentación y ayuda para que haga lo que desea.