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.