第2回 名前解決の仕組みとゾーンファイルの設定
今回は、BINDの設定を行う。ゾーンファイルの編集を行って正引き・逆引きが行えるようにするほか、MX、CNAMEなど各種レコードの使い方を紹介する。また、名前解決の仕組みについてもここで理解しておいてほしい。
関野史朗
2001/1/12
前回、DNSサーバの代表的な実装であるBINDをインストールしました。今回は設定を行います。
しかしその前に、BINDの動作を簡単に理解しておく必要があります。そうせずに、単に資料の引き写しの設定ファイルを使う方法もありますが、予期せぬ動作をしたときに対処できなくなってしまいます。
前回、「DNSは分散型データベースである」と述べました。つまり、どこかにすべてのデータを持ったサーバがあるわけではなく、あちらこちらにサーバが分散しているわけです。問題は、どうやって目的のデータを持ったサーバを見つけだすかです。
さすがに手掛かりゼロではどうしようもないので、最初の手掛かりとしてルートネームサーバが用意されています。いまのところ、ルートネームサーバは世界に13個存在します。BINDは問い合わせを受けると、まずこのルートネームサーバに照会します。すると、「そのドメイン名ならこのサーバに権限を委譲している」というデータが返ってきます。そこで、指示されたサーバに再び照会し直すと、さらに「そのドメイン名ならこのサーバに権限を委譲している」という回答が返ってきます。こうして権限を委譲されたサーバをたどっていくことで、最終的に「そのドメイン名のIPアドレスは210.xxx.xxx.xxxです」と答えてくれるサーバに行き着くわけです。
もう少し具体的に、www.atmarkit.co.jpのIPアドレスを問い合わせるとしましょう。まず、BINDはルートネームサーバに照会します。するとルートネームサーバは「jpドメインはサーバAに権限を委譲している」という答えを返します。ついでBINDはサーバAに対してwww.atmarkit.co.jpのIPアドレスを問い合わせます。するとサーバAは「co.jpドメインはサーバBに権限を委譲している」と答えます。サーバBに同じような問い合わせを行うと、「atmarkit.co.jpドメインはサーバCに権限を委譲している」と回答します。ここでサーバCに問い合わせると「www.atmarkit.co.jpのIPアドレスは211.2.252.66である」となって、無事解決できるわけです。
なお、ここでは単純にドメインごとにサーバを分けていますが、自前のDNSサーバを持たないドメインもあります。この場合は、より上位のDNSサーバが該当するドメインに対する問い合わせに答えます。
もちろん、問い合わせがあるたびにいちいちルートネームサーバから照会すると無駄なトラフィックが発生しますから、ある程度はBINDがデータをキャッシュしています。
基本的な動作が分かったところで、順に設定ファイルを見ていきましょう。前提としてOCNエコノミーなどで、/28（ネットワークアドレスが28bitsでホストアドレスが4bits）のIPアドレスを割り当てられたことにします。この場合、ISPからDNSサーバのホスト名とIPアドレスを指定されるので、そのコンピュータでBINDを動かします。DNSサーバのIPアドレスは、だいたい下位4bitsだけを見て2というのが一般的なようです（0はネットワークそのもの、1はルータに対して割り当てられることが多い）。
まずは、BINDそのものの基本設定ファイルです。これは通常/etc/named.confですが、ディストリビューションによっても違ってきます。例えばLASER5 Linux 6.4はこのとおりですが、Debian GNU/Linux 2.2では/etc/bind/named.confです。
必要最小限の設定を挙げると、以下のようになります。
options { |
| リスト1 named.conf |
上から順に説明しましょう。まずoptionsですが、ここではdirectoryを使ってBINDの設定ファイルがあるディレクトリを指定しています。/etc/bindなどでもいいでしょう。named.conf以外は、明示的に指定したこのディレクトリにまとめておいた方が分かりやすくなります。
次のzone "."は、ルートネームサーバを記述したファイルを指定します。ここではファイル名しか書いてありませんから、前述のoptionsで指定したディレクトリ内のnamed.root、すなわち/etc/namedb/named.rootを意味しています。
zone "0.0.127.IN-ADDR.ARPA"は、localhostを処理するためのおまじないです。ここはどんなサイトでも同じになります。
zone "atmarkit.co.jp"では、atmarkit.co.jpドメインのプライマリネームサーバになること、正引き（ドメイン名からIPアドレスを引くこと）のデータはnamed.hostsに記述することを指定します。
zone "80.1.168.192.in-addr.arpa"は逆引きの設定で、やはりプライマリネームサーバであることと、逆引き（IPアドレスからドメイン名を引くこと）のデータはnamed.revに収められていることを意味しています。なお、ここではIPアドレスとして192.168.1.80/28を想定しています。これはプライベートIPアドレスなので、実際には外部に向かってアナウンスすべきものではありません。実際に設定を行うときは、ISPから割り当てられたIPアドレスに適宜読み替えてください。また、zoneに続く記述ではIPアドレスを逆順に表記する点にも注意が必要です。
これは簡単です。named.confで指定したファイルに、ルートネームサーバを記述しておけばいいのです。最新のデータはftp://ftp.rs.internic.net/domain/named.rootです。これをそのままコピーすればOKです。原稿執筆時点では、1997年8月がlast updateになっています。たまにチェックするだけでよいでしょう。
続けて、正引きのデータを用意します。サンプルとしては以下のようになります。
@ IN SOA dns.atmarkit.co.jp.
root.atmarkit.co.jp. ( |
| リスト2 named.hosts（正引き用ローカルゾーンファイル） |
最初に、SOAレコードを記述します。冒頭の@マークは、自ドメインに置き換わります。正確を期すなら、atmarkit.co.jp.などと明示的に記述します。ここで、ドメイン名の最後にピリオドが付いていることに注意してください。
続くINはInterNetを意味しています。ほかにも指定できるパラメータはあるのですが、今日ではINしか使われていないといって差し支えないでしょう。SOAはStart Of Authorityの略です。続けて、このデータが格納されているホスト名と、このデータに責任を持つ人間の電子メールアドレスを記述します。いずれもピリオドが最後に付くこと、@を.に置き換える点に注意が必要です。
続く数字は、セカンダリネームサーバに対する指定です。最初にシリアル番号がきます。これはデータを変更したときにより大きな数値に変更することで、ほかのDNSサーバに変更があったことを知らせます。何でもいいのですが、2000122401のように年月日＋連番にしておくと、いつ変更したのか分かりやすくなります。
あとは、データを確認する間隔、失敗後再試行の間隔、データが無効になるまでの時間、データをキャッシュしておける時間を、それぞれ秒数で指定します。ここを変更する必要はほとんどありません。
| ■コラム ピリオドの有無 |
|
BINDの正引き、逆引き設定ファイルでは、ピリオドの有無に気を付ける必要があります。それは、ピリオドがないとnamed.confで指定したドメイン名が補完されるからです。wwwとだけ書くとwww.atmarkit.co.jpになるのですが、www.atmarkit.co.jpと書くとwww.atmarkit.co.jp.atmarkit.co.jpと書いたことになってしまうのです。一般的にはFQDNを記述するよりもホスト名を記述する頻度が高いでしょうから、その手間を減らすためにこのような仕様になっているのでしょう。 |
SOAの次には、NSレコードを記述します。NSはName Serverの略で、ネームサーバを指定します。自分自身と、普通はISPが用意するセカンダリネームサーバを指定しておきます。ここでも、ドメイン名の最後にピリオドが付いていることに注意してください。
ようやく、個々のホスト名を記述するところまできました。ホスト名はA（Address）レコードで記述します。ここでは、ホスト名の後ろにピリオドを付ける必要はありません。IPアドレスも普通に記述します。
ホスト名の付け方に関しては、お好み次第です。小規模なうちは惑星、星座あたりを付ける人が多いようです。大規模になると、どうしても設置場所などをもとにした記号になってしまうようですが。
なお、ドメイン名が何を意味するのかは微妙です。例えばwww.atmarkit.co.jpと書いた場合、wwwがホスト名でatmarkit.co.jpがドメイン名、と考えるのが普通です。しかし、RFC 1034の2.4. Elements of the DNSあたりを読むと、どうもwww.atmarkit.co.jpでドメイン名となるようです。このあたりの誤解を避けるため、ホスト名を含んだドメイン名の記述をFQDN（Fully Qualified Domain Name：完全修飾ドメイン名 ）と呼んでいます。
正引きデータができたら、今度は逆引きデータです。サンプルは以下のとおり。
@ IN SOA sun.atmarkit.co.jp.
root.atmarkit.co.jp. ( |
| リスト3 named.rev（逆引きファイル） |
SOAレコードとNSレコードについては、正引きのときと同じです。
逆引きのデータについては、PTR（PoinTeR）レコードで記述します。最初だけは例外的に、どこのドメイン名を扱うのかを宣言します。ここではatmarkit.co.jpを指定しますが、最後にピリオドが付くことを忘れないでください。続くAレコードでは、これも例外的にネットマスクを記述します。とりあえず、/28のネットワークでは255.255.255.240になります。
ネットマスクはBINDやDNSではなく、どちらかといえばIPネットワークの知識なのですが、簡単に説明しておきましょう。IPアドレスは2進数で書くと32けたです。そして、ネットワークを区別するためのネットワークアドレスと、ネットワーク内でホストを区別するためのホストアドレスで構成されています。このとき、上位何bitsをネットワークアドレスとして使うかを、/に続けた数値で表します。つまり192.168.1.80/28と書くと、192.168.1.80から始まる、ネットワークアドレス長が28bitsのネットワークということになります。さらにいえばホストアドレスは4（＝32−28）bitsですから16通りです。従って、192.168.1.80-192.168.1.95までがこのネットワークに所属するIPアドレスということになります。
このことを別の方法で表記するのが、ネットマスクです。こちらの方法だと、IPアドレスのうちネットワークアドレス部を1に、ホストアドレス部を0にしたものを、通常のIPアドレスの表記に従って0〜255の数値4つで記述します。これはちょうど2進数で8けたに相当する範囲です。なので、/28のネットワークだと最初の3つは255、最後の1つは2進数表記で11110000、10進数表記で240となるのです。
さて、以後は普通にIPアドレスとホスト名をPTRレコードとして記述していくだけです。ここでも、ドメイン名の最後にピリオドを付加します。また、IPアドレスは最も下位の1オクテットのみを記述するだけです。
最後に、もう1つループバック用の逆引きファイルを用意します。これでBINDを動かすために必要な最低限の設定ファイルがそろったことになります。
@ IN SOA dns.atmarkit.co.jp.
root.atmarkit.co.jp. ( |
| リスト4 localhost.rev（ループバック用逆引きファイル） |
以上で基本的な設定は終了です。しかし、まだ重要な設定が残っています。それはメールサーバを指定するMX（Mail eXchanger）レコードです。OCNエコノミーでDNSサーバを自組織で用意するということは、すなわちメールサーバも自組織で用意するということです。そのため、MXレコードの設定は欠かせません。メールサーバ自体の設定は、本フォーラムの実用qmailサーバ運用・管理術などを参照してください。
MXレコードは、正引きデータを記述したファイルに
IN MX 10 sun.atmarkit.co.jp. |
といった形で指定します。ここでMXに続く数値はプリファレンス値といいます。この数値が小さい順に、順次メールサーバとしてアクセスするという指定になります。相対的な大きさだけが問題なので、符号なし16bits数値の範囲なら好きなように設定できます。つまり、予備のメールサーバを作っておけるわけです。
もう1つ、便利な設定にCNAME（Canonical NAME）レコードがあります。これは、1つのIPアドレスに幾つかのホスト名を割り当てるときに使います。これもMXレコード同様に、正引きデータを記述したファイル内に記述します。例としてはこんなところでしょうか。
dns IN CNAME sun |
サービス名をそのままCNAMEで設定しておくと、実際にサービスを提供しているコンピュータが変わったときに、BINDのデータを変更するだけで済みます。個々のクライアントは、一切変更する必要がないわけです。ただ、この方法は外部の悪意を持ったユーザーから容易に推察できるという点で、セキュリティ的にはやや問題のある方法です。
また、Apacheと組み合わせてバーチャルホストを使うときにも、CNAMEは欠かせません。この方法を使うと、1つのIPアドレスを割り当てた1台のホストで、見かけ上は複数のWebサーバを運用できます。
最後に、いま紹介したMXおよびCNAMEレコードを正引きファイルに反映してみましょう。以下のリストが完成版です。
@ IN SOA dns.atmarkit.co.jp.
root.atmarkit.co.jp. ( |
| リスト5 完成版named.hosts（正引き用ローカルゾーンファイル） |
ここまでくれば、BINDを動かし始めることができるはずです。ディストリビューションによっては、パッケージからインストールした時点で動き始めているかもしれません。psコマンドを使ってnamedを探し、ないようだったら実行します。すでに動いていれば、変更内容を反映するためにSIGHUPを該当プロセスに送ってください。実行するコマンドは、
$ kill -HUP プロセス番号 |
です。
ここでresolv.confを書き換えて、いきなり外のWebにアクセスする方法もあります。が、テスト用のnslookupを使った方がよいでしょう。起動後に、まずローカルなネットワークに所属するホスト名だけを打ち込んで［Enter］キーを押します。すると、対応するIPアドレスが返ってくるはずです。逆にIPアドレスを入力すると、ホスト名が返ってきます。ローカルなネットワークでうまくいったら、外部のホスト名に対しても確認してみましょう。
もう1つ、MXレコードについても確認しておきましょう。nslookupのプロンプトで、以下のように操作します。
> set type=mx |
すると、MXレコードの設定に応じて、以下のような出力が得られます。
atmarkit.co.jp preference = 20, mail
exchanger = smtp.atmarkit.co.jp |
この設定と、メールサーバの設定が正しければ、外部からSMTPでメールを受け取ることができるはずです。
もし、うまくいかなかったら……次回は不具合の発見方法をお伝えします。
 |
連載 BINDで作るDNSサーバ |
| Linux Squareフォーラム サーバ構築・運用関連記事 |
 |
連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します |
|
特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する |
|
連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える |
|
連載：実用
BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく |
|
連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで |
|
特集：Samba
3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する |
|
ホワイトペーパー（TechTargetジャパン）
- natテーブルを利用したLinuxルータの作成・2 （2010/3/11）
IPパケットのディスティネーションアドレスを書き換える「DNAT」を使って、透過型プロキシを構築します - 一歩進んだ監視のカスタマイズ （2010/3/3）
スクリプトの実行結果などを取得できるユーザーパラメータを用いて、自分のニーズにぴったり合った監視を実現 - OSSライセンス順守の第一歩 （2010/2/18）
企業として、OSSライセンス違反を犯さないためには、どのような手順が必要か、いくつかアドバイスします - 無視できないフラグメンテーション問題への解答は？ （2010/2/10）
今回は、メモリコンパクション、そしてメモリバリアを発行するシステムコールという2つのパッチについて深く紹介します
 |
|
|
|
|
スキルアップ／キャリアアップ（JOB@IT）
スポンサーからのお知らせ
- - PR -
 |
「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは？ New！ |
 |
「特権ユーザー」の事件を防げ！ 万能権限を持つユーザーの管理方法とは？ New！ |
 |
仮想環境の構築とデータ保護の特効薬？！ 実績と信頼性の高いパッケージで安心運用 |
 |
仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
 |
おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
 |
社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
 |
その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
 |
美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
 |
進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
 |
運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
- - PR -
お勧め求人情報
*＊先週の人気講座ランキング＊*
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約！ “業務”用APサーバ大百科 New！ |
| ◆ | 一気に解説！ 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New！ |
| ◆ | クラウド的ユーザー体験の変化は脅威か？ 仮想化技術を使いこなす運用管理術を紹介 New！ |
| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは？ New！ |
| ◆ | おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| ◆ | Twitterのアカウントはなぜ突破された？ メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ！ Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は？ |
| ◆ | 業務効率と情報セキュリティ対策を両立！ 手間なく確実に機密情報を守る方法とは？ |
| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
| ◆ | 【CTC事例】約30の基幹システムを統合！ 膨大なバッジジョブを制御した方法は？ |
| ◆ | 仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「＠IT MONOist」「ITmedia」「誠」「BARKS」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。