djbdns vs bind [クローズ]

私はDNSネームサーバーの設定方法を学びたい初心者です。djbdns、BIND、または他の何かを使用する必要がありますか？

現在のネットワーク要件には、サブドメインのサポート、SSL、およびメールサービスが含まれ、すべて非常にトラフィックが少ないです。いつかはより重いトラフィックと、場合によってはより複雑な要件（負荷分散など）にスケールアップできるソリューションが必要です。現時点では、Linuxで実行します。

BINDが適切に構成されていないとセキュリティ上の問題があり、その構成には注意が必要な場合があることを読みました。また、djbdnsは設定が簡単で、安全性が高く、重い負荷に匹敵することも読みました。djbdnの議論はもっともらしいようですが、私はそれらを適切に評価する専門知識を持っていません。BINDの方が良い場合は、djbdnsに対するこれらの主張の議論に感謝します。

ありがとう。

私は過去にdjbdnsで働いてきましたが、現在は多数のBINDサーバーを実行しています。

djbdnsの最大の問題は、私の1年生の先生が自分のレポートカードに「他人と上手く遊ばない」ように置くことです。後であなたに噛みつく可能性のあるあらゆる種類の非常に小さな方法で、Unixボックスの他の何かとはまったく動作しません。他のどこにも表示されないゾーンファイルの構文を使用します。

djbdnsの最大の利点は、目標1としてセキュリティをゼロから設計したことです。

DNSサーバーをセットアップしてインターネットに公開し、それを維持しない場合は、djbdnsが最適です。

現実の世界では、ほとんどの管理者はOSベンダーのBINDパッケージを使用し、更新がある場合はすぐにパッチを適用する方が良いでしょう。ただし、chrootして実行するのは良い考えです。また、信頼できるDNSサーバーを再帰的なリゾルバーDNSサーバーから分離することは良い考えです。

DNSに関する何かのドキュメントを見つけた場合、BINDが含まれ、djbdnsが含まれることはほとんどありません。digを使用する場合、それが返す形式をBINDゾーンファイルに貼り付けて作業することができます。別の惑星からのものではなく、通常のUNIXデーモンのように動作します。

いくつかのハードウェアロードバランサーを使用し、再帰リゾルバーBINDサーバーの負荷を分散します。よく働く。ユーザーがリクエストを送信したときと同じソースIPを取得し、UDPおよびTCP対応の負荷分散セットアップが機能することを確認してください。権限のあるDNSを実行している場合、負荷分散は複数のサーバーを持ち、それらすべてをwhois情報で公開するのと同じくらい簡単です。他のDNSサーバーはインテリジェントに負荷分散します。

信頼できるサービスの場合、nsd。

再帰的なものの場合、unbound。

どちらも小さく（したがって、おそらく発見されるのを待っているセキュリティホールが少ない）、積極的に維持され、最近のDNSのすべて（DNSSEC、IPv6など）をサポートしています。

それ以外の場合、BINDは優れたソフトウェアです。

djbdnsは、長い間メンテナンスされておらず、安全性が劣るワンマンプロジェクトであり（著者はそう言っています）、公式Webサイトには間違いがたくさんあります。（今、私はdjbboysから多くのdownvotesを得ると確信しています。私の担当者は私の好みには高すぎました:-)

自分用であり、DNSの仕組みを学びたい場合は、djbdnsを使用します。

他のすべての人がDNSをどのように行っているか、および典型的なエンタープライズ展開をサポートする方法を理解したい場合は、バインドを学びます。

目標が最小限の労力とサポートであり、合理的な能力がある場合、djbdnsのサポートオーバーヘッドははるかに低くなります。

あなたがフェンスの初心者側にいる場合は、おそらくバインドを開始して実行するのが簡単になりますが、奇妙で奇抜な方法で爆発する可能性がはるかに高いことに注意してください。

djbdns（およびバインド）をまだ知らなかった場合は、powerdnsとmaradnsも調べますが、小さなインストールではdjbdnsスイートよりも優れているとは思いません。

とにかく、DNSをインターネットにアドバタイズするためにバインドを使用する場合でも、システムのリゾルバのlocalhostで実行されるdnscache（djbdnsスイートの一部）を実行する必要があります。

djbdnsをスキップします。djbはヒーローですが、数学者のsoftware慢さをソフトウェアに引き継いでいます。起動/停止に関して他のソフトウェアのように振る舞わないという事実は、デーモンを管理する巧妙なテクニックの良いデモンストレーションかもしれません。ただし、定期的に使用しない場合は、すべてがまったく異なるため、ドキュメントを取り出す必要があります。他の人が同様に管理しているシステムにセットアップする場合は、明確なドキュメントを作成する必要があります。簡単な操作を行うには、ドキュメント全体を読む必要があります。initを実行するのはかわいくて賢いです。しかし、それはまた不快で、驚くべきものであり、非標準です。

また、ソフトウェアの相互運用性ではなく、標準のみを尊重するという主張のために、djbdnが深刻な問題を引き起こす問題がありました。これらの問題のトラブルシューティングは、DNSパケットのわずかな違いにかかっていたため、大きな時間の無駄でした。

また、djbdnsには特定のケースで奇妙な動作があり、人々がdjb以外（nslookupなど）のツールを使用してDNSサーバーのトラブルシューティングを行うと、驚くべき結果が得られます。「実際には、djbdnsと呼ばれるこのあいまいなDNSサーバーを使用しているだけです。問題は、診断ツールから奇妙なメッセージが表示されることですが、正常に機能していることです。このパケットキャプチャを見ると、これは、数か月前にdjbdnsがDNSサーバーと正しく相互運用できなかった問題とは関係ありません。数週間前に私が不在だった問題とは関係なく、チームメイトがDNSサーバーを再起動するのに1時間かかります。」

すべての周りのqmailでの同様の問題。

質問をして殺す時間があるなら、djbdnを設定することには教育的な価値があります。また、djbのWebサイトを読むだけで多くのことを学ぶことができます。

セキュリティには2つの問題があります。攻撃者がシステムにアクセスできるようにするセキュリティホール-djbdnsには、これらのいずれもほぼ確実に含まれていません。数年前、bindには短期間でかなりの数の恥ずかしいものが発見されましたが、これも悪いデザインを露呈しています。私はこの長年にわたって完全に書き直されたことを期待しています。この点で本当に安全にしたい場合は、仮想マシン（Xenなど）で実行してください。また、SELinuxをターゲットモードにしたLinuxシステムで実行している場合は、バインドの設定があり、おそらくdjbdnsの設定は気にしないでしょう。bind + SELinuxシステムは潜在的に安全です。

もう1つの問題は、キャッシュポイズニングに対するセキュリティです。私の推測では、djbdnsはリリースされた時点でより優れていたと思われますが、今ではおそらく注目が集まっているため、bindの方が優れているでしょう。これはおそらく、「適切に構成されていない限り」バインドが安全でないという聴覚の原因です。少なくともこの問題を調査して理解する必要があります。このプロセスでは、おそらく両方のDNSサーバーに存在する構成リスクを見つけるでしょう。

負荷が大きい場合の動作は、ほとんどのユーザーにとってナンセンスな基準です。まれにパフォーマンスのボトルネックとなるソフトウェアを評価するための基準として使用されるパフォーマンスに注意してください。膨大なユーザーベースのキャッシュDNSサーバーをホストしていないため、かなりの割合でリクエストを受け取る可能性があります。おそらく同じシステムで実行されているサービスを提供するために、権限のあるDNSを実行しています。これらのサービスは、DNSの何千倍も高価です。インターネットリンクはDNSサーバーに大きな負荷をかけるには不十分な場合もありますが、提供するサービスにこのような大きな負荷がかかっている場合、DNSがボトルネックになることはほとんどありません。

セキュリティ対応のDNSサーバーであるMaraDNSをご覧ください。

• 安全。MaraDNSには、他のDNSサーバーと同等以上のセキュリティ履歴があります。たとえば、MaraDNSは、安全な乱数ジェネレーター、クエリID、およびDNSクエリのソースポートを使用して、常にランダム化しています。また、「新しい」キャッシュポイズニング攻撃に対して脆弱ではありませんでした。

• サポートされています。MaraDNSには、維持および更新の長い歴史があります。MaraDNSはもともと2001年に作成されました。MaraDNS1.0は2002年にリリースされ、MaraDNS 1.2は2005年12月にリリースされました。MaraDNSは引き続き完全にサポートされます。最新のリリースは2009年2月13日に行われました。MaraDNS2.0の一部となるコードであるDeadwoodは積極的に開発されています。

• 使いやすい。基本的な再帰構成では、3行の構成ファイルが1つだけ必要です。基本的な信頼できる構成に必要なのは、4行の構成ファイルと1行のゾーンファイルのみです。MaraDNSは、わかりやすいチュートリアルと完全で最新のリファレンスマニュアルの両方で完全に文書化されています。

• 小さい。MaraDNSは、サーバーが可能な限り最小限のリソースを使用する必要がある組み込みアプリケーションやその他の環境に適しています。MaraDNSのバイナリは、現在維持されている他の再帰DNSサーバーのバイナリよりも小さくなっています。

• オープンソース。MaraDNSは完全にオープンソースです。ライセンスは2条項のBSDライセンスで、FreeBSDライセンスとほとんど同じです。

選択に役立ついくつかのDNSサーバーソフトウェアの比較があるmaraDNSアドボカシーのページを参照してください。

自分でDNSを実行している場合は、djbdnsが優れたソフトウェアパッケージです。これは、昨年の主要なDNSセキュリティ問題を特定した数少ないソフトウェアパッケージの1つであり、数年前に修正/修正するためにビルド/パッチされました。DNSキャッシングの場合、権限のあるDNSサーバーとして実行されていないすべてのサーバーにdnscache（djbdnsの一部）をインストールします。ほとんどのアイテムではBINDよりも実際に機能しますが、今日のハードウェアを考えると、BINDの余分な重量と遅い速度は問題ではありません。

経験のために、実行するパッケージの選択に関係なく、BINDの基本を学びます。

Djbdnsは、コマンドラインから簡単に管理できるように設定されています。DNSデータに対するすべての変更は、コマンドとして実行されます。BINDでは、一連のテキストファイルを編集します。

両方のパッケージを入手できます。IEと他のブラウザーの違いを確認します。IEにはさまざまな機能が組み込まれていますが、デフォルトから変更することはありません。Djbdnsは異なり、異なるトレードオフのセットが必要です。ISPの場合、BINDからdjbdnへの移行は少し難しい場合があります。これは、デフォルトではBINDがキャッシングとネームサービスを行うためです。djbdnsはこれを2つの部分に分割します。これは望ましいセキュリティソリューションですが、セットアップが難しいため、多くのBINDインストールは気にしません。

個人的には、参考のためにBINDの基本を学ぶ必要があると思いますが、別のものに移行することで、将来のシステム管理者がより幸せになります:)

私がISP業界で働いたほとんどの場所はdjbdnを利用しているようです。それは優れたビルディングブロックと基盤を提供し、「マネージド」サービスを上に重ねます-ゾーンファイルを生成するスクリプトを書くのはとても簡単です。とにかくSQLで。1秒間に途方もない量のクエリを処理し、安全に起動できます。

スケールする必要がある場合は、http：//haproxy.1wt.euを覗いて、その背後にいくつかの信頼できるサーバーをポップしてください！また、展開することを選択したセットアップでは、信頼できるサーバーからリゾルバーを分​​割することを強くお勧めします。

読む価値のある他のことは、MaraDNSとPowerDNSです。

私は主にこの種のことのためにFreeBSDを使用しますが、BINDにバンドルされているので、他のことを学ぶ努力をしませんでした。しかし、BINDの設定は比較的簡単で、FreeBSDによってセキュリティの観点から維持されているため、セキュリティの問題についてそのチャネルを追跡するだけで済みます。

だから、あなたにとって最善の策は、両方を試して、どちらがあなたに最も適しているかを見ることだと思う。つまり、どちらかにバンドルされているOSを使用しない限り。

DNSについて学びたいなら、O'Reillyの本「DNS and BIND」とインストールされているbindの最新バージョンのコピーがおそらく最良の方法です。

BINDがその存続期間中により多くのセキュリティ問題を抱えていたことは事実です。dnjdnsには昨年まで何もありませんでしたが、BINDとは非常に異なるアーキテクチャを持っているため、ネーミングシステムの仕組みに慣れていない場合は、取り上げるのが難しいかもしれません。

DNS サーバーの実行方法（プロトコルなどの学習とは対照的に）の詳細を知りたい場合は、1つだけを選んで飛び込むことをお勧めします。両方のバイナリパッケージが見つかることを期待しています。選択した* nixディストリビューションで。そうは言っても、セキュリティの脆弱性が発表されている場合は、再構築する必要があるソフトウェアでソースからコンパイルすることにはいくつかの利点があります。

インターネットに接続するサービスと同様に、使用するソフトウェアに関係なく、常識と実用的な考え方が最善の方法です。動的更新を有効にする必要がある場合は、それらが署名されていることを確認してください。ゾーン転送を許可する場合、サーバーなどからゾーン転送を実行できるユーザーを制限します。

バインド。

（多少面倒なDNS関連のRFCを読みながら）構成方法を学習すれば、将来（別の目的のために）別のDNSサーバーに簡単に切り替えることができます。私はBINDをFreeBSD、Linuxのどこでもプライマリサーバーおよびセカンダリサーバーとして使用しています。また、Vistaラップトップ（VMware NATのホスト用）でも使用しています。

ところで、BINDのソースを読んで、たとえばgethostbyname（）やgethostbyaddr（）のような古典的な関数がどのように機能するかを知るのはちょっとした楽しみです。

バインドを何年も使用した後、ほとんどのサーバーで独自のDNSデーモンを実行する必要がないことが最終的にわかりました。これはあなたには当てはまらないかもしれませんが、考えてみてください。最近のほぼすべてのドメインレジストラは、DNSレコードをサーバーに提供することを提供しています（通常、WebベースでDNSレコードを編集する方法を提供します）。情報の提供、セカンダリの管理などを処理します。サーバーがDNSクエリに応答する必要がなくなった場合、サーバーがDNSルックアップを行うだけです。このため、私は/etc/resolv.confを4.2.2.1と4.2.2.2に向けます。これらはLevel3の「エニーキャスト」DNSサーバーであり、非常に高速で信頼性が高いようです。

追加のボーナスは、サーバーのファイアウォール構成でDNSを使用する必要がなくなったことです。サーバーのDNSクエリを機能させるには、「確立された、関連する」ルールに従う必要があります。

さて、DNSデーモンを実行する必要があるかどうかは尋ねませんでしたが、それが私が答えた質問です。完成させるために、実行する必要がある場合は、バインドを使用することをお勧めします。バインドは非常に一般的に使用されているため、多くのドキュメントがあり、必要な処理を行うのに役立ちます。