djbdns vs bind [ditutup]


20

Saya seorang pemula yang ingin belajar cara mengatur server nama DNS. Haruskah saya menggunakan djbdns, BIND, atau yang lainnya?

Persyaratan jaringan saat ini termasuk dukungan subdomain, SSL, dan layanan surat, semuanya pada lalu lintas yang sangat ringan. Saya ingin solusi yang suatu hari nanti dapat meningkatkan lalu lintas yang lebih berat dan persyaratan yang mungkin lebih rumit (seperti load balancing). Saat ini saya sudah menjalankan keduanya di Linux.

Saya pernah membaca bahwa BIND memiliki masalah keamanan jika tidak dikonfigurasi dengan benar, dan konfigurasinya bisa rumit. Saya juga membaca bahwa djbdns lebih mudah untuk dikonfigurasi, lebih aman, dan sama dengan beban berat. Argumen untuk djbdns tampaknya masuk akal, tetapi saya tidak memiliki keahlian untuk mengevaluasinya dengan baik. Jika BIND lebih baik, saya akan menghargai diskusi tentang klaim untuk djbdns.

Terima kasih.


Layanan resmi atau yang rekursif?
bortzmeyer

Berwenang, saya pikir.
chernevik

Jawaban:


14

Saya telah bekerja dengan djbdns di masa lalu dan saat ini menjalankan banyak server BIND.

Masalah terbesar dengan DJJns adalah yang terbaik menempatkan cara guru kelas satu saya meletakkannya di kartu laporan saya: "tidak bermain baik dengan orang lain". Itu hanya tidak berperilaku seperti apa pun di kotak unix dalam segala macam cara yang sangat kecil yang dapat menggigit Anda nanti. Itu menggunakan sintaks untuk file zona Anda tidak akan melihat di tempat lain.

Keuntungan djbdns terbesar adalah bahwa ia dirancang dari bawah ke atas dengan keamanan sebagai tujuan # 1.

Jika Anda akan mengatur server DNS, memaparkannya ke internet dan kemudian tidak pernah memeliharanya, djbdns akan menjadi cara untuk pergi.

Di dunia nyata, sebagian besar admin lebih baik menggunakan paket BIND dari vendor OS, dan menambalnya segera ketika ada pembaruan. Tetapi menjalankannya chroot adalah ide yang bagus, dan menjaga server DNS otoritatif Anda terpisah dari server DNS resolver rekursif Anda adalah ide yang bagus.

Jika Anda menemukan dokumen untuk sesuatu dengan DNS, BIND akan dimasukkan dan djbdns tidak mungkin disertakan. Jika Anda menggunakan dig, format yang dikembalikannya dapat ditempelkan ke file zona BIND dan berfungsi. Kerjanya seperti daemon unix normal dan bukan sesuatu dari planet lain.

Kami menggunakan beberapa penyeimbang beban perangkat keras dan menyeimbangkan server BIND penyelesai rekursif kami; bekerja dengan baik. Pastikan saja pengguna mendapatkan IP sumber yang sama saat mereka mengirim permintaan mereka ke dan pengaturan penyeimbangan beban yang mampu UDP dan TCP harus bekerja. Jika Anda melakukan DNS resmi, load balancing semudah memiliki lebih dari satu server dan menerbitkan semuanya di info whois; server DNS lainnya akan memuat keseimbangan secara cerdas.


2
Saya suka menganggapnya seolah-olah DJN tidak bekerja, itu salahmu, jika ya, maka DJ-nya.
Dave Cheney

2
Seluruh diskusi sangat membantu, dan memilih satu jawaban tampaknya agak tidak adil bagi yang lain. Yang ini paling dekat dengan kesimpulan yang saya raih sendiri: apa pun perbedaan teknologinya, BIND lebih baik didukung oleh dokumentasi dan komunitas. Seperti jawaban lain yang dicatat, memahami sepertinya akan menyederhanakan interaksi DNS di masa depan. Keuntungan itu tampaknya lebih penting daripada manfaat apa pun yang ditawarkan djbdns dalam kemudahan konfigurasi.
chernevik

9

Untuk layanan resmi , nsd .

Untuk yang rekursif, tidak terikat .

Keduanya kecil (jadi mungkin memiliki lubang keamanan yang lebih sedikit menunggu untuk ditemukan), dipelihara secara aktif dan mendukung semua hal-hal DNS terbaru (DNSSEC, IPv6, dll).

Kalau tidak, BIND adalah perangkat lunak yang baik.

djbdns adalah proyek satu orang, tidak dipelihara untuk waktu yang lama, tidak lebih aman (penulis hanya mengatakannya demikian), dan situs Web resmi penuh dengan kesalahan. (Sekarang, saya yakin saya akan mendapatkan banyak downvotes dari djbboys, perwakilan saya terlalu tinggi untuk seleraku :-)


8

Jika itu untuk Anda sendiri, dan jika Anda ingin mempelajari cara kerja DNS, saya akan menggunakan djbdns.

Jika Anda ingin memahami bagaimana semua orang melakukan DNS, dan bagaimana mendukung penyebaran tipikal perusahaan, pelajari bind.

Jika tujuan Anda adalah upaya dan dukungan minimal, dan Anda cukup kompeten, DJJN memiliki overhead dukungan yang jauh lebih rendah.

Jika Anda lebih banyak berada di sisi pemula pagar, Anda mungkin akan memiliki waktu lebih mudah untuk mengikat dan berlari, tetapi perlu diingat bahwa itu jauh lebih mungkin untuk meledak dengan cara yang aneh dan aneh.

Jika saya belum tahu djbdns (dan mengikat) saya juga akan melihat powerdns dan maradns, tapi saya ragu bahwa untuk instalasi kecil itu lebih baik daripada djbdns suite.

Bagaimanapun, bahkan jika Anda menggunakan bind untuk mengiklankan DNS Anda ke internet, Anda tetap harus menjalankan dnscache (bagian dari paket djbdns) yang berjalan di localhost untuk resolver sistem Anda.


6

Lewati djbdns. Meskipun djb adalah pahlawan, ia membawa kesombongan matematikawan ke perangkat lunak. Fakta bahwa itu tidak berperilaku seperti perangkat lunak lain sehubungan dengan memulai / menghentikannya mungkin merupakan demonstrasi yang baik dari teknik pintar mengelola daemon. Tetapi Anda harus menarik dokumentasi jika Anda tidak menggunakannya secara teratur, karena semuanya sangat berbeda. Jika Anda mengaturnya pada sistem yang dipelihara orang lain juga, Anda harus menuliskannya dokumentasi yang jelas - yang harus dibaca secara keseluruhan untuk melakukan operasi sederhana. Kehabisan barang init itu lucu, bahkan pintar. Tapi itu juga menjengkelkan, mengejutkan, dan tidak standar.

Juga, saya punya masalah dengan DJJN yang menyebabkan masalah serius karena desakan hanya menghormati standar, dan bukan interoperabilitas perangkat lunak. Memecahkan masalah ini adalah buang-buang waktu, karena bergantung pada perbedaan kecil dalam paket DNS.

Djjjns juga memiliki perilaku aneh dalam kasus-kasus tertentu yang akan menyebabkan orang memecahkan masalah server DNS Anda dengan alat selain dari DjJs (misalnya dengan nslookup) untuk mendapatkan hasil yang mengejutkan. Anda akan membuang waktu Anda untuk menjelaskan "sebenarnya, saya hanya menggunakan server DNS tidak jelas ini yang disebut djbdns. Masalahnya adalah alat diagnostik Anda memberi Anda pesan aneh, tetapi berfungsi dengan baik. Jika Anda melihat tangkapan paket ini, Anda dapat memberitahu Ini tidak terkait dengan masalah yang kami miliki beberapa bulan yang lalu di mana djbdns tidak beroperasi dengan benar dengan server DNS Anda. Juga tidak terkait dengan masalah yang kami miliki beberapa minggu yang lalu di mana saya berada di luar kantor dan saya memerlukan waktu. rekan satu jam untuk memulai kembali server DNS. "

Masalah serupa dengan qmail ada di sekitar.

Ada beberapa nilai pendidikan dalam pengaturan djbdns, jika Anda mengajukan pertanyaan dan punya waktu untuk membunuh. Anda juga dapat belajar banyak dengan hanya membaca situs web djb.

Ada dua set masalah keamanan. Lubang keamanan yang memungkinkan penyerang mengakses sistem - djbdns hampir pasti tidak memilikinya. Beberapa tahun yang lalu ikat memiliki beberapa yang memalukan ditemukan dalam waktu singkat, juga memperlihatkan desain yang buruk. Saya berharap bahwa selama bertahun-tahun ini, sudah sepenuhnya ditulis ulang. Jika Anda benar-benar ingin aman dalam hal ini, jalankan di bawah mesin virtual (mis. Xen). Juga pertimbangkan, jika Anda menjalankan sistem Linux dengan SELinux dalam mode yang ditargetkan, Anda akan memiliki pengaturan untuk bind dan mungkin tidak akan repot dengan satu untuk djbdns. Sistem bind + SELinux berpotensi lebih aman.

Masalah lainnya adalah keamanan terhadap keracunan cache. Dugaan saya adalah bahwa DJJns lebih baik ketika dirilis, dan mengikat mungkin lebih baik sekarang karena perhatian yang lebih besar. Ini mungkin penyebab pendengaran Anda yang mengikat tidak aman kecuali "dikonfigurasi dengan benar". Anda setidaknya harus meneliti dan memahami masalah ini. Dalam prosesnya Anda mungkin akan mengetahui risiko konfigurasi apa yang ada untuk kedua server DNS.

Perilaku di bawah beban berat adalah kriteria yang tidak masuk akal bagi sebagian besar pengguna. Waspadalah terhadap kinerja yang digunakan sebagai kriteria untuk mengevaluasi perangkat lunak yang jarang menjadi hambatan kinerja. Anda tidak meng-hosting server DNS caching untuk basis pengguna yang besar, tempat Anda mungkin mendapatkan permintaan pada tingkat yang signifikan. Anda menjalankan DNS resmi untuk menyediakan layanan yang mungkin berjalan pada sistem yang sama. Layanan ini ribuan kali lebih mahal daripada DNS. Tautan Internet Anda mungkin bahkan tidak cukup untuk memuat server DNS Anda, tetapi jika Anda menerima beban yang begitu besar pada layanan yang Anda berikan, DNS tidak akan menjadi penghambat.


5

Anda mungkin ingin melihat MaraDNS , server DNS yang sadar keamanan.

  • Aman. MaraDNS memiliki riwayat keamanan yang sama baiknya atau lebih baik dari server DNS lainnya. Sebagai contoh, MaraDNS selalu secara acak, menggunakan generator nomor acak yang aman, ID Kueri dan port sumber permintaan DNS; dan tidak pernah rentan terhadap serangan keracunan cache "baru".

  • Didukung MaraDNS memiliki sejarah panjang tentang pemeliharaan dan pembaruan. MaraDNS awalnya dibuat pada tahun 2001. MaraDNS 1.0 dirilis pada tahun 2002 dan MaraDNS 1.2 dirilis pada Desember 2005. MaraDNS telah diuji secara luas, baik dengan proses SQA dan dengan lebih dari empat tahun penggunaan di dunia nyata. MaraDNS terus didukung sepenuhnya: Rilis terbaru dilakukan pada 13 Februari 2009. Deadwood, kode yang akan menjadi bagian dari MaraDNS 2.0, sedang dikembangkan secara aktif.

  • Mudah digunakan. Konfigurasi rekursif dasar hanya membutuhkan satu file konfigurasi tiga baris. Konfigurasi dasar otoritatif hanya memerlukan file konfigurasi empat baris dan file zona satu baris. MaraDNS sepenuhnya didokumentasikan, dengan tutorial yang mudah diikuti dan manual referensi yang lengkap dan terkini.

  • Kecil. MaraDNS sangat cocok untuk aplikasi tertanam dan lingkungan lain di mana server harus menggunakan sumber daya minimum absolut yang mungkin. Biner MaraDNS lebih kecil daripada biner dari server DNS rekursif lainnya yang saat ini dikelola.

  • Sumber Terbuka. MaraDNS sepenuhnya open-source, Lisensi ini adalah lisensi BSD dua klausa yang hampir identik dengan lisensi FreeBSD.

Lihat halaman advokasi maraDNS di mana ada perbandingan beberapa perangkat lunak server DNS yang dapat membantu Anda memilih.


MaraDNS tidak lagi dikelola oleh penulis, seperti yang tercantum pada halaman muka
Joseph Holsten

1
Sebagai koreksi, sementara saya tidak lagi mengembangkan MaraDNS secara aktif, saya masih mempertahankannya (perbaikan bug, pembaruan untuk kompiler baru dan distro Linux, dll.). Bahkan, saya baru saja mengeluarkan rilis MaraDNS baru tahun ini (2014) dan mungkin akan membuat satu tahun depan: maradns.samiam.org/download.html
samiam

4

Jika Anda menjalankan DNS hanya untuk Anda sendiri, djbdns adalah paket perangkat lunak yang lebih baik. Itu adalah salah satu dari beberapa paket perangkat lunak yang telah mengidentifikasi masalah keamanan DNS utama dari tahun lalu dan dibangun / ditambal untuk memperbaikinya bertahun-tahun sebelumnya. Untuk caching DNS, saya menginstal dnscache (bagian dari djbdns) di semua server yang tidak berjalan sebagai server DNS yang otoritatif. Ini benar-benar bekerja lebih baik daripada BIND untuk sebagian besar barang, tetapi mengingat perangkat keras saat ini, bobot ekstra dan kecepatan lebih lambat dari BIND adalah bukan masalah.

Untuk pengalaman, saya akan mempelajari dasar-dasar BIND, terlepas dari paket mana yang Anda pilih untuk dijalankan.

Djbdns sudah diatur agar mudah admin dari baris perintah. Semua perubahan pada data DNS dilakukan sebagai perintah. Di BIND, Anda mengedit serangkaian file teks.

Anda bisa mendapatkan paket untuk keduanya. Saya melihat perbedaannya sebagai IE vs browser lain. IE hadir dan bekerja untuk banyak hal dan tidak berarti Anda mengubah dari default. Djbdns berbeda dan membutuhkan serangkaian trade-off yang berbeda. Untuk ISP, pindah dari BIND ke djbdns bisa menjadi sedikit rumit, karena BIND secara default melakukan caching dan penyajian nama, sedangkan djbdns membagi ini menjadi dua bagian. Ini solusi keamanan yang disukai, tetapi lebih sulit untuk diatur, sehingga banyak instalasi BIND yang tidak mengganggu.


3

Secara pribadi saya akan mengatakan bahwa Anda perlu mempelajari dasar-dasar BIND demi referensi, tetapi pindah ke hal lain akan membuat Anda seorang administrator sistem yang lebih bahagia untuk masa depan :)

Sebagian besar tempat saya bekerja di industri ISP tampaknya menggunakan djbdns, ini memberikan blok bangunan yang sangat baik dan fondasi untuk lapisan layanan 'terkelola' di atas - penulisan skrip untuk menghasilkan file zona cukup sepele, artinya Anda dapat menyimpan semua data DNS Anda dalam SQL. Ini menangani sejumlah pertanyaan konyol per detik dan aman untuk boot.

Jika Anda perlu mengatur skala, lihat saja di http://haproxy.1wt.eu dan pop beberapa server otoritatif di belakang itu! Saya juga sangat merekomendasikan pemecahan resolvers dari server otoritatif dalam pengaturan apa pun yang Anda pilih untuk digunakan.

Hal-hal lain yang layak dibaca adalah MaraDNS dan PowerDNS.


2

Saya terutama menggunakan FreeBSD untuk hal-hal semacam ini dan karena ada bundel dengan BIND saya tidak pernah benar-benar berusaha untuk mempelajari hal lain. Namun saya menemukan BIND agak mudah dikonfigurasikan dan karena dikelola dalam perspektif keamanan oleh FreeBSD, saya hanya perlu melacak saluran itu untuk masalah keamanan apa pun.

Jadi saya kira taruhan terbaik untuk Anda adalah mencoba keduanya dan lihat mana yang paling cocok untuk Anda, kecuali Anda menggunakan OS yang dibundel dengan keduanya.


2

Jika Anda ingin mempelajari tentang DNS, salinan buku O'Reilly " DNS and BIND " dan versi terbaru dari bind yang diinstal mungkin merupakan cara terbaik untuk melakukannya.

Memang benar bahwa BIND memiliki lebih banyak masalah keamanan seumur hidupnya. dnjdns belum memilikinya hingga tahun lalu, tetapi memiliki arsitektur yang sangat berbeda dari BIND dan Anda mungkin merasa lebih sulit untuk mengambilnya jika Anda tidak terbiasa dengan cara kerja sistem penamaan.

Jika Anda hanya ingin belajar tentang cara menjalankan server DNS (sebagai lawan mempelajari tentang protokol dan semacamnya), Anda sebaiknya memilih dan menyelami. Saya berharap Anda akan menemukan paket biner untuk keduanya dalam apa pun * nix distro yang Anda pilih. Yang sedang berkata, ada beberapa keuntungan untuk mengkompilasi dari sumber dengan perangkat lunak yang Anda mungkin perlu membangun kembali jika ada kerentanan keamanan diumumkan.

Seperti halnya layanan yang berhubungan dengan internet, beberapa akal sehat dan pemikiran pragmatis adalah cara terbaik untuk melangkah, terlepas dari perangkat lunak apa yang Anda gunakan. Jika Anda harus mengaktifkan pembaruan dinamis, pastikan itu sudah ditandatangani. Jika Anda mengizinkan transfer zona, batasi siapa yang dapat melakukannya dari server Anda, dll.


1
Saya terjun ke dalam djbdns, dengan cepat menemukan beberapa masalah instalasi kecil, dan menemukan bahwa tidak ada komunitas yang sangat besar yang mendokumentasikan masalah semacam itu. Tidak ada yang seperti "DNS dan BIND" untuk itu. Bahkan jika saya bisa melewati rintangan ini, setiap hal yang saya ingin lakukan lebih mungkin untuk berdiskusi tentang solusi BIND. Apakah teknologinya lebih baik atau tidak, BIND tampaknya memiliki dukungan yang lebih baik.
chernevik

Ternyata, tidak sesulit yang Anda mau. Saya mencoba melakukan pekerjaan, dan membuat pilihan terbaik yang saya bisa dengan pemahaman yang terbatas, tidak menghabiskan potensi alat tertentu. Saya bersyukur atas djbdns, dan perl, dan lighttpd, dan Free BSD, dan semua hal open source lainnya yang saat ini tidak saya gunakan. Yah, hampir semuanya. Tapi saya tidak berpikir Anda bisa dengan serius mengharapkan seorang pemula ke RTFM, atau Mencari TFM, lebih dari saya. Anda jelas berinvestasi dalam djbdns, dan itu bagus. Jika pendapat saya mengganggu Anda, saya kira Anda bisa berharap untuk pemula yang lebih cerdas, atau Anda dapat bekerja untuk memudahkan kami menemukan jawaban.
chernevik

2

MENGIKAT.

Jika Anda akan belajar cara mengkonfigurasinya (sambil membaca sejumlah RFC yang agak melelahkan terkait DNS) maka Anda dapat dengan mudah beralih ke server DNS lain di masa mendatang (untuk tujuan apa pun). Saya menggunakan BIND sebagai server primer dan sekunder di mana-mana di FreeBSD, Linux dan bahkan pada laptop Vista (untuk host VMware NAT'ed).

Btw, itu agak menyenangkan untuk membaca sumber BIND dan menemukan bagaimana, misalnya, fungsi klasik seperti gethostbyname () atau gethostbyaddr () berfungsi.


2

Setelah bertahun-tahun menggunakan bind, akhirnya saya sadar bahwa sebagian besar server saya tidak perlu menjalankan daemon DNS mereka sama sekali. Ini mungkin tidak berlaku untuk Anda, tetapi pikirkan: hampir setiap pendaftar domain hari ini menawarkan ke server catatan DNS Anda untuk Anda (biasanya memberi Anda beberapa cara berbasis web untuk mengedit catatan DNS Anda). Mereka menangani penyajian info, mengelola sekunder, dll. Jika Anda menghapus kebutuhan server Anda untuk menanggapi permintaan DNS, yang tersisa hanyalah server Anda untuk melakukan pencarian DNS. Untuk ini, saya arahkan /etc/resolv.conf di 4.2.2.1 dan 4.2.2.2, yang merupakan server DNS "anycast" Level3 dan tampaknya cukup cepat dan dapat diandalkan.

Bonus tambahan adalah bahwa konfigurasi firewall untuk server Anda tidak perlu lagi masuk ke DNS. Anda hanya perlu aturan "didirikan, terkait" untuk memungkinkan kueri DNS server Anda berfungsi.

Oke, jadi Anda tidak bertanya apakah Anda perlu menjalankan daemon DNS, tapi itulah pertanyaan yang saya jawab. Supaya lengkap, jika Anda harus menjalankannya, saya sarankan tetap menggunakan bind karena ini sangat umum digunakan, Anda akan menemukan banyak dokumentasi dan membantu membuatnya melakukan apa yang Anda inginkan.


Tampaknya masuk akal, tetapi tampaknya lebih mudah untuk mengetahui cara kerjanya dengan pertama-tama hosting sendiri.
chernevik
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.