|
DNSサーバーの設定 |
2010年7月4日(日) | 2010年7月9日(金)更新 |
DNS(Domain Name Server)を構築してアドレス解決の高速化をはかるとともに、自分のサーバーのドメイン公開を行います。 |
概要
他のドメインのIPアドレスを得るリゾルバ(resolver)として、また自分のドメインを公開するいわゆるDNSとして使用します。
リゾルバとしての機能は初回はプロバイダーのDNSのほうが速いのですが、2回目以降はサーバー内DNSが圧倒的に早くなります。
インストール
bind-utilsにはdig, host, nslookupなどのネームサービス関係のコマンド実行ファイル等が収められています。
resolver設定
CentOSのnamedはchroot環境で動いているようです。で、
基本設定ファイルは /var/named/chroot/etc/named.conf
ざっと見てみますとすでに基本的な設定はされているようです。
ためしにこのまま起動してみます。
#service named start ⇒ OKとなり無事起動
digコマンドで応答速度を見てみます。
#dig @localhost kuragane.jp
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @localhost kuragane.jp
; (1 server found)
........
;; Query time: 720 msec
........
2回目
........
;; Query time: 1 msec
........
#dig @203...(プロバイダーDNSアドレス) kuragane.jp
........
;; Query time: 142 msec
........
2回目
........
;; Query time: 37 msec
........
1回目プロバイダーのDNSが早いのはたぶん専用マシンであることやインターネット回線の速度の差でしょう。
ただブラウザを使うと体感的には内部DNSを使った方が相当早く感じられます。おそらく1ページを表示するのに画像などにアクセスする都度DNSを参照するのでしょう。
メニューの 管理 ⇒ ネットワーク で DNSの1番目を 127.0.0.1に。
起動時に開始するように起動設定。
#chkconfig named on
ブラウザで各サイトを開いてみると立ち上がりが格段に早くなった気がします。ステータスバーに表示される「....のアドレス解決をしています」の文字はほとんど見えません。
ということで第一段階は10分で完了。
このページを書いている時間のほうがはるかに長い!みんなこうだといいんだけど。
ロギングの設定
ログをとる設定をします。
named.conf の最初のほうに以下を書き込みます。(optionsの前) // loggingは最初に書く! これを読み込む前の処理はログされない。で、/var/named/chroot/var/にlog/namedというディレクトリをつくり、namedの所有者をnamedにし、書き込み権限を付与。(現行サーバーのログの場所 /var/log/named に合わせた。) #service named restart したところログファイルが作成されず、さらにSELinuxさんに権限がないとおこられました。(モードはpermissiveにしてあったんだけど。) |
ログファイルが作られました。見ると起動の様子が記録されています。
ディレクトリ/var/named/chroot/var/log/namedへのリンクを/var/logにおいておきます。
さらにブラウザ(Firefox)を起動、ホームページ(http://www.google.co.jpにしてある)を表示してからログを見ると、なんと50個近いクエリーが発行されています。
よくよく見るとこれらはホームページにあるリンクやツールバーのリンクです。さらに半分はipv6で、しかもipv4より先に発行されています。DNS先読み機能というやつらしいです。それでDNSが遅いとページ表示も遅くなっちゃうのかな。
/etc/loglotate.d/named も確認し、多少変更しておきます。
missingok
notifempty …追加
create 0644 named named
postrotate
/sbin/service named reload 2> /dev/null > /dev/null || true
endscript
}
error: the working directory is not writable
とあります。安全のためにわざとそうしているのか、設定ミスなのかよくわかりません。
working directory に設定した /var/named/chroot/var/named にgroup named の書き込み権限を与えておきます。これでいちおう上記のエラーは出なくなりました。
が、またSELinuxさんにおこられます。しょうがないので、setroubleshootで言っている「アクセスを許可」のコマンド restorecon .... を実行。
それからこのエラーは出なくなりましたが、めんどいな。
動作の設定
多少付け加えます。
options {
........
allow-recursion { localhost; localnets; }; //resolverの使用は内部のみに。
max-cache-size 10485760; //DNSキャッシュを10MBに制限。ディフォルトは無制限。
notify no;
allow-notify { none; };
allow-transfer { none; };
forward first; // まずはプロバイダのDNSサーバーに問い合わせる。少し速い。
forwarders {
203.141.xxx.xxx; …プロバイダのDNSサーバー
203.141.xxx.xxx;
};
........
}
allow-recursion はプロバイダーと同じDNS機能を公開する必要もないので。
max-cache-size は単に念のためといったところ。
forwardは結局最初はプロバイダのDNSを使い、キャッシュされたあとは自前DNSを使うのが総合的に一番速いようなので....。
こんなところかな。
自前zoneの設定ホストするドメインがあれば、そのzoneファイルを作ります。 /var/named/chroot/var/named/iroribata.org.zone.master ; iroribata.org (zone master) |
続いてnamed.confにmasterとslaveのzone定義を記入。 // iroribata.org (master) |
こうすることによって、メインサーバーとバックアップサーバーを入れ替えたときにすぐにmasterとslaveを入れ替えられます。
zoneがたくさんある場合はそれぞれ別のファイルに書いておき、includeで入れ替えてもいいかと。
他方のnameserverにも同様の設定をしておきます。
namedを再スタート。
#service named restart
ログを見てエラーのないのを確認。OK。
ファイアウォールの設定と再起動
/etc/sysconfig/iptablesに追加。
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
完了です。
SPFレコードの追加
迷惑メールやなりすましメールの防止判定用です。
これをやらなかったからと言って今のとこメールが送れないわけではありませんが、将来に向けてと、あと誰かがこちらのメールアドレスを詐称した場合(スパムメールでは実際に送信者にもこちらのアドレスが使われることがよくある!)、それを検知してもらえるようにするためです。
SPFレコードというのをメールアドレスに使うドメインに追加します。
こちらのメールサーバーのIPアドレスは 219.117.195.47 ですが、バージョン1とバージョン2の両方の記載をしておきます。
別にそれほど難しいものでもなく、メールはipv4で219.117.195.47のアドレスから発信、それ以外からは発信しないよという情報です。
IN TXT "v=spf1 ip4:219.117.195.47 -all"
IN TXT "spf2.0/pra,mfrom ip4:219.117.195.47 -all"
を zone master ファイルに追加します。
上記の /var/named/chroot/var/named/iroribata.org.zone.master は
; iroribata.org (zone master)となります。これだけ。あとは、 # service named restart してOK。 |