djbdns vs bind [chiuso]

Sono un principiante che vuole imparare come impostare un nameserver DNS. Dovrei usare djbdns, BIND o qualcos'altro?

I requisiti di rete attuali includono supporto per sottodomini, SSL e servizio di posta, il tutto su un traffico molto leggero. Vorrei una soluzione che un giorno potesse aumentare il traffico più pesante e possibilmente requisiti più difficili (come il bilanciamento del carico). In questo momento avrei eseguito su Linux.

Ho letto che BIND ha problemi di sicurezza se non configurato correttamente e che la sua configurazione può essere complicata. Ho anche letto che djbdns è più facile da configurare, più sicuro e uguale a carichi pesanti. Gli argomenti per i djbdns sembrano plausibili, ma non ho l'esperienza per valutarli correttamente. Se BIND è migliore, apprezzerei una discussione di tali affermazioni per djbdns.

Grazie.

Ho lavorato con djbdns in passato e attualmente eseguo un sacco di server BIND.

Il problema più grande con djbdns è quello di mettere il mio insegnante di prima elementare sulla mia pagella: "non gioca bene con gli altri". Semplicemente non si comporta come qualsiasi altra cosa su una scatola unix in tutti i modi molto piccoli che possono morderti in seguito. Usa una sintassi per i file di zona che non vedrai da nessun'altra parte.

Il più grande vantaggio di djbdns è che è stato progettato da zero con la sicurezza come obiettivo n. 1.

Se avessi impostato un server DNS, lo esponessi a Internet e non lo manterrai mai, djbdns sarebbe la strada da percorrere.

Nel mondo reale, la maggior parte degli amministratori sta meglio usando i pacchetti BIND del fornitore del sistema operativo e correggendolo prontamente quando c'è un aggiornamento. Ma eseguirlo con il chroot è una buona idea, e mantenere i server DNS autorevoli separati dai server DNS risolutori ricorsivi è una buona idea.

Se trovi documenti per qualcosa con DNS, BIND verrà incluso e è improbabile che djbdns venga incluso. Se si utilizza dig, il formato che restituisce può essere incollato in un file di zona BIND e funzionare. Si comporta come un normale demone unix invece di qualcosa proveniente da un altro pianeta.

Utilizziamo alcuni bilanciatori del carico hardware e bilanciamo il carico dei nostri server BIND risolutore ricorsivo; funziona alla grande. Assicurati solo che gli utenti ottengano lo stesso IP di origine a cui hanno inviato le loro richieste e che qualsiasi configurazione di bilanciamento del carico compatibile con UDP e TCP dovrebbe funzionare. Se stai eseguendo un DNS autorevole, il bilanciamento del carico è semplice come avere più di un server e pubblicarli tutti nelle informazioni whois; gli altri server DNS caricheranno il bilanciamento in modo intelligente.

Per un servizio autorevole, nsd .

Per uno ricorsivo, nessun impegno .

Entrambi sono piccoli (quindi probabilmente hanno meno falle di sicurezza in attesa di essere scoperti), gestiti attivamente e supportano tutte le recenti cose DNS (DNSSEC, IPv6, ecc.).

Altrimenti, BIND è un buon software.

djbdns è un progetto one-man, non mantenuto per lungo tempo, non più sicuro (l'autore dice così) e il sito Web ufficiale è pieno di errori. (Ora, sono sicuro che otterrò molti voti negativi da DJJBO, il mio rappresentante era troppo alto per i miei gusti :-)

Se è per te e se vuoi imparare come funziona il DNS, userei djbdns.

Se vuoi capire come fanno tutti gli altri DNS e come supportare le tipiche implementazioni aziendali, impara il bind.

Se il tuo obiettivo è il minimo sforzo e supporto, e sei ragionevolmente competente, djbdns ha un overhead di supporto molto più basso.

Se sei più dalla parte dei principianti della recinzione, probabilmente avrai un momento più facile per legarti e correre, ma tieni presente che è molto più probabile che esploda in modi strani e stravaganti.

Se non avessi già conosciuto djbdns (e bind) avrei anche cercato powerdns e maradns, ma dubito che per installazioni minuscole sia meglio della suite djbdns.

Indipendentemente da ciò, anche se usi bind per pubblicizzare il tuo DNS su Internet, dovresti comunque eseguire dnscache (parte della suite djbdns) in esecuzione su localhost per il resolver del tuo sistema.

Skip djbdns. Sebbene djb sia un eroe, porta l'arroganza di un matematico nei confronti del software. Il fatto che non si comporti come un altro software rispetto all'avvio / arresto potrebbe essere una buona dimostrazione di una tecnica intelligente di gestione dei demoni. Ma dovrai estrarre la documentazione se non la usi regolarmente, perché tutto è così diverso. Se lo configuri su sistemi gestiti anche da altri, dovrai scrivere loro una documentazione chiara, che dovranno leggere nella loro interezza per fare semplici operazioni. Correre roba da init è carino, persino intelligente. Ma è anche odioso, sorprendente e non standard.

Inoltre, ho avuto problemi con djbdns che causavano seri problemi a causa dell'insistenza sul solo rispetto degli standard e non dell'interoperabilità del software. La risoluzione di questi problemi è stata una grande perdita di tempo, perché dipendeva da differenze minori nei pacchetti DNS.

Anche djbdns ha comportamenti strani in alcuni casi che causano la risoluzione dei problemi del server DNS con strumenti diversi da quelli di djb (ad es. Con nslookup) per ottenere risultati sorprendenti. Perderai il tuo tempo a spiegare "in realtà, io uso solo questo oscuro server DNS chiamato djbdns. Il problema è che i tuoi strumenti diagnostici ti stanno dando uno strano messaggio, ma funziona bene. Se guardi questa acquisizione di pacchetti, puoi dire Questo non è correlato al problema che abbiamo avuto alcuni mesi fa in cui djbdns non interagiva correttamente con il tuo server DNS, né è correlato al problema che abbiamo avuto qualche settimana fa in cui ero fuori ufficio e ha impiegato il mio compagni di squadra un'ora per riavviare il server DNS ".

Problemi simili con qmail tutto intorno.

C'è qualche valore educativo nell'impostare djbdns, se stai ponendo la domanda e hai il tempo di uccidere. Puoi anche imparare molte cose semplicemente leggendo il sito web di djb.

Esistono due serie di problemi di sicurezza. Falle di sicurezza che consentono a un utente malintenzionato di accedere al sistema: quasi sicuramente djbdns non ne ha. Alcuni anni fa Bind ne ha scoperti abbastanza imbarazzanti in breve tempo, esponendo anche un cattivo design. Mi aspetto che in questi anni sia stato completamente riscritto. Se vuoi davvero essere sicuro in questo senso, eseguilo sotto una macchina virtuale (ad esempio Xen). Inoltre, se stai eseguendo un sistema Linux con SELinux in modalità mirata, avrai una configurazione per bind e probabilmente non ti preoccuperai di uno per djbdns. Il sistema bind + SELinux è potenzialmente più sicuro.

L'altro problema è la sicurezza contro l'avvelenamento da cache. La mia ipotesi è che djbdns fosse migliore quando è stato rilasciato, e probabilmente il bind ora è migliore a causa di una maggiore attenzione. Questa è probabilmente la causa dell'udito che il legame è insicuro a meno che non sia "correttamente configurato". Dovresti almeno cercare e comprendere questo problema. Nel processo probabilmente scoprirai quali rischi di configurazione esistono per entrambi i server DNS.

Il comportamento sotto carico è un criterio senza senso per la maggior parte degli utenti. Prestare attenzione alle prestazioni utilizzate come criteri per valutare software che raramente rappresenta un collo di bottiglia nelle prestazioni. Non stai ospitando un server DNS di cache per un'enorme base di utenti, dove potresti ricevere richieste a un tasso significativo. Stai utilizzando DNS autorevole per fornire servizi che probabilmente sono in esecuzione sullo stesso sistema. Questi servizi sono migliaia di volte più costosi del DNS. Il tuo collegamento Internet potrebbe non essere nemmeno sufficiente per caricare pesantemente il tuo server DNS, ma se tu stessi ricevendo un carico così pesante sui servizi che fornisci, il DNS non sarebbe un probabile collo di bottiglia.

Potresti dare un'occhiata a MaraDNS , un server DNS sensibile alla sicurezza.

• Sicuro. MaraDNS ha una cronologia di sicurezza buona o migliore di qualsiasi altro server DNS. Ad esempio, MaraDNS ha sempre randomizzato, utilizzando un generatore di numeri casuali sicuri, l'ID query e la porta di origine delle query DNS; e non è mai stato vulnerabile al "nuovo" attacco di avvelenamento da cache.

• Supportato. MaraDNS ha una lunga storia di manutenzione e aggiornamento. MaraDNS è stato originariamente creato nel 2001. MaraDNS 1.0 è stato rilasciato nel 2002 e MaraDNS 1.2 è stato rilasciato nel dicembre del 2005. MaraDNS è stato ampiamente testato, sia con un processo SQA che con oltre quattro anni di utilizzo nel mondo reale. MaraDNS continua a essere pienamente supportato: la versione più recente è stata rilasciata il 13 febbraio 2009. Deadwood, il codice che diventerà parte di MaraDNS 2.0, è in fase di sviluppo attivo.

• Facile da usare. Una configurazione ricorsiva di base richiede solo un singolo file di configurazione a tre righe. Una configurazione autorevole di base richiede solo un file di configurazione a quattro righe e un file di zona a una riga. MaraDNS è completamente documentato, con esercitazioni facili da seguire e un manuale di riferimento completo e aggiornato.

• Piccolo. MaraDNS è adatto per applicazioni integrate e altri ambienti in cui il server deve utilizzare il numero minimo assoluto di risorse possibile. Il binario di MaraDNS è più piccolo di quello di qualsiasi altro server DNS ricorsivo attualmente gestito.

• Open Source. MaraDNS è completamente open-source, La licenza è una licenza BSD a due clausole quasi identica alla licenza FreeBSD.

Consulta la pagina di supporto di maraDNS in cui è presente un confronto tra diversi software server DNS che possono aiutarti a scegliere.

Se stai eseguendo DNS solo per te stesso, djbdns è il pacchetto software migliore. Era uno dei pochi pacchetti software che aveva identificato il principale problema di sicurezza DNS dello scorso anno ed è stato creato / corretto per risolverlo anni prima. Per la memorizzazione nella cache DNS, installo dnscache (parte di djbdns) su tutti i server che non funzionano come server DNS autorevoli. Funziona davvero meglio di BIND per la maggior parte degli articoli, ma dato l'hardware di oggi, il peso extra e la velocità più bassa di BIND non sono un problema.

Per esperienza, imparerei le basi di BIND, indipendentemente dal pacchetto che scegli di eseguire.

Djbdns è impostato per essere veramente facile da amministrare dalla riga di comando. Tutte le modifiche ai dati DNS vengono eseguite come comandi. In BIND, si modifica una serie di file di testo.

Puoi ottenere pacchetti per entrambi. Vedo la differenza come IE rispetto ad altri browser. IE è integrato e funziona per molte cose e non cambia da quello predefinito. Djbdns è diverso e richiede un diverso set di compromessi. Per un ISP, passare da BIND a djbdns può essere un po 'complicato, perché BIND per impostazione predefinita esegue la memorizzazione nella cache e la gestione dei nomi, mentre come djbdns lo divide in due parti. Questa soluzione di sicurezza preferita, ma è più difficile da configurare, quindi molte installazioni BIND non danno fastidio.

Personalmente direi che devi imparare le basi di BIND come riferimento, ma che passare a qualcos'altro ti renderà un amministratore di sistema più felice per il futuro :)

La maggior parte dei posti in cui ho lavorato nel settore dell'ISP sembrano fare uso di djbdns, fornisce eccellenti elementi costitutivi e basi per sovrapporre i servizi "gestiti" in cima - scrivere script per generare file di zona è piuttosto banale, il che significa che puoi archiviare tutti i tuoi dati DNS in SQL comunque. Gestisce una quantità ridicola di query al secondo ed è sicuro da avviare.

Se hai bisogno di ridimensionarlo, dai un'occhiata a http://haproxy.1wt.eu e pop alcuni server autorevoli dietro quello! Consiglio vivamente di suddividere i resolver dai server autorevoli in qualsiasi configurazione che si sceglie di distribuire.

Altre cose che vale la pena leggere sono MaraDNS e PowerDNS.

Uso principalmente FreeBSD per questo tipo di cose e dato che si tratta di bundle con BIND, non ho mai fatto davvero lo sforzo di imparare nient'altro. Per quanto trovo che BIND sia piuttosto facile da configurare e poiché è gestito in una prospettiva di sicurezza da FreeBSD, devo solo seguire quel canale per eventuali problemi di sicurezza.

Quindi immagino che la scommessa migliore per te sia provare entrambi e vedere quale ti piace di più, cioè a meno che tu non usi un sistema operativo fornito in bundle con uno di essi.

Se stai cercando di conoscere il DNS, una copia del libro O'Reilly " DNS and BIND " e l'ultima versione di bind installata è probabilmente il modo migliore per andare.

È vero che BIND ha avuto più problemi di sicurezza nel corso della sua vita. dnjdns non ne ha avuti fino allo scorso anno, ma ha un'architettura molto diversa da BIND e potresti trovare più difficile raccogliere se non hai familiarità con il funzionamento del sistema di denominazione.

Se stai solo cercando di imparare come eseguire un server DNS (invece di apprendere i protocolli e simili), sarebbe meglio sceglierne uno e immergersi. Mi aspetto che troverai pacchetti binari per entrambi in qualunque * nix distro tu scelga. Detto questo, ci sono alcuni vantaggi nella compilazione dall'origine con software che potrebbe essere necessario ricostruire se viene annunciata una vulnerabilità di sicurezza.

Come con qualsiasi servizio rivolto a Internet, il buon senso e il pensiero pragmatico sono il modo migliore di procedere, indipendentemente dal software utilizzato. Se devi abilitare gli aggiornamenti dinamici, assicurati che siano firmati. Se consenti i trasferimenti di zona, limita chi può eseguirli dal tuo server ecc.

BIND.

Se imparerai come configurarlo (leggendo un sacco di fastidiosi RFC relativi al DNS), in futuro puoi facilmente passare a un altro server DNS (per qualsiasi scopo). Sto usando BIND come server primari e secondari ovunque su FreeBSD, Linux e persino sul laptop Vista (per host NAT VMware).

A proposito, è un po 'divertente leggere la fonte di BIND e scoprire come, ad esempio, funzioni classiche come gethostbyname () o gethostbyaddr () funzionano.

Dopo anni di utilizzo di bind, ho finalmente capito che la maggior parte dei miei server non ha bisogno di eseguire il proprio demone DNS. Questo potrebbe non valere per te, ma pensaci: praticamente ogni registrar di domini in questi giorni offre di server per i tuoi record DNS per te (di solito ti dà un modo basato sul web per modificare i tuoi record DNS). Gestiscono la gestione delle informazioni, la gestione dei secondari, ecc. Se si rimuove la necessità che il server risponda alle query DNS, tutto ciò che resta da fare è che il server esegua ricerche DNS. Per questo, indico il mio /etc/resolv.conf su 4.2.2.1 e 4.2.2.2, che sono i server DNS "anycast" di Level3 e sembrano essere abbastanza veloci e affidabili.

Un ulteriore vantaggio è che la configurazione del firewall per il tuo server non deve più entrare nel DNS. Hai solo bisogno della regola "stabilita, correlata" per consentire il funzionamento delle query DNS del tuo server.

Ok, quindi non hai chiesto se avessi bisogno di eseguire un demone DNS, ma questa è la domanda a cui ho risposto. Per essere completo, se trovi che devi eseguirne uno, ti consiglio di attenermi perché è così comunemente usato che troverai un sacco di documentazione e ti aiuterà a farlo fare quello che vuoi.