このページでは固定IPアドレス一個名前解決を行うDNSサーバーの構築を行う際のブートファイルの基本設定についてビギナー向けに解説します。
お便利サーバー.com+相互リンクサイト内をキーワードで検索
固定IPでDNSサーバー構築

固定IPでDNSサーバー構築

ブートファイルの基本設定

WAN用ゾーンファイルの作成

ポートフォワーディングの設定

WAN空間からのDNSチェック

スレーブDNSサーバーの設置

DNSサーバとドメイン名の登録

レコードの書き換えについて


LAN側とWAN側で異なる名前解決結果を返すには

このページをご覧になっている方の多くは、既に BIND を使って LAN 側で動作する DNSサーバー を運用していると思います LANで使用するDNSサーバーの構築

以下は、 LANで使用するDNSサーバーの構築 に準じてLAN内で利用するDNSサーバーを運用していることを前提に解説を行いますので、もしも hostsファイル でLAN内の 名前解決 を行っている場合 hostsファイルの設定について は、BINDの基本的な設定を理解する意味でも、まずはLAN側で動作するDNSサーバーを構築してみてください。

さて、稼働中のDNSサーバーを WAN 側からでも利用できるようにするには、名前解決のための Well-Knownポート である 53番 Well-Knownポートについて 構築中のLinuxサーバー ポートフォワーディング するように ルーター を設定すればOKです。

ただし、それは アクセスして利用可能になる というだけであって、実際にはうまく機能しません。

なぜなら、現在の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" の記述例 LAN側で使用するDNSサーバーの/etc/named.confの記述例(〜9.3.x) "view" キーワードを追加して、LAN側とWAN側のアクセスの振り分けを記述してみましょう。

//
// named.conf for Red Hat caching-nameserver
//

options {
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    /*
     * If there is a firewall between you and nameservers you want
     * to talk to, you might need to uncomment the query-source
     * directive below. Previous versions of BIND always asked
     * questions using port 53, but BIND 8.1 uses an unprivileged
     * port by default.
     */
     // query-source address * port 53;
};        1.ゾーンファイルのディレクトリなどの指定

//
// a caching only nameserver config
//
controls {
    inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};        2.rndcによるコントロールの設定

view lan {
    match-clients {
        localnets;
    };
    recursion yes;


zone "." IN {
    type hint;
    file "named.ca";
};        3.ルートサーバーのためのゾーンファイル設定

zone "localdomain" IN {
    type master;
    file "localdomain.zone";
    allow-update { none; };
};        4'.ローカルホスト(DNS名)の正引きゾーンファイル設定

zone "localhost" IN {
    type master;
    file "localhost.zone";
    allow-update { none; };
};        4.ローカルホスト(一般名)の正引きゾーンファイル設定

zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "named.local";
    allow-update { none; };
};        5.ループバックアドレスの逆引きゾーンファイル設定

zone "obenri.com" IN {
    type master;
    file "obenri.com.zone";
    allow-update { none; };
};        A."obenri.com"に対する正引きゾーンファイル設定(LAN側)

zone "100.168.192.in-addr.arpa" IN {
    type master;
    file "100.168.192.in-addr.arpa.zone";
    allow-update { none; };
};        B.サブネットのIPアドレスに対する逆引きゾーンファイル設定

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 {
    type master;
    file "named.ip6.local";
    allow-update { none; };
};        6.IPv6用ループバックアドレスの逆引きゾーンファイル設定

zone "255.in-addr.arpa" IN {
    type master;
    file "named.broadcast";
    allow-update { none; };
};        7.誤った逆引きに対処するゾーンファイル設定

zone "0.in-addr.arpa" IN {
    type master;
    file "named.zero";
    allow-update { none; };
};        7'.誤った逆引きに対処するゾーンファイル設定

};

view wan {
    match-clients {
        !localnets;
        any;
    };
    recursion no;


zone "obenri.com" IN {
    type master;
    file "obenri.com.wan.zone";
    allow-update { none; };
};        A’."obenri.com"に対する正引きゾーンファイル設定(WAN側)

};

include "/etc/rndc.key";        8.rndc用暗号化キーの所在の指定

"view" キーワードはこのように、アクセスを許可するIPアドレスの範囲を宣言して、その対象となるゾーンの定義を括るように記述します。

つまり、 view lan { から }; までの範囲に記述されている各ゾーン命令は、LAN側からの名前解決リクエストにのみ答えを返し、 view wan { から }; までの範囲はそれ以外(つまりWAN側)からのリクエストに応える、という設定になるわけです。

LAN側の各ゾーンに対する記述内容は変更する必要がなく、単純に view lan { から }; でくくるだけでOKです。

一方WAN側に回答するゾーン命令(ゾーンファイル "obenri.com.wan.zone" )については、契約している固定IPアドレスを元に新規に記述することになります。

以下のパートで、この "view" キーワードについてもう少し詳しく解説します。

関連セクションへ 関連セクション・ 自宅内DNSサーバーの構築


このページの先頭へ↑

"view"キーワードの設定について

"view" キーワードの基本的な書式は以下のとおりです。

view [定義名] {
    match-clients {
    [アクセス制御パラメータ];
    [アクセス制御パラメータ];
    ....;
    };
    [オプション];
    ....;

ゾーン命令
.
.

};

仕組みは意外に単純で、 クライアント のリクエスト元の ノード 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" の記述のために予め用意されている アクセスリスト名 という以下のパラメータを記述することもできます。

アクセスリスト名 意味
any すべてのノードと一致(制限なし)
none すべてのノードと不一致(完全に遮断)
localhost 自ホストのノード
localnets 自ホストが属するサブネット

"match-clients"で利用可能なアクセスリスト名

"localhost" "localnets" の二つのアクセスリスト名は、 構築中のLinuxサーバー のネットワーク設定 WBEL3のネットワーク設定について CentOS3のネットワーク設定について WBEL4のネットワーク設定について CentOS4のネットワーク設定について CentOS5のネットワーク設定について のパラメータを引き継ぎます。

従って、

view lan {
    match-clients {
        192.168.100.0/24;
    };
.
.

と、

view lan {
    match-clients {
        localnets;
    };
.
.

は、 構築中のLinuxサーバー BIND を稼動させる場合には同じ動作をすることになりますが、できれば "localnets" という記述をお勧めします。

サーバー機 NIC を追加して複数のサブネットを設定したり、一つのNICに複数のサブネットを割り当てたりすると、 "localnets" "localhost" は複数の値を持つことになりますので気をつけてください。

なぜなら、例えば サーバー機 を含めた自宅のサブネットを "192.168.100.0/24 から "192.168.200.0/24 に変更した場合でも、 "localnets" と記述しておけば自動的に値が変更されるからです。

また、パラメータの先頭に "!" を付けると、そのパラメータの 否定 を意味するようになります。

そこで、

view lan {
    match-clients {
        localnets;
    };

LAN側に応答させるゾーン

};

view wan {
    match-clients {
        !localnets;
        any;
    };

WAN側に応答させるゾーン

};

という記述になるわけです。

DNSサーバーの構築に、
とても役に立った一冊です

実際には最初の "view lan" のところでLAN側に対する応答が行われると "view wan" は参照されないため、正確には "!localnets" の記述は必要ありません。

しかし、

view lan {
    match-clients {
        localnets;
    };

LAN側に応答させるゾーン

};

view wan {
    match-clients {
        any;
    };

WAN側に応答させるゾーン

};

とだけ記述してしまうと、例えば "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キャッシュによる回答を行わない)

という設定方法になります。

つまり上の設定例のように、

view lan {
    match-clients {
        localnets;
    };
    recursion yes;

LAN側に応答させるゾーン

};

view wan {
    match-clients {
        !localnets;
        any;
    };
    recursion no;

WAN側に応答させるゾーン

};

と記述すると、 LAN 側ではゾーン命令に一致しないリクエストに対してはDNSキャッシュによる回答を試み、 WAN 側ではゾーン命令以外の回答は一切行わなくなります。

WAN空間からのリクエストに対してDNSキャッシュを使用しない理由は、いうまでもなく不正使用を防止するためです。

構築中のLinuxサーバー が正式に「権威あるDNSサーバー」として登録されると、その FQDN グローバルIPアドレス は一般情報として世界中に公開されることになります。

もしWAN空間に対してDNSキャッシュによる回答を有効にしたままにしておくと、仕組み上は ISP などが運営しているエンドユーザー向けのDNSサーバーと同じ振る舞いをしますから、見知らぬ誰かに勝手に利用されてしまう可能性がでてきます。

しかし "recursion no" と設定しておけば、 構築中のLinuxサーバー ドメイン名 "obenri.com" に関する回答以外は行わなくなりますから、一般での利用価値がなくなってしまい、結果的に不正使用が防止されるというわけです。

ところが「自前で賄えるものはできるだけ自前で賄う」という立派なポリシーをお持ちの方などは、「せっかく構築するのだから、WAN空間からでも自前のDNSサーバーをキャッシュサーバーとして使いたい。」と思われるかもしれませんが、それは全くといっていいほど 意味のないことです。

下の模式図をご覧ください。

契約しているISPのDNSサーバーを用いる時の名前解決パケットの流れ
契約しているISPのDNSサーバーを用いる時の名前解決パケットの流れ

通常インターネット接続契約を行うと、ISPから使用するDNSサーバーのIPアドレスが指定されますが、それは通常、ISPが自身で設置しているDNSサーバーです。

ISPはユーザーにできるだけ快適なサービスができるようにするため、図のようにDNSサーバーは クライアント から出来るだけ最短の経路でに到達できる位置に設置されています。

向かって右側は一般的なインターネット接続の例、向かって左側の図は自宅にDNSサーバーを設置している例です。

ISPのDNSサーバーを フォワーダー フォワーダーの設定について(〜9.3.x) として指定している場合の例です。

自宅のDNSサーバーを利用する場合でも、伸びる経路は自宅内のLANの部分だけですから、直接ISPのDNSサーバーを参照する場合と比べても大した違いはありません。

ところが、自宅に設置しているDNSサーバーを外部から利用しようとすると、下の図のように パケット は非常に長い経路を通ることになります。

外出先から自宅のDNSサーバーを用いる時の名前解決パケットの流れ
外出先から自宅のDNSサーバーを用いる時の名前解決パケットの流れ

自宅サーバーはISPのサーバーと異なり、物理的にも論理的にも「インターネットの末端」に設置されているわけですから、パケットはどうしてもこのような長旅を強いられることになります。

この図では二つのISPの間がお互いのルーターで直結されているようになっていますが、実際にはもっと多くの ルーター を経由することになるのが普通です。

これでお解りのとおり、インターネット全体で見た場合の通信帯域への負荷と 名前解決 のレスポンス、そして通信経路の長さによるエラーの発生頻度などを考えれば、無理して自宅のDNSサーバーを利用するよりは、ISPが設置しているDNSサーバーを素直に利用したほうがよいことになります。

というわけですから、WAN側に設定する "view" キーワードには必ず "recursion no" を設定し、DNSキャッシュを利用できないようにしてしまいましょう。

関連セクションへ 関連セクション・ 自宅内DNSサーバーの構築


このページの先頭へ↑

"/etc/named.conf"の例

以上の内容で作成した "/etc/named.conf" は、こちらをクリックすると表示できます。

この テキスト ファイルには余分な文字は入っていませんから、開いてコピー&ペーストで使用するか、 ダウンロード して使用してください。

関連セクションへ 関連セクション・ 自宅内DNSサーバーの構築


このサイトは既に更新を終了していますが、今のところ店じまいの予定はありません。 リンクフリー ですので、趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。
Powered by Apache
”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。
www.centos.org - The Community ENTerprise Operating System