djbdnsとbind
DNSネームサーバーの設定方法を学びたい初心者です。 djbdns、BIND、または他のものを使用する必要がありますか？
現在のネットワーク要件には、サブドメインのサポート、SSL、メールサービスなど、すべて非常に軽いトラフィックが含まれます。いつかトラフィックを増やして、場合によってはより複雑な要件（負荷分散など）にスケールアップできるソリューションが欲しいのですが。現時点では、Linuxで実行します。
BINDが適切に構成されていない場合、セキュリティの問題があり、その構成はトリッキーになる可能性があることを読みました。また、djbdnsの方が構成が簡単で、安全性が高く、負荷が高い場合と同等であることも読みました。 djbdnの議論はもっともらしいようですが、私はそれらを適切に評価する専門知識を持っていません。 BINDの方が優れている場合は、djbdnsに対するそれらの主張について議論していただければ幸いです。
ありがとう。
私は過去にdjbdnsを使用しており、現在は多数のBINDサーバーを実行しています。
Djbdnsの最大の問題は、1年生の先生が私のレポートカードに「他の人とうまくいかない」という表現をすることです。それは単にあなたを後で噛むことができるあらゆる種類の非常に小さな方法でUNIXボックス上で他のどのようにも動作しません。これは、他では見られないゾーンファイルの構文を使用します。
Djbdnsの最大の利点は、セキュリティを最初の目標として最初から設計されたことです。
DNSサーバーをセットアップし、インターネットに公開し、それを維持しない場合は、djbdnsが適しています。
現実の世界では、ほとんどの管理者はOSベンダーのBINDパッケージを使用し、更新があった場合はすぐにパッチを適用する方がよいでしょう。しかし、それをchrootして実行することは良い考えであり、信頼できるDNSサーバーを再帰リゾルバーDNSサーバーから分離しておくことは良い考えです。
DNSを使用したドキュメントが見つかった場合、BINDが含まれ、djbdnsは含まれそうにありません。 Digを使用する場合、返される形式をBINDゾーンファイルに貼り付けて機能させることができます。他の惑星のものではなく、通常のUNIXデーモンのように動作します。
一部のハードウェアロードバランサーを使用して、再帰リゾルバーBINDサーバーの負荷を分散しています。よく働く。ユーザーがリクエストを送信したときと同じソースIPを取得し、UDPとTCP=可能なロードバランシングのセットアップが機能することを確認してください。信頼できるDNSを実行している場合、ロードバランシングは簡単です。複数のサーバーがあり、それらすべてをwhois情報で公開しているため、他のDNSサーバーはインテリジェントに負荷分散します。
それが自分のためであり、DNSのしくみを知りたい場合は、djbdnsを使用します。
他の全員がDNSをどのように使用しているか、および一般的なエンタープライズ展開をサポートする方法を理解したい場合は、バインドについて学習します。
目標が最小限の労力とサポートであり、十分な能力がある場合、djbdnsのサポートオーバーヘッドははるかに低くなります。
フェンスの初心者の方が多い場合は、バインドして実行するのが簡単になりますが、奇妙で奇抜な方法で爆発する可能性がはるかに高いことに注意してください。
Djbdns（およびバインド）をまだ知らなかった場合は、powerdnsとmaradnsも調べますが、小さなインストールの場合、djbdnsスイートよりも優れているとは思えません。
とにかく、DNSをインターネットにアドバタイズするためにbindを使用する場合でも、システムのリゾルバーのlocalhostで実行されているdnscache（djbdnsスイートの一部）を実行する必要があります。
Djbdnsをスキップします。 djbはヒーローですが、数学者の傲慢さをソフトウェアに引き継いでいます。起動/停止に関して他のソフトウェアのように動作しないという事実は、デーモンを管理する巧妙な手法の良いデモンストレーションかもしれません。しかし、すべてを非常に異なっているので、定期的に使用しない場合は、ドキュメントを引き出す必要があります。他の人も維持しているシステムに設定する場合は、明確なドキュメントを書く必要があります。簡単な操作を行うには、ドキュメント全体を読む必要があります。 initからの実行は、賢くさえもかわいいです。しかし、それはまた不愉快で、驚くべき、そして非標準的です。
また、私はdjbdnsで問題を抱えており、ソフトウェアの相互運用性ではなく、標準のみを尊重することに固執するために深刻な問題を引き起こしています。これらの問題のトラブルシューティングは、DNSパケットのわずかな違いに依存していたため、時間の無駄でした。
また、場合によっては、djbdnsが奇妙な動作をするため、djb以外のツール（nslookupなど）を使用してDNSサーバーをトラブルシューティングすると、驚くべき結果が得られます。 「実際には、私はdjbdnsと呼ばれるこのあいまいなDNSサーバーを使用しています。問題は、診断ツールが奇妙なメッセージを表示していることですが、正常に機能しています。このパケットキャプチャを見ると、 。これは、djbdnsがDNSサーバーと正しく相互運用していなかった数か月前に発生した問題とは関係ありません。また、私が不在で、それが原因で数週間前に発生した問題とも関係ありません。チームメイトがDNSサーバーを再起動するのに1時間かかります。」
Qmail全体で同様の問題。
あなたが質問をしていて、殺す時間があるならば、djbdnsを設定することにいくらかの教育的価値があります。また、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は、SQAプロセスと4年以上の実際の使用の両方で広範囲にテストされています。 MaraDNSは引き続き完全にサポートされています。最新のリリースは2009年2月13日に行われました。MadeDNS2.0の一部となるコードであるDeadwoodは活発に開発されています。
使いやすい。基本的な再帰構成には、3行の構成ファイルが1つだけ必要です。基本的な信頼できる構成には、4行の構成ファイルと1行のゾーンファイルのみが必要です。 MaraDNSは完全に文書化されており、わかりやすいチュートリアルと完全で最新のリファレンスマニュアルの両方が用意されています。
小さい。 MaraDNSは、サーバーが可能な限り最小限のリソースを使用する必要がある組み込みアプリケーションやその他の環境に適しています。 MaraDNSのバイナリは、現在維持されている他の再帰DNSサーバーよりも小さくなっています。
オープンソース。 MaraDNSは完全にオープンソースであり、ライセンスはFreeBSDライセンスとほぼ同じ2条項のBSDライセンスです。
maraDNS advocacy のページを参照してください。ここでは、選択に役立つ可能性があるいくつかのDNSサーバーソフトウェアの比較があります。
DNSを自分だけで実行している場合は、djbdnsがより優れたソフトウェアパッケージです。これは、昨年からの主要なDNSセキュリティ問題を特定し、数年前に修正するためにビルド/パッチされた数少ないソフトウェアパッケージの1つでした。 DNSキャッシングでは、権限のあるDNSサーバーとして実行されていないすべてのサーバーにdnscache（djbdnsの一部）をインストールします。ほとんどのアイテムでBINDよりも実際にうまく機能しますが、今日のハードウェアを考えると、BINDの余分な重量と遅い速度は問題になりません。
経験上、どのパッケージを実行するかに関わらず、BINDの基本を学びます。
Djbdnsは、コマンドラインから管理しやすいように設定されています。 DNSデータへのすべての変更は、コマンドとして行われます。 BINDでは、一連のテキストファイルを編集します。
両方のパッケージを取得できます。 IE対他のブラウザとの違いを私は見ています。IEは組み込みで多くのことに機能し、デフォルトから変更することはありません。Djbdnsは異なり、トレードオフの異なるセットを必要とします。ISPの場合、BINDからdjbdnsへの移行は少し難しい場合があります。これは、BINDがデフォルトでキャッシングとネームサービスを行うためです。djbdnsはこれを2つの部分に分割します。 、しかしセットアップが難しいので、多くのBINDインストールは気にしません。
個人的には、参考のためにBINDの基本を学ぶ必要があると思いますが、何か他のものに移動すると、将来のシステム管理者がより幸せになります:)
私がISP業界で働いたほとんどの場所はdjbdnsを利用しているようです。それは、「管理された」サービスを上に重ねるための優れたビルディングブロックと基盤を提供します-ゾーンファイルを生成するスクリプトを書くのは非常に簡単です。つまり、すべてのDNSデータを保存できますとにかくSQLで。 1秒あたりのとんでもない量のクエリを処理し、起動しても安全です。
スケーリングする必要がある場合は、 http://haproxy.1wt.e を確認し、その背後にいくつかの信頼できるサーバーをポップしてください。また、展開することを選択したセットアップでは、信頼できるサーバーからリゾルバーを分割することを強くお勧めします。
他に読む価値のあるものは、MaraDNSとPowerDNSです。
私は主にこの種のものにFreeBSDを使用しており、BINDにバンドルされているため、他のことを学ぶために努力することはありませんでした。ただし、BINDの設定はかなり簡単で、FreeBSDによってセキュリティの観点から維持されているため、セキュリティ上の問題がないかどうかチャネルを追跡するだけで済みます。
ですから、あなたにとって最善の策は、両方を試して、どちらが最も適しているかを確認することです。つまり、どちらかにバンドルされているOSを使用する場合を除きます。
DNSについて学習したい場合は、O'Reillyの本 " DNS and BIND "と最新バージョンのbindがインストールされているのがおそらく最良の方法です。
BINDの存続期間中に、より多くのセキュリティ問題があったことは事実です。 dnjdnsには昨年まで何もありませんでしたが、BINDとはアーキテクチャが大きく異なり、ネーミングシステムの仕組みに慣れていないと、入手しにくい場合があります。
DNSserverを実行する方法（プロトコルなどについて学習するのではなく）について学習したいだけの場合は、どちらかを選択して飛び込みます。選択した* nixディストリビューションに両方のバイナリパッケージが見つかると思います。そうは言っても、セキュリティの脆弱性が発表された場合に再構築が必要になる可能性があるソフトウェアをソースからコンパイルすることにはいくつかの利点があります。
他のインターネット向けサービスと同様に、使用するソフトウェアに関係なく、常識と実用的な考え方が最善の方法です。動的更新を有効にする必要がある場合は、それらが署名されていることを確認してください。ゾーン転送を許可する場合は、サーバーからそれらを実行できるユーザーなどを制限します。
練る。
（やや面倒なDNS関連のRFCの束をすべて読みながら）構成方法を学習する場合は、将来、（目的を問わず）別のDNSサーバーに簡単に切り替えることができます。 FreeBSD、Linux、さらにはVistaラップトップ（VMware NATのホスト用）の至る所で、プライマリサーバーとセカンダリサーバーとしてBINDを使用しています。
ところで、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デーモンを実行する必要があるかどうか尋ねませんでしたが、それは私が答えた質問です。完全にするために、1つを実行する必要がある場合は、bindを使用することをお勧めします。bindは非常に一般的に使用されているため、多くのドキュメントが見つかり、必要なことを実行するのに役立ちます。