内部DNSサーバがある環境でのDNSルーティングの適用

概要

ここで言う「DNSルーティング」とは、一部のブロードバンドルータに実装されている、以下のような機能のことです(メーカによる説明は、例えばここ(PDF))。

ブロードバンドルータに複数の対外接続(例えばISPとのPPPoEセッションとFLET'S SQUAREとのPPPoEセッション)がある。
ブロードバンドルータのDNS proxy機能が有効になっている。
内部のクライアントからのDNS queryはブロードバンドルータのDNS proxyに向けられる。
ブロードバンドルータのDNS proxyは、特定のドメイン名(例えば.flets)については特定のrecursiveサーバ(例えばFLET'S SQUAREのDNSサーバ)にqueryし、それ以外はデフォルトのrecursiveサーバ(例えばISPのrecursiveサーバ)にqueryする。
ブロードバンドルータのフォワーディングテーブルに
- destinationが上で述べた特定のドメイン名についてrecursiveサーバにqueryして得られた結果のA RRが示すIPアドレス(ここまでの例に従えばFLET'S SQUAREのサーバのIPアドレス)
- next hopあるいはegressインターフェースを指定した内容(例えばFLET'S SQUAREとのPPPoEセッション)
とするエントリを追加する。(ここの説明はちょっと端折っています。正確なことはブロードバンドルータのマニュアルを参照して下さい。)
その結果、特定のドメイン名(例えば.flets)のホスト行きのパケットは指定した対外接続(例えばFLET'S SQUAREとのPPPoEセッション)を経由し、それ以外はデフォルトの対外接続(例えばISPとのPPPoEセッション)を経由させることができる。

この説明は、ある特定機種の説明書に基づく理解によるものなので、機種によっては細部に差異があったり同じ名称で異なる機能が提供されている可能性もあります。
一方、ブロードバンドルータでNATを有効にし、内部のホスト/ネットワークを外部には隠蔽する構成では、内部向けDNSサーバで、recursiveネームサービスと、内部のホスト/ネットワークに関するauthoritativeネームサービスを提供する構成も考えられます。ところがこの構成では、クライアントはrecursiveネームサーバとしてブロードバンドルータではなく内部向けネームサーバをアクセスする必要があるので、単純にはDNSルーティングを適用することができません。そこでこのメモでは、内部向けDNSサーバとDNSルーティングを両立させる手法について説明します。

設定例

想定環境

ここでは諸条件を以下のように想定します。

外部アドレス: ISPから10.20.30.40を固定割り当てされている。
ドメイン名: example.jpという独自ドメインを運用している。
DNSルーティングの対象とするドメイン名: .flets
内部アドレス: 192.168.0.0/24を割り当てている。ブロードバンドルータのアドレスは192.168.0.254とする。
DNSサーバ: 以下に設定例を挙げるBIND 9のサーバで、ブロードバンドルータの固定masqueradeによりexample.jpの外部向けネームサービスを提供している。また、内部向けにrecursiveサービスおよびexample.jpと0.168.192.in-addr.arpaの2つのゾーンのauthoritativeサービスを提供している。

named.confの設定例


acl internal {
        192.168.0.0/24;
};
options {
        allow-query {
                internal;
                localhost;
        };
};
view "internal" IN {
        match-clients {
                internal;
                localhost;
        };
        zone "localhost" IN {
                type master;
                file "internal/localhost";
        };
        # localhostやprivateの逆索きを適切に
        zone "example.jp" IN {
                type master;
                file "internal/example.jp";
        };
        zone "0.168.192.in-addr.arpa" IN {
                type master;
                file "internal/0.168.192.in-addr.arpa";
        };
        zone "flets" IN {
                type forward;
                forward only;
                forwarders {
                        192.168.0.254;
                };
        };
};
view "exhibit" IN {
        zone "." IN {
                type hint;
                file "/dev/null";
        };
        zone "example.jp" IN {
                type master;
                file "exhibit/example.jp";
                allow-query {
                        any;
                };
        };
};

要点はzone "flets"について、type forwardとしてforwarderをブロードバンドルータに設定していることです。また本題とは関係ありませんが、DNS amplification attackに加担しないために、allow-queryを内部だけに設定し、view exhibitのzone "example.jp"だけ、allow-queryをanyに設定してworldwideからのqueryを許可していることと、同じくview exhibitでrootゾーンについてはネームサービスを提供しないように、file "/dev/null"としています。

DNS amplification attackについての参考資料

バリエーション

この設定のバリエーションを考えてみます。独自ドメインは運用せず、このDNSサーバで外向けのネームサービスは提供しないことにすれば、viewディレクティブによるsplit DNSは必要なくなります。しかし、DNS amplification attackの対策や内部ホストに関する情報を漏洩させないために、allow-queryによるアクセス制限は、依然、必要です。上の設定例では、"flets"というドメイン名をDNSルーティングの対象とするという設定をDNSサーバとブロードバンドルータに重複して設定することになるので、zone "flets"の中ではなく、optionsの中で、自分がauthorityを持っている内部ゾーン以外に関するすべてのqueryをブロードバンドルータにforwardするという設定も考えられます。