倉金家ホームページ趣味の部屋/サーバー構築メモ その2
| ||||||
概要現行のサーバーではDNSとしてBIND9が動いています。
他のドメインのIPアドレスを得るリゾルバ(resolver)として、また自分のドメインを公開するいわゆるDNSとして使用します。 リゾルバとしての機能は初回はプロバイダーのDNSのほうが速いのですが、2回目以降はサーバー内DNSが圧倒的に早くなります。 | ||||||
インストールすでにCentOSインストールの際、bindおよびbind-utilsを入れてあります。バージョンは9.3.6です。
bind-utilsにはdig, host, nslookupなどのネームサービス関係のコマンド実行ファイル等が収められています。 | ||||||
resolver設定まずはリゾルバとしての設定をおこないます。
CentOSのnamedはchroot環境で動いているようです。で、 基本設定ファイルは /var/named/chroot/etc/named.conf ざっと見てみますとすでに基本的な設定はされているようです。 ためしにこのまま起動してみます。 #service named start ⇒ OKとなり無事起動 digコマンドで応答速度を見てみます。 #dig @localhost kuragane.jp 1回目 同様のことをプロバイダーのDNSでやってみます。; <<>> 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 1回目 いったんキャッシュされてしまえば内部DNSの方がはるかに早い。........ ;; 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を見ますとログをとる設定にはなっていません。初期段階、特に設定が完了するまでは簡単にでもログをとって確認する必要があります。
ログをとる設定をします。 | ||||||
| ||||||
setroubleshootブラウザの指示どおり、setsebool .... を実行し設定を行いますと今度はOK。
ログファイルが作られました。見ると起動の様子が記録されています。 ディレクトリ/var/named/chroot/var/log/namedへのリンクを/var/logにおいておきます。 さらにブラウザ(Firefox)を起動、ホームページ(http://www.google.co.jpにしてある)を表示してからログを見ると、なんと50個近いクエリーが発行されています。 よくよく見るとこれらはホームページにあるリンクやツールバーのリンクです。さらに半分はipv6で、しかもipv4より先に発行されています。DNS先読み機能というやつらしいです。それでDNSが遅いとページ表示も遅くなっちゃうのかな。 /etc/loglotate.d/named も確認し、多少変更しておきます。 /var/log/named/named.log { 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 .... を実行。 それからこのエラーは出なくなりましたが、めんどいな。 | ||||||
動作の設定まずはresolverとしての設定ですが、すでに問題なく動いています。
多少付け加えます。 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を使うのが総合的に一番速いようなので....。 こんなところかな。 | ||||||
| ||||||
| ||||||
masterとslaveの両方を書いて片方を/* */で無効にしておきます。
こうすることによって、メインサーバーとバックアップサーバーを入れ替えたときにすぐにmasterとslaveを入れ替えられます。 zoneがたくさんある場合はそれぞれ別のファイルに書いておき、includeで入れ替えてもいいかと。 他方のnameserverにも同様の設定をしておきます。 namedを再スタート。 #service named restart ログを見てエラーのないのを確認。OK。 ファイアウォールの設定と再起動 /etc/sysconfig/iptablesに追加。 -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT #service iptables restart-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 は | ||||||
| ||||||