|
|
|
|
サーバーのセットアップ
|
|
固定IPでDNSサーバー構築
|
||
固定IPでDNSサーバー構築ブートファイルの基本設定WAN用ゾーンファイルの作成ポートフォワーディングの設定WAN空間からのDNSチェックスレーブDNSサーバーの設置DNSサーバとドメイン名の登録レコードの書き換えについて |
LAN側とWAN側で異なる名前解決結果を返すには
このページをご覧になっている方の多くは、既に
BIND
を使って
LAN
側で動作する
DNSサーバー
を運用していると思います
以下は、
さて、稼働中のDNSサーバーを
WAN
側からでも利用できるようにするには、名前解決のための
Well-Knownポート
である
53番
ただし、それは アクセスして利用可能になる というだけであって、実際にはうまく機能しません。 |
||||||||||||
|
|
なぜなら、現在のBINDの設定はあくまでLAN側に利用を限定したものですから、WAN空間からアクセスしても肝心の "obenri.com" の FQDN について、
"web1.obenri.com" → "192.168.100.11"
のように、 プライベートIPアドレス に名前解決されてしまいます。 実際には "web1.obenri.com" は、WAN空間からは自宅のインターネット接続に用いる固定の グローバルIPアドレス に名前解決されなければならないわけですから、これではもちろんNGです。 つまり、こういうケースでBINDをWAN側で「権威あるDNSサーバー」として稼動させるには、LAN側からのアクセスに対してはプライベートIPアドレスに、WAN側からのアクセスに対してはグローバルIPアドレスに、という具合に 別々の回答をさせる ようにしなければなりません。 BINDにこういった働きをさせるには、大きく分けて二つの方法があります。 ひとつ目は、 「一つの named の プロセス の中で、アクセス元の IPアドレス に応じて回答の内容が変わるように設定を行う。」 という方法です。 これは比較的オーソドックスな方法です。 もうひとつは、 「namedのプロセスを二つ稼動させ、それぞれをWAN側とLAN側で分けて応答させる。」 というちょっと高度な方法です。 これらの方法にはもちろん一長一短があって、どちらが良くてどちらが良くないということはありません。 |
||||||||||||
|
メインメモリ の消費量や サーバー機 への負荷を考えるならば前者が有利でしょうし、大量の ドメイン名 を運用するような大規模のDNSサーバーでは、 セキュリティ が高く、プロセスを管理しやすい後者を選ぶべきでしょう。 もちろんこの コンテンツ では、設定が簡単で負荷の小さな前者の方法について解説します。 BINDは非常に柔軟な設定が可能な アプリケーション ですから、これから紹介する以外にもLAN側とWAN側の回答を別々に行う方法はいくつかあります。 今回はそのなかから最もわかりやすく、設定を間違えにくい "view" キーワードを利用した方法を紹介します。
関連セクション・
自宅内DNSサーバーの構築
関連ページ・
名前解決とネームサーバー
|
|||||||||||||
| このページの先頭へ↑ |
"view"キーワードを用いた基本的なブートファイルの記述"view" は、比較的最近のバージョンのBINDで利用できるようになった便利なキーワードで、 ブートファイルである "/etc/named.conf" の中に記述し、 名前解決 をリクエストする クライアント の IPアドレス ごとにゾーンファイル命令の応答、拒否のふるい分けを行う。 という仕組みを「簡単に」提供します。 同様の仕組みは、 "acl" キーワードと "allow-query" 補助命令を組み合わせても提供することが可能で、こちらを利用するほうがより細かいアクセス制御ができます。 しかし今回は ドメイン名 "obenri.com" に関する正引きの回答について、 LAN 側と WAN 側で別々に行うだけですから、 "view" キーワードで充分でしょう。 |
||||||||||||
|
|
では具体的に、LAN側で使用するDNSサーバーの
"/etc/named.conf"
の記述例
"view" キーワードはこのように、アクセスを許可するIPアドレスの範囲を宣言して、その対象となるゾーンの定義を括るように記述します。 つまり、 view lan { から }; までの範囲に記述されている各ゾーン命令は、LAN側からの名前解決リクエストにのみ答えを返し、 view lan { から }; までの範囲はそれ以外(つまりWAN側)からのリクエストに応える、という設定になるわけです。 LAN側の各ゾーンに対する記述内容は変更する必要がなく、単純に view lan { から }; でくくるだけでOKです。 一方WAN側に回答するゾーン命令(ゾーンファイル "obenri.com.wan.zone" )については、契約している固定IPアドレスを元に新規に記述することになります。 以下のパートで、この "view" キーワードについてもう少し詳しく解説します。
関連セクション・
自宅内DNSサーバーの構築
関連ページ・
名前解決とネームサーバー
|
||||||||||||
| このページの先頭へ↑ |
"view"キーワードの設定について"view" キーワードの基本的な書式は以下のとおりです。
仕組みは意外に単純で、 クライアント のリクエスト元の ノード の IPアドレス が [アクセス制御パラメータ] と比較され、条件が一致した場合に該当する "view" に括られたゾーン命令から回答が行われます。 "view" キーワードは先の記述例のように複数定義するのが一般的で、文頭に記述された "view" から順に条件の比較が行われます。 そして条件が一致した段階で参照は終了し、以降の "view" は参照されなくなります。 従って、 "view" キーワードでアクセス制御を行う場合、IPアドレス範囲の限定されているものから順に "view" を記述し、最後に「それ以外のIPアドレスに応答許可」という "view" を記述するようにします。 [定義名] には任意の名前を宣言します。今回のケースでは解りやすいように LAN 側に応答を許可する範囲に "lan" 、それ以外(つまり WAN 側) に "wan" という名前を宣言しています。 "match-clients"〜アクセスの許可範囲を定義する"match-clients" は "view" キーワードの中に記述する補助命令で最も重要な部分で、 [アクセス制御パラメータ] に記述された範囲にリクエスト元の IPアドレス が含まれる場合に "view" の範囲が応答を行うことになります。 |
||||||||||||
| これらのパラメータは複数記述することで複数の異なる範囲を一緒に指定することもできます。 |
[アクセス制御パラメータ] には、 "192.168.100.0/24" 、 "192.168.100.0/255.255.255.0" といった プレフィックス長 形式や サブネットマスク 形式で サブネット の範囲を記述できます。もちろん、 "192.168.100.112" のように特定のIPアドレスを設定することもできます。 |
||||||||||||
|
|
また、 "/etc/named.conf" の記述のために予め用意されている アクセスリスト名 という以下のパラメータを記述することもできます。
"match-clients"で利用可能なアクセスリスト名
"localhost"
、
"localnets"
の二つのアクセスリスト名は、
構築中のLinuxサーバー
のネットワーク設定
従って、
と、
は、 構築中のLinuxサーバー で BIND を稼動させる場合には同じ動作をすることになりますが、できれば "localnets" という記述をお勧めします。 |
||||||||||||
| サーバー機 に NIC を追加して複数のサブネットを設定したり、一つのNICに複数のサブネットを割り当てたりすると、 "localnets" や "localhost" は複数の値を持つことになりますので気をつけてください。 |
なぜなら、例えば サーバー機 を含めた自宅のサブネットを "192.168.100.0/24 から "192.168.200.0/24 に変更した場合でも、 "localnets" と記述しておけば自動的に値が変更されるからです。 また、パラメータの先頭に "!" を付けると、そのパラメータの 否定 を意味するようになります。 そこで、
という記述になるわけです。 |
||||||||||||
|
DNSサーバーの構築に、
とても役に立った一冊です ↓ |
実際には最初の "view lan" のところでLAN側に対する応答が行われると "view wan" は参照されないため、正確には "!localnets" の記述は必要ありません。 しかし、
とだけ記述してしまうと、例えば "view lan" の設定を間違えてしまった場合に、LAN側から "view wan" 内のゾーン命令が参照されてしまう可能性が生じてしまいます。 そういった間違いを予防するためにも、 "view wan" には必ず "!localnets" を加えておいてください。 "recursion"〜DNSキャッシュによる応答の制御WBEL や CentOS に インストール されている BIND は、他の多くの ディストリビューション の場合と同じく デフォルト で DNSキャッシュ の機能が有効になっています。 従って明示的にDNSキャッシュの利用に関する設定を行わない限り、BINDはリクエストした相手に対して「権威ある回答」と同時にDNSキャッシュからの回答をあわせて行うことになります。 "recursion" は、そのDNSキャッシュによる回答を明示的に指定するもので、 recursion yes (DNSキャッシュによる回答を行う) recursion no (DNSキャッシュによる回答を行わない) という設定方法になります。 |
||||||||||||
|
|
つまり上の設定例のように、
と記述すると、 LAN 側ではゾーン命令に一致しないリクエストに対してはDNSキャッシュによる回答を試み、 WAN 側ではゾーン命令以外の回答は一切行わなくなります。 WAN空間からのリクエストに対してDNSキャッシュを使用しない理由は、いうまでもなく不正使用を防止するためです。 構築中のLinuxサーバー が正式に「権威あるDNSサーバー」として登録されると、その FQDN と グローバルIPアドレス は一般情報として世界中に公開されることになります。 もしWAN空間に対してDNSキャッシュによる回答を有効にしたままにしておくと、仕組み上は ISP などが運営しているエンドユーザー向けのDNSサーバーと同じ振る舞いをしますから、見知らぬ誰かに勝手に利用されてしまう可能性がでてきます。 しかし "recursion no" と設定しておけば、 構築中のLinuxサーバー は ドメイン名 "obenri.com" に関する回答以外は行わなくなりますから、一般での利用価値がなくなってしまい、結果的に不正使用が防止されるというわけです。 ところが「自前で賄えるものはできるだけ自前で賄う」という立派なポリシーをお持ちの方などは、「せっかく構築するのだから、WAN空間からでも自前のDNSサーバーをキャッシュサーバーとして使いたい。」と思われるかもしれませんが、それは全くといっていいほど 意味のないことです。 下の模式図をご覧ください。
契約しているISPのDNSサーバーを用いる時の名前解決パケットの流れ 通常インターネット接続契約を行うと、ISPから使用するDNSサーバーのIPアドレスが指定されますが、それは通常、ISPが自身で設置しているDNSサーバーです。 ISPはユーザーにできるだけ快適なサービスができるようにするため、図のようにDNSサーバーは クライアント から出来るだけ最短の経路でに到達できる位置に設置されています。 向かって右側は一般的なインターネット接続の例、向かって左側の図は自宅にDNSサーバーを設置している例です。 |
||||||||||||
ISPのDNSサーバーを
フォワーダー
として指定している場合の例です。
|
自宅のDNSサーバーを利用する場合でも、伸びる経路は自宅内のLANの部分だけですから、直接ISPのDNSサーバーを参照する場合と比べても大した違いはありません。 ところが、自宅に設置しているDNSサーバーを外部から利用しようとすると、下の図のように パケット は非常に長い経路を通ることになります。
外出先から自宅のDNSサーバーを用いる時の名前解決パケットの流れ 自宅サーバーはISPのサーバーと異なり、物理的にも論理的にも「インターネットの末端」に設置されているわけですから、パケットはどうしてもこのような長旅を強いられることになります。 この図では二つのISPの間がお互いのルーターで直結されているようになっていますが、実際にはもっと多くの ルーター を経由することになるのが普通です。 これでお解りのとおり、インターネット全体で見た場合の通信帯域への負荷と 名前解決 のレスポンス、そして通信経路の長さによるエラーの発生頻度などを考えれば、無理して自宅のDNSサーバーを利用するよりは、ISPが設置しているDNSサーバーを素直に利用したほうがよいことになります。 というわけですから、WAN側に設定する "view" キーワードには必ず "recursion no" を設定し、DNSキャッシュを利用できないようにしてしまいましょう。
関連セクション・
自宅内DNSサーバーの構築
関連ページ・
名前解決とネームサーバー
|
||||||||||||
| このページの先頭へ↑ |
"/etc/named.conf"の例以上の内容で作成した "/etc/named.conf" は、こちらをクリックすると表示できます。 この テキスト ファイルには余分な文字は入っていませんから、開いてコピー&ペーストで使用するか、 ダウンロード して使用してください。
関連セクション・
自宅内DNSサーバーの構築
関連ページ・
名前解決とネームサーバー
|
|
固定IPでDNSサーバー構築
<<Previous
|
Next>>
WAN用ゾーンファイルの作成
|
| このサイトに対するご意見、ご要望、苦情、泣き言、献上品、資金援助などがございましたら こちら からお寄せください(お返事できなかったらごめんなさい)。もちろん リンクフリー です。趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。また、本サイトの更新情報をメールで知らせてほしい方は ここ からご登録ください。 |
| ”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。 |