 :Visitor  :Unique visitor |
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
DNSサーバって、ただなんとなく公開しておくと外部からの攻撃を結構激しく受けます。なのでもし余裕があればサービス用と社内用のDNSサーバを分け、社内用DNSサーバ(正確にはDNSキャッシュサーバ。こちらを参照)にACL(Access Control List)をかけることをお勧めします。
bind8のACLのかけかた例
↓
acl ACLNAME {
xxx.yyy.zzz.aaa/24; ←社内ネットワークアドレスを記す
};
options {
directory "/etc/namedb";
version "";
allow-recursion {
ACLNAME;
};
};
またこちらを参照し、bindのログなんかも取っておくとよいかもしれません。
bindのログを残すためには、named.confに以下の内容を追加しましょう。
logging {
channel "log_default" {
file "/var/log/named.log" versions 7 size 10m;
severity info;
print-time yes;
print-category yes;
};
channel "log_security" {
file "/var/log/name_sec.log" versions 3 size 10m;
severity info;
print-time yes;
print-category yes;
};
category default { "log_default"; };
category security { "log_security"; };
};
DNSはUDP53番ポートを使うということを知っている人は多いです。しかし「ポートフィルタリング時UDP53番ポートさえ開ければよい」と思っているとしたら大きな間違いです。関連ドキュメントをよく読んでみると「受けはUDP53番だが、戻りはUDP1023番以降を使う」としっかり書いてあります。ファイアウォールを使うと戻りの部分はファイアウォールが勝手にやってくれるのでファイアウォール設定のベテランの方でも意外とこのことを知らない人も多いのではないでしょうか。
PS: こういうことがあるので、くどいですがドキュメントというのはしっかり読み込まないといけないです。ドキュメントを読まない人はこういうことに全然気づかないと思います。
DNSサーバは、メールサーバに並ぶくらい仕組みをよく理解されない状態で設定されて公開されてしまう場合が多いです。「とりあえず動いているからいいか」という妥協が良くないのは言うまでもありません。ということで今回はDNSサーバの正しい設定と構成について話しをしたいと思います。
【オリジンとキャッシュの違い】
DNSサーバにプライマリとセカンダリがあることはよく知られています。しかしオリジンとキャッシュという考え方を初めて聞く人も多いと思います。オリジンは管理しているサイトの情報を提供するサーバです。キャッシュはいわゆるキャッシュのサーバになります。
オリジンとキャッシュを分けるメリットは２点あります。一つ目は例えばDNSサーバにDoSアタックがあったとしてもオリジンサーバにまでそのアタックが及びません。二つ目はオリジンサーバに不正侵入されて情報が盗まれるというリスクが減ります。(ただしオリジンサーバは必ずプライベートIPにしておきましょう）
【forwarder設定の有無がなぜ重要か】
外部公開用DNSサーバとDNSオリジンサーバ共、管理しているサイトの情報だけ正引き・逆引きの情報を提供できれば十分です。forwarderというのは、問い合わせに対してサーバが情報を持っていない場合他のDNSサーバに代理で問い合わせをするという仕組みです。公開用DNSサーバにはforwarder設定は不要です。もしDNSサーバにforwarder設定をしてしまうと一般ユーザのPCのDNSサーバ設定に公開しているDNSサーバのIPアドレスを設定されてしまうかもしれません。そうなると余計なサーバ負荷やネットワーク帯域利用率が増えてしまいます。
【理想的なサーバ構成とforwarder設定】
お金に余裕があるサイトは次のようにサーバを構成するのがよいでしょう。(6台必要になります)
-----------------------------------------------------------------------------
・外部公開用DNSサーバ(forwarder設定なし)
【DNSプライマリ(キャッシュ)】 【DNSセカンダリ(キャッシュ)】
==================================================
・DNSオリジンサーバ(forwarder設定なし)
【DNSプライマリ(オリジン)】 【DNSセカンダリ(オリジン)】
==================================================
・社内利用用DNSサーバ(forwarder設定あり)
【DNSプライマリ(キャッシュ)】 【DNSセカンダリ(キャッシュ)】
-----------------------------------------------------------------------------
【forwarder実験】
実験してみましょう。まずはDNSサーバにforwarder設定をしていない適切な例を示します。
% nslookup www.yahoo.co.jp ns.hogehoge.co.jp
*** UnKnown can't find www.yahoo.co.jp: Query refused
% nslookup www.yahoo.co.jp ns.araara.co.jp
Name: www.yahoo.co.jp
Addresses: 210.81.150.5, 211.14.15.5, 202.229.198.216, 202.229.199.136
203.141.35.113, 210.81.3.241
【とはいいつつも】
とはいいつつも、DNSサーバのために６台もサーバを割けるサイトというのは少ないでしょう。一般的なのはオリジン、キャッシュ、社内利用を兼ねたDNSサーバを２台用意するというパターンです。これはこれでよいと思いますが、その構成だとサイトに大量アクセスがくるようになると危険が一杯だということだけ覚えて置いてください。
メールサーバ（SMTPサーバorMTAサーバと呼ぶのが正しい？）を稼動させるためにはDNSサーバの設定も必要になりますが、MXレコードの記述は必ずなされますが、逆引きの設定までは徹底されていないように感じます。そんなわけで、今回はメールサーバの逆引き設定をしてみましょう。
【なんで逆引き設定が必要なの？】
世界中を見渡すと、メールサーバの仕組みを全然理解しないでとりあえずどこかから設定例を入手して動かしてみて、とりあえず動いたからＯＫ，という安直な方法で本稼動させてしまっているシステム管理者が非常に多い気がします。でもまあそれは次の理由からなんとなく分かるような気がします。
①メールサーバを設定する機会は非常に少ない。
②接続する相手が千差万別なのでテストが難しい。
③メールの仕組み自体複雑で理解がしんどいのに、ただでさえ理解しにくいDNSの仕組みまで理解を要求されるのでますますしんどい。
要するに仕組みの理解が面倒くさい割には人生のうちでメールサーバを設定する機会なんてそう滅多にないので真剣に理解することよりもとりあえず動かしてしまって早くメールサーバ立ち上げの仕事から逃れたいという心理が働くのでしょう。
さて、なんで逆引き設定が必要なのかという本題に戻りますが、そもそもメールシステムの本質はSMTPサーバとSMTPサーバがTCPコネクションを張ってメールデータの受け渡しをするだけです。ここまでは簡単ですね。しかし時代と共にウィルスメールやSPAMメールが社会問題化してくると、問題のあるメールは受け取らないようにフィルタリングしてしまいたいというニーズが高まってきました。そこでいろいろなフィルタリングがメールサーバに施されてきましたが、その流れの中で「送信 IP アドレスからホスト名の逆引きができない場合に受信拒否する」実装を施したメールサーバが現れました。このメールサーバにメールを送っても逆引き設定をしていないと受信拒否されることが予想されます。
・・・とはいいつつも正直私はそのような実装が施されているメールサーバの名前を具体的に知らないんですよね。どなたがご存知でしたらコメントいただけると幸いです。それがわかれば、正引きと逆引きをぴったり一致させなければならないのか、それともとりあえず逆引き設定さえしておけばよいのか調べることができます。私はそのあたり不安なので今は正引きと逆引きをぴったり一致させています。
PS: メールサーバって自分の中では「SMTP/MTA」サーバのことを指しているのですが、一般的な概念としては「POP」も含まれるのでしょうか。POPが含まれるのであればIMAPやAPOPも含まれるのだろうか？？？メールシステムって本当に難しい！
ポートスキャンをかけると、bindについてもバージョン情報がバレバレです。こんな情報はクラッカーにとっては有用ですが、通常のユーザには全く不要なのでさっさと出ないようにしてしまいましょう。(ただbind自体セキュリティホールが多いので個人的には他のDNSサーバを使ったほうがよいとは思いますけど)
【やり方】
named.confというファイルに
「version "";」
を追加するだけです。
例：
options {
directory "/etc/namedb";
versioin "";
・
・
・
www.○○○.comというサイトがあったとします。このサイトをWEBブラウザーで開くとき
次のような打ち間違いをすることってよくありませんか？
http://○○○.com/
http://ww.○○○.com/
http://wwww.○○○.com/
http://w.○○○.com/
等々。
こういった打ち間違いに対応するために、以下のようにDNSを設定しておくと打ち間違い
にも対応した柔軟さを持たせることができます。
www IN A 10.0.0.10
IN A 10.0.0.10
w IN A 10.0.0.10
ww IN A 10.0.0.10
wwww IN A 10.0.0.10
※ただしCookiesを使っている場合はうまく動かなくなることがありますので注意してくださいね。
DNS障害はサービス停止を意味するくらい深刻なダメージを受けます。しかし世界中のサイトを見渡してみると、DNSを正しく運用できているサイトのほうが珍しいくらいめちゃくちゃな状態です。この原因は設定した内容が本当に正しいのか確認する術がなかったこと及びDNS設定を正しく紹介している文献が非常に少ないことによるものと思っております。そこで今回はDNS設定を正しく行うために便利なサイトをお伝えします。
【DNS設定が正しいか確認する】
DNS設定を行う際、なんとなく設定してなんとなく動いてることが確認できたら「設定完了！」と思ってしまうことが多いかと思いますが、多分それではだめです。DNS設定が正しいかを下記のサイトで客観的にチェックできますので是非一度お試しください。
【DNS設定を正しく行うために読んでおくべき文献】
DNS設定方法の情報ソースは各種文献やホームページ上にそれこそたくさん出回っておりますが、実際のところ、それらの情報のほとんどが間違っているか本質的な部分の記載が抜けています。
無論一番確実な情報はRFCなんですけど、それ以外の情報ソースをいろいろ探してみましたが、日本語でしたら下記のサイトの情報が一番信用できそうです(特にコンテンツサーバとキャッシュサーバを分離することの重要性についてはほとんどの情報ソースでは述べられてません)。
Recent Comments