text
DNSサーバーの構築
DNSサーバーの構築と活用
1.DNSサーバーとは
DNSとは「Domain Name System」の略で、IPアドレスとホスト名を相互変換してくれるサービス。インターネット、イントラネットに関わらずTCP/IPベースのネットワークでは、パソコンやサーバーからスイッチ、ルーター、プリンタといったネットワーク機器まで、ネットワークに接続して稼動させる機器にはそれぞれネットワーク上での個体識別のためにIPアドレス(例:172.168.140.1)が割り振られることになっている。ネットワークに接続されたコンピュータはお互いのIPアドレスを送信先に指定して通信を行っている。
IPアドレスはは0〜255の数値を4つ、ピリオドで区切って並べて表記するが、コレは人間にとっては覚えやすいものではない。コンピュータの役割に応じた名前(=ホスト名)ならば、人間は非常に覚えやすくなる。そこで、ホスト名でアクセスできるようにホスト名とIPアドレスとの対応表が作られるようになった。コンピュータネットワークの黎明期ならば数が非常に少数なため、手作業による作業で十分可能だが、現代のようにコンピュータネットワーク全盛の時代では手作業による対応表のメンテナンスは到底不可能になる。そこで、IPアドレスとホスト名とを自動変換する仕組みが考案され、処理を階層化するとともに分散型データベースとしてDNSという仕組みが実装され現在に至る。
2.本実習の目的
インターネット上では、FQDN(Fully Qualified Domain Name)からIPアドレスを取得するDNSが広く利用されている。
DNSはホスト名とIPアドレスとの対応を提供するDBだが、他のサーバーと連携して規模が大きい点やデータベースを提供する範囲をネットワークごとに指定できるなどの特徴がある。この実習ではDNSソフトウェアの代表であるBINDの設定を利用方法に応じて学習する。
3.DNSの仕組み
図のように、DNSはIPアドレスとホスト名を対応させるデータベースを持っている。端末からのホスト名に対するIPアドレスの問い合わせが発生した際に、DNSは自身のDBに登録されているリストの中から対応するIPとホスト名の組み合わせを探し出し、問い合わせてきた端末に対して結果を送り返す。
仮に世界中にネットワークに接続した機械が1億台あったとすると、DNSは1億台分のIPアドレスとホスト名の対応情報が登録されていればよい。
では、1億台分のリストはどのように得られるのだろうか?
すべての、IPアドレスとホスト名の対応表をDBに持っているDNSが世界に1台あればよいというわけではない。その方法では、山のようにあるIPやホスト名の対応情報を漏れなく登録することは実質不可能になる。この問題を解決する手法としてDNSのリゾルバ機能だ。
今、クライアントが“juppiter.sentan-college.ac.jp”にアクセスしたいと思った場合、ネットワークのトポロジー上1番近いDNSに問い合わせをかけるのだが、そのDNSが必ずしも“juppiter.sentan-college.ac.jp”を知っているとは限らない。このような場合、ローカルDNSはまず「ルートサーバー」と呼ばれるサーバー(これは世界に13台あります)に問い合わせを掛けることになっている。ルートサーバーは、“juppiter.sentan-college.ac.jp”の最後の“jp”に着目し、“.jp”というトップドメインを管理しているDNSのIPアドレスを返してくる。そこでローカルDNSは次に“.jp”を管理しているサーバーにリクエストを出すと、“ac.jp”を管理しているサーバーのIPアドレスが返ってきます。3度目は“ac.jp”を管理しているサーバーにリクエストを出し、“sentan-college.ac.jp”を管理しているサーバーのIPを得るわけで、4度目にはついに“juppiter.sentan-college.ac.jp”のIPアドレスを得ることができ、これがクライアントに返ってくる。

実は、DNSの処理の仕組みは、拠点から中枢に向かって処理を集めて一括処理を行い、結果を拠点に返すという旧来の日本型の一括集中処理を行っている。
この方式により、DNSは自分が知らないホストのIPアドレスも、問題なく取得できるようになっている。基本的にルーサーバーに向けてDNSは問い合わせをしているのだが、いっせいに世界中からルートサーバーに向けて問い合わせが発生したら、たった13台しかなくともルートサーバー処理する。DNSは分散してIP-ホスト名の情報を持っているが、最終的にはルートサーバーが問い合わせに対して返答しているので、負荷分散ではない。
上記でも述べたように、ルートサーバーへの負荷はそれなりに大きい。そこでDNSサーバーは一定期間ならば、1度問い合わせた結果はキャッシュに格納することでルートサーバーへの不用意なトラフィックを増やさない、という工夫(=DNSラウンドロビン)でルートサーバーへの負荷軽減を実施している。
例えば、クライアントが“mercury.sentan-college.ac.jp”をリクエストするたびに、もう1度ルートサーバーからアクセスしなおすのは無駄だ。そこで1回目に“sentan-college.ac.jp”ドメインから“mercury.sentan-college.ac.jp”の IPアドレスを取得した際に、“mercury.sentan-college.ac.jp”=“210.173.173.66”を自分のキャッシュに蓄えておき、2 度目以降はこのキャッシュをみて即座にクライアントにIPアドレスを返すという仕組みが備わっている。もちろんこのキャッシュの仕組みはDNSのみならず、クライアント側でも有効となっている。
ただし、キャッシュの場合は適当な頻度で更新をかけないと、データが変わっている場合がある。DNSでは、値を返す際にその値の有効期限(TTL:Time To Live)も一緒に返しており、値を取得してからTTLに定められる時間が経過したあとは、キャッシュをいったん破棄してもう1度サーバーから最新の値を取得することが必要とされている。

一般的に、サードレベルのドメイン(=sentan-college)は基本的に組織単位で持つ。組織内のDNSとは、1つのDNSの中にキャッシュサーバーとドメインサーバーとがある。キャッシュサーバーは内部のネットワークからのリゾルバによって組織外のDNSへ問い合わせる。ドメインサーバーは組織外からの問い合わせに返答する、というように明確に分かれている。組織内のDNSリゾルバの処理をしたいだけならば、キャッシュサーバーだけで十分、ということもありうる。
リゾルバ(resolver)とは、ドメイン名を元にIPアドレスの情報を検索したり、IPアドレスからドメイン名の情報を検索する、といった名前の解決(name resolution)を行うプログラムのことをを示す。ネームサーバがDNSの情報提供を担う側であるのに対し、それを利用してドメイン名から必要な情報を解決(resolve)する側になる。リゾルバには「フルサービスリゾルバ (Full-Service Resolver)」と「スタブリゾルバ(Stub Resolver)」があるが、単に「リゾルバ」と呼んだ場合には、「スタブリゾルバ」を一般的に指す場合が多い。スタブリゾルバは、利用者から出される要望を元に、端末側で動作する検索プログラムに該当する。
Webブラウザやメールソフトでドメイン名を入力する場面では、そのアプリケーションは、実際に通信を行うサーバのIPアドレスを調べるために、スタブリゾルバを呼び出す。スタブリゾルバはフルサービスリゾルバとの橋渡しとして動作し、調べたいドメイン名に関して再起検索をしてもらい情報を得る。
スタブリゾルバは、フルサービスリゾルバやコンテンツサーバとは異なり、単独の名前の付いたプロセスではない。関数やライブラリとしてOSから提供されることが多い。Windowsの「TCP/IP のプロパティ」や UNIX 系OSの/etc/resolv.confにネームサーバのIPアドレスを指定する箇所があるが、これはスタブリゾルバの動作を制御するもので、交信するフルサービスリゾルバを指定している。
ネームサーバは、以下の3つの働きが組み合わされてる。
コンテンツサーバ(Contents Server)
自分が管理しているゾーンに対する問い合わせだけに回答する。名前解決ができなくてもほかのネームサーバへの問い合わせはせず、自らが管理しているデータベースに該当する情報がなければ「情報はない」と答える。
フルサービスリゾルバ(Full-Service Resolver)
スタブリゾルバから送られる「再帰(Recursive)検索」要求を受け、名前解決が完了するまで、それぞれの名前についてほかのネームサーバに「反復(Iterative)検索」という形で問い合わせをする。また、その結果をスタブリゾルバに返答する。
このとき、同じ問い合わせを何度も繰り返すという非効率を避けるため、一度名前解決をしたドメイン名を内部にキャッシュして再利用することから「キャッシュサーバ」とも呼ばれる。最近では、こちらの呼び名の方が出現頻度は高くなっている。
スタブリゾルバ(Stub Resolver) 利用者側から出される要望を基にフルサービスリゾルバと交信し、調べたいドメイン名を渡して必要な情報を教えてもらう、端末側で動作する検索プログラム。単に「リゾルバ」と呼ばれることもある。
4.サーバー構築の手順
(1)IPアドレスと名前解決の方法
/etc/hostsファイルとDNS
DNSの必要性
(2)ネットワークの構成とDNSのカバー範囲
ネットワークの公開範囲の確認
DNSでカバーする範囲の確認(外向けのみか、外と内の両方か)
キャッシュサーバー
(3)DNSの設定
/etc/named.conf
/var/named/named.ca ・・・ ルートサーバーの設定ファイル
localhost.zone ・・・localhostの正引きファイル
named.local ・・・ localhostの逆引きファイル
※
正引きゾーンファイル ドメイン名 -> IPアドレス
逆引きゾーンファイル IPアドレス -> ドメイン名
FedoraCoreではchrootにより、/etc/named.confや/var/named/下のファイルはシンボリックリンクファイルである。実際のファイルはより下の/var/named/chroot/etc/や/var/named/chroot/var/named/直下にある。
従来のUNIXやそのクローンOSでは/var/named/直下に実体のファイルが収められていてそれを編集する。なぜ、FedoraCoreはこのようなことをするのか、と云うと、従来とはパスを変えて第三者に分かりにくくするセキュリティ対策である。
(4)サービスの起動と停止
ex)
#service named start |
(5)DNSの動作環境
ローカルホストでのDNSの動作確認テスト
/etc/juppiter.sentan-college.ac.jp
クライアントテストWindowsネットワーク設定(TCP/IP)でのDNS設定に相当
※ 本実習でのドメイン名はsentan-college.ac.jpとします。
5.BINDの基本設定
DNS(Domain Name Service)はIPアドレスとホスト名とを相互に変換するデータベースでドメインネットワーク内のIPとホスト名との対応を管理している。UNIXやUNIXクローンOSの多くで利用されるDNSはBIND(Berkley Internet Name Domain)というインターネットの世界では最も多く利用されている。いわばデファクトスタンダードだ。いかに、Microsoftが物量戦を仕掛けてこようとも、ネットワークの創世記からインターネットの隆盛とともに成長を続けてきたBINDには導入実績や信頼性ではかなうものではない、というのが現状だ。
本実習実習環境のFedoraCoreに含まれるバージョンはBIND9であり、BIND8と比較してもセキュリティ面が大幅に強化されたものとなっており、IPv6にも対応している。
一般にBINDの設定すべきファイルは
・/var/named/chroot/etc/named.conf
・/var/named/chroot/var/named/直下の
正引きゾーンファイル(ホスト名 -> IPアドレス)
逆引きゾーンファイル(IPアドレス -> ホスト名)
正引きループバックファイル
逆引きループバックファイル
■hostsファイル
DNSの原型となるプレーンテキストファイルで、1行ごとに名前解決を定義する。hostsファイルはlocalhost内でのみ名前解決に利用できる。したがって、hostsファイルでLAN内の名前解決をしたいときはLAN内のすべての端末及びサーバーに同じ内容のhostsファイルを用意する必要がある。
#vi /etc/hosts |
host.confファイルはlocalhost内での名前解決に利用する仕組みの優先順位を指定する。
# vi /etc/host.conf order dns,hosts |
■DNSクライアント
LinuxをDNSクライアントとして利用する場合には、設定ファイル/etc/resolve.confにDNSサーバーのIPアドレスを設定する。
(設定例)
search dmz.sentan-college.ac.jp
nameserver 172.18.140.1
■プライマリDNSサーバ-の設定
DNSサーバーは、同一ドメイン内にマスターサーバーと、スレーブサーバー(=バックアップ用)を用意するのが通例で、スレーブサーバーは何台あってもかまわない。
実際、マスターサーバーにLAN内のDNSを指定し、スレーブサーバーにプロバイダのDNSを指定することも多い。
6.named.confの設定
ここからは、いよいよDNSの設定に関わる設定ファイルを変更していく。
■/var/named/chroot/etc/named.confの設定
UNIXやFedoraCore以外UNIXクローンOSでは/etc/named.confに相当するが、OSに標準で用意されているnamed.confの内容を以下に示す。ちなみに、FedoraCoreでは標準でIPv6対応に関するzoneの記述部分が追加されているので、自身でDNSサーバーを建てるときに参考にするとよいだろう。
(named.confのデフォルトの記述)
// |
DNSサーバーの設定時に施すnamed.confファイルへの変更はゾーンファイル記述の追加だ。
ゾーンファイル記述はnamed.confの末尾、zone "0.in-addr.arpa" IN {のコードブロックの末尾と};include "/etc/rndc.key";の間に行を挿入し、記述する。
(記入例)
zone "dmz.sentan-college.ac.jp" IN{ |
ゾーン名称はDNSサーバーが所属するネットワークに対応した正しい名称を設定する。対応するゾーンファイル名は/var/named/chroot/var/named/(※通常のUNIXやそのクローンOSの場合は/var/named/)下に存在するファイル名であれば何でもよい。ただし、そのファイルが正引きなのか逆引きなのか分かるものにしてあることが好ましい。一般的には正引きファイルは*.zone(例:dmz140.sentan-college.zone)、逆引きファイルは*.rev(例:dmz140.sentan-college.rev)、といったファイル名が好まれる傾向にある。
■/named.confの内容
上記で紹介したnamed.confのそれ以外の記述の注目点について解説する。
まず注目するのは、5-6行目の記述。
options { |
ここでは、/var/named/chroot/var/named/のシンボリックファイルである/var/named/を指定する。
FedraCore以外のUNIX及びクローンOSでは、/var/named/は実体のファイルの収められているディレクトリである。FedoraCore以外のOSとの互換性の記述とも考えられる。
次に、19-20行目の記述
forwarders{172.18.0.1;}; |
これは、DNSの問い合わせ先(->再帰問い合わせをして、リカーシブを返してもらうDNS)のIPで、この設定ファイルを記述しているサーバーがスタブサーバーのときは必ず書く。
29行目の記述。
zone "." IN { |
コレは、ルートサーバーの情報を参照することを示している。
31行目の記述。
file "named.ca"; |
これは、外部のDNSへの問い合わせは、RootServerに問い合わせるという意味。named.confを記述しているサーバーがスタブサーバーの時にはコメントアウトするか書かない。そうでなければ、必ず書くことが必須である。
34行目の記述。
zone "localdomain" IN { |
コレは、ローカルホストの正引きを示している。
40行目の記述。
zone "localhost" IN { |
コレは、IPV6用のローカルホストの正引きを示している。
46行目の記述。
zone "0.0.127.in-addr.arpa" IN { |
コレは、ローカルホストの逆引き。
52行目の記述。
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN { |
コレは、IPV6用のローカルホストの逆引き。
58行目の記述。
zone "255.in-addr.arpa" IN { |
コレは、ブロードキャストの逆引き。
64行目の記述。
zone "0.in-addr.arpa" IN { |
コレは、ネットワークアドレスの正引き。
■ゾーンファイルの設定
FedoraCoreのゾーンファイルの実体は、/var/named/chroot/etc/var/namedに作成され、/var/namedにそのシンボリックリンクを作成するようになっている。
ゾーンファイルにはそれぞれレコードが定められていて、DNSのサービスを提供している。下記にそのレコードとその役割について説明する。
SOA(Start Of Arthority) ・・・ ゾーンデータベースの最初に記述する。
NS(Name Service) ・・・ ゾーンを管理するDNSサーバー一覧
MX(Mail Exchange) ・・・ メールの配送先
A(Address) ・・・ ホスト名に対応したIPアドレス
CNAME(Canonical Name) ・・・ サーバーに別名をつける。
PTR(Pointer) ・・・ IPアドレスからホスト名に変換
以下に正引きゾーンファイルと逆引きゾーンファイルの記述例を示す。
■正引きゾーンファイル(dmz140.sentan-college.zone)の記述例
$ORIGIN dmz.sentan-college.ac.jp. |
正引きゾーンファイルの記述について解説していく。
まず、1行目の$ORIGIN以降の記述だが、これは管理するネットワーク(=ドメイン名)を記述する。
2行目の$TTL(=Time To Live)はDNSサーバーのキャッシュ生存期間。ココでは86400(秒)と書かれている。これは、DNSサーバーのキャッシュが24時間有効であることを示している。
3行目の@ IN SOAの以降は、このIPアドレス(=172.18.140.1)のホストの名前解決をするホスト名を記述する。上記の例では、eaa00140.dmz.sentan-college.ac.jpとroot.sentan-college.ac.jpのホスト名をこのIPアドレス(=172.18.140.1)として解決している。解決したいホスト名が複数ある場合は半角スペースで区切る。最後のホスト名の末尾に.(ピリオド)を入れることを忘れないように注意。
上記の3行は先頭にスペースやタブをいれずに右詰めで記述しないと、DNSが有効にならないので注意すること。
4〜10行目はスペースやタブをいてれもかまわない。
Serial・・・更新フラグを示す。ゾーンファイルを書き換えるたびに更新日時を書き込んで記録しておく。
Refresh・・・DNS情報のリフレッシュ間隔(秒)
Retry・・・ココで記述した時間(秒)応答がなければタイムアウトする。
Expire・・・DNSの認証期間(秒)
IN NS以降の記述は、このゾーン(=該当のドメインのネットワーク範囲)を管理しているDNSサーバーの一覧を記述する。複数台記述は可能だが、ホスト名とホスト名はスペースで区切り、最後のホスト名の末尾には必ず、.(ピリオド)を入れることを忘れないように注意。
10行目の記述、 IN MX 10 mail140.dmz.sentan-college.ac.jp.だが、これは、DNSサーバーが要求を受け付けたメールの配信先サーバーを記述する。上記の例では、1台しか書いていないが複数台記述することが出来る。MXの後に、10と云う記述があるが、これはDNSが要求を受け付けたメール配信サーバーの優先順位である。
MX 10 ・・・ 第1優先
MX 20 ・・・ 第2優先
MX 30 ・・・ 第3優先
第2優先、第3優先のメールサーバーを記述した際には、下にIPアドレスとホスト名の対応、サーバー名に対する別名を記述する必要がある。
11行目以降は再び、先頭にスペースやタブを入れては設定が有効にならない。コレからは、ホスト名に対するIPアドレスとの対応やゾーン内のサーバーの別名をつける。
eaa00140 IN A 172.18.140.1 ・・・ IPアドレス172.18.140.1のホストをこのゾーンではeaa00140として名前解決する。
dns140 IN CNAME eaa00140 ・・・ DNSサーバー(=dns140)は上記で登録したeaa00140として名前解決する。
www140 IN CNAME eaa00140 ・・・ WEBサーバー(=www140)は上記で登録したeaa00140として名前解決する。
mail140 IN CNAME eaa00140 ・・・ Mailサーバー(=mail140)は上記で登録したeaa00140として名前解決する。
※
eaa00140のホスト上では、DNS,WWW,MAILサーバーがそれそれ稼働しているので、上記のような記述になる。
■逆引きゾーンファイル(dmz140.sentan-college.rev)の記述例
$ORIGIN 140.18.172.in-addr.arpa. |
逆引きゾーンファイルの記述について解説していく。
まず、1行目の$ORIGIN以降の記述だが、これはDNSサーバーたる自サーバーのIPアドレスを逆に書く。例えば、IPアドレスが、172.18.140.1だったとする。ホストアドレス(.1)を抜いた値(172.18.140)の逆並びを記述し、その直後に.in-addr.arpa.と書く。以降9行目の記述までは上記の正引きゾーンファイルの記述と役割は同じである。
10行目、1 IN PTR eaa00140.dmz.sentan-college.ac.jp.の1だが、これはDNSサーバーのIPアドレス(172.18.140.1)のホスト部分の1である。コレを記述しないと逆引きが出来ない。
7.BINDの起動確認
■ファイアウォール設定の変更
DNSサーバーに対するUDPポート場号53の開放をファイアウォールで設定する。
# vi /etc/sysconfig/iptables -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT |
iptablesに上記の記述をしたら、変更を反映させるためにiptablesを再起動する。
# service iptables restart |
■デーモン(named)の状態確認
ここまで設定が済んだら、BINDの動作確認を行うために、デーモンたるnamedを起動する。
# service named status |
デーモンが起動していれば下記のように表示される。
number of zones: 8 |
ココでは、まだ起動していないので上記のようには表示されないはず。
■デーモンの起動・停止・再起動
# service named start <- 起動させる場合 |
■初期起動設定
今の状態では、サーバーを再起動した際にBINDは停止したままになってしまう。
以下のようにコマンドを発行し、起動・再起動時にも自動的にBINDが起動するようにしておく。
# chkconfig --list named <- 現在の設定の確認 |
下記のように表示される。
named 0:off 1:off 2:on 3:off 4:off 5:off 6:off |
デーモンのランレベル3,4,5は常にonにしておくべきなので、以下のようにコマンドを発行する。
# chkconfig named on <- 現在の設定の確認 |
8.DNSサーバーの動作確認
DNSサーバーによる名前解決が出来ているか、動作確認。
DNSでエラーが起こっていればログファイル/var/log/messagesにDNSのエラー内容が記述されるので以下のようにコマンドを打ち込んで、確認する。
# tail -f /var/log/messages |
DNSクライアントとして/etc/resolv.confの記述で下記の記述があることを確認する。
search dmz.sentan-college.ac.jp |
■nslookupで動作確認
#nslookup
>172.18.140.1 |
上記のような結果が返ってくれば、サーバー上ではDNSの稼動が確認できた。
次に、同一ネットワーク上のクライアントPCからDNSサーバからの名前解決が可能かを確認する。
C:\nslookup
C:\nslookup |
上記のような結果が返ってくれば、クライアントPC上でのDNSの稼動が確認できた。