スレーブ・サーバのゾーン転送とセキュリティ
規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。 今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。 コラム スレーブ・サーバとセカンダリ・サーバ 本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。 資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・
＠IT：DNS Tips：BINDのバージョンの問い合わせに別の応答文字列を返すには
BINDでversion.bindの問い合わせに対する応答文字列の変更が必要な場合があります。BINDのバージョンを公開すると、バージョン特有の脆弱性を外部から攻撃される可能性があるからです。意図的に外部からのバージョンの問い合わせに、別の応答文字列を返答するように設定しておくといいでしょう。 具体的な設定は、named.confファイルで行います。具体的には、リスト1に示すようにoptionsの中で返す文字列を設定します。 % dig @ns1.jprs.co.jp chaos txt version.bind ; <<>> DiG 8.3 <<>> @ns1.jprs.co.jp chaos txt version.bind ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
