FreeBSD DNS サーバ その２

私の自宅は大阪某所なので、よく遊びに行くところとして、大阪は当然、京都、神戸、奈良、和歌山、ちょっと頑張って、福井、滋賀、兵庫、香川、徳島あたりまで車で日帰りツアーによく出かけます。中でも京都市内は大阪靭公園あたりと同じくらい良く訪れる地となっています。京都では美観対策の一環として、電柱などが地中に埋設されているケースが沢山あります。加えて、道しるべなどの本来棒状の柱に取り付けられているものも、地上にあったりします。( 地中だと見ることができないので 🙂 ) 電線のない町では思わず空を見上げて気持ちよくなります。

cooperate wide DNS implementation
DNS acl
Windows Active Directory DNS / Dynamic Update
forwarders in views
GEO-IP
zone 転送 in views
response-policy
動作確認

cooperate wide DNS implementation

さて、前回に続いて DNS の話題です。前回は家庭内の非常に小さな設定でしたが、会社レベルの大きな設定の話をしてみたいと思います。私の会社でも ISC BIND918 を使用しているのですが、アジア、ヨーロッパ、アメリカの3か所のデータセンターに２つずつの DNS サーバをおいて、そのエリアの各オフィスからそれらの DNS サーバーを共有して使用しています。ISC BIND918 には view という概念が存在し、各 view は前回設定したご家庭の DNS サービス1つに相当します。１つの DNS サーバを見ると、DNS が走っているホストは１つ、プロセスも１つ、でも仮想的に複数の DNS が個別の設定で動いているように見せることができます。１つの view の中には１つの DNS の設定が丸々入っています。DNS のアクセスリストで定義されたソース IP アドレスにマッチした DNS クライアントからの問い合わせは、そのアクセスリストがマッチした view の設定を使用して応答を組み立てます。今回はお試しで view の定義を行ってみます。この例では、pokemon さんを view OSAKA に、package さんを view SAOPAULO のクライアントに仕立てます。home.jf3vqb.net の DNS リソースは共通に使用し、それ以外のインターネットのリソースは pokemon さんは大阪で使用するのにベストであろうと思われるレスポンスを、package さんにはサンパウロで使用するのにベストであろうと思われるレスポンスを組み立てることができるようにすることを設計の目的とします。加えて、home.jf3vqb.net ドメインの MX レコードを大阪では pokemon.home.jf3vqb.net と package.home.jf3vqb.net、dhcp.home.jf3vqb.net の３サイトへこの順番で、サンパウロでは、package.home.jf3vqb.net と pokemon.home.jf3vqb.net、dhcp.home.jf3vqb.net の３サイトへこの順番で登録します。各 view の定義ファイルは別ファイルとして取り扱いをしやすくしたいと思います。基本 named.conf が設定ファイルですので、それ以外のファイルがある場合は、それらのファイルを named.conf に定義してやります。こんな感じです。プライマリもセカンダリも基本同じ方針で行きます。

view を使用するときには全ての zone 構成が view の内部に定義されている必要がありますので、named.conf の zone の定義を全てコメントアウトします。または見やすいように削除します。今回各 view で使用したファイルは２種類ずつにしました。*-client.conf ファイルは view に属する DNS クライアントの定義です。今回の設計の方針から、pokemon を OSAKA に、package を SAOPAULO にします。因みに他のマシンはどの view にも属しませんが、ここでは無視しておきます。設定は上から順に処理されてゆきますので、どの view にも属さない Windows PC は問い合わせを処理する設定がないので、問い合わせ自体を拒否されます。本来なら 192.168.0.0/24 をカバーする view HOME などを作っておいて、OSAKA -> SAOPAULO -> HOME と設定の最下部に置いておいて pokemon や package 以外をカバーすべきなのでしょうが、家庭での view はあくまでもテストなので、深入りはせずにおきます。

M$ が嫌いなのではなく、設定がない Windows クライアントからな問い合わせなので拒否されました 🙂

DNS acl

*-client.conf ファイルはこんな感じです。思い出してください、各ホストのリゾルバは 127.0.0.1 が最初に書かれています。ですので、pokemon のループバックアドレスは OSAKA に属する必要があります。同じ理由で、package のループバックは SAOPAULO に属する必要があります。

前ステップでコメントアウト、あるいは削除した zone の定義を丸々 COMMON.conf にコピーして他のファイルから include 文で使用できるようにします。コメントも何もかも一切コピーしたのでわかりにくいかもしれませんが、こんな感じです。

view OSAKA と SAOPAULO の定義ファイルに COMMON.conf を挿入します。view OSAKA の定義は OSAKA.conf でしており、こんな感じになります。

Windows Active Directory DNS / Dynamic Update

余談ですが、ある程度の規模の会社のネットワークでは、使いたくなくても M$ Windows の Active Directory を使っている会社がほとんどだと思います。その場合は、COMMON.conf などに AD サーバーを conditional forwarders で定義したりすると思います。ですので、BIND918 の zone の定義に type primary となる zone はないんだろうと思います。勿論 bind918 のみに存在する zone があればそれらは primary になります。home.jf3vqb.net が M$ AD のドメインと仮定した場合、こんな感じになります。bind9 のマニュアルによると、forwarders は書かれた順番に使われるのではなく、レスポンスの良いものを優先して使用するようになっているようです。

Windows のネットワークでは DNS ダイナミックアップデートが重要になります。この仮想ドメインの例だと home.jf3vqb.net の SOA ゾーンや NS レコードは全て Windows ドメインコントローラを指し示しますので、必要なダイナミックアップデートは BIND918 ではなく、Windows DC に対して行われることになります。逆引きのダイナミックアップデートを考えると、この例では BIND918 に対して行われます。ところが BIND918 のデフォルトではセキュリティ上の理由からダイナミックアップデートを受け付けないようになっています。Windows PC の逆引きを提供したい場合は、逆引きを受け付けるようにする必要があるかもしれません。

話を元に戻します。COMMON.conf は各 view 共通なので、SAOPAULO.conf にも同じように書き加えます。package さんも view を使って書き換えたので pokemon さんと同じように変更します。一点注意が必要なのがセカンダリ DNS として作成されるキャッシュファイルの取り扱いです。プライマリでは同じファイルをデータベースとして使用しますので、各 view で同じ記述を使用できます。ところがセカンダリではデータ転送も view 毎に行われるので、同じファイル名を使用すると運悪く同時にアップデートした場合にファイルが破損する可能性があります。そのために別ファイル名を使用するようにします。

forwarders in views

次は forwarders の設定です。view OSAKA は大阪で使用する DNS クライアントに対してベストであろうと思われるレスポンスを作る必要があります。ですので、view OSAKA で使用する forwarders に定義する DNS サーバーのアドレスは大阪近辺に設置されている DNS サーバーを使用します。最近の DNS は GEO-IP をサポートしているサイトが多くなってきていますので、GEO-IP をサポートしていない DNS サーバーを見つける作業が必要になります。同様に view SAOPAULO でも GEO-IP をサポートしていない SAOPAULO 近辺にある DNS サーバーを使用する必要があります。この作業を行う上で参考になるサイトがこちらです。このサイトでは各国で DNS として稼働しているサイトのリストが随時アップデートされてデータとして使用することができます。ただし、提供されるサイトは無償、あるいは無許可で使用できるサイトとは限りません。ですのでアクセスを拒否されることもないとは限りません。そのような場合は、forwarders に使用しないようにしましょう。今回選択したサイトはこちらです。

アクセスが拒否されるかもしれないので、複数指定する必要があります。またアクセスが拒否されたら使用しないようにします。

GEO-IP

また話がそれてしまいますが、GEO-IP をサポートしているサイトを使用して何が困るのでしょうか？ GEO-IP をサポートしている DNS A が韓国にあったとします。このサイトを日本にある DNS クライアントから直接使用するのであれば、日本での使用に適した DNS レコードを返してくれるでしょう。これが GEO-IP の仕組みです。この DNS A を forwarders として日本にある私たちの DNS サーバーに使用したとしましょう。この私たちのサーバーを韓国のクライアントから使用した場合に、韓国のクライアントは日本に適したサイトを、つまり韓国にはあまり適していない DNS リソースを使うことになり、韓国のクライアントはネットワークアクセスが遅くなるということになります。なぜなら DNS A にアクセスしてくる IP アドレスは韓国ではなく日本のアドレスとなるからです。このような事態を防ぐために GEO-IP をサポートしていない DNS を fowarders に使用することが必要になります。GEO-IP をサポートしているかどうかは nslookup を使用して簡単に調べられます。これは方法のほんの一例ですが、outlook.office365.com のアドレスを view SAOPAULO の forwarders に書いた DNS に問い合わせてみます。

M$ のデータセンターには近所の空港の IATA コードをホスト名につけています。日本からアクセスして、CPQ を返してきますので、この DNS は GEO-IP をサポートしていないと思われます。因みに CPQ はブラジルの空港です。GEO-IP をサポートしているならば、ITM-efz.ms-acdc.office.com か少なくとも HND-efz.ms-acdc.office.com が返ってくるはずです。またまた因みにですが、ITM は伊丹、HND は羽田です。最後の設定に移ります。MX レコードの設定です。まず、view OSAKA で設計通り MX レコードを作成します。

dhcp さんの登場です。非常に古い物理マシンです。Vmware が動いている Windows PC が Windows Update で再起動してしまい、pokemon さんや package さんがクラッシュしてしまいました 🙁

zone 転送 in views

さて問題です。プライマリ DNS のデータを書き換えて、シリアル番号を大きくして、 rndc reload を実行しました。そうすると、セカンダリにも同じ変更が転送されます。のはずですが、実際転送は行われません。何故か？実はプライマリ/セカンダリの転送も view に影響されます。プライマリの転送を許可したアドレスとして 192.168.0.253 を指定しています。このアドレスは SAOPAULO のアドレスとして定義しています。ですので、OSAKA のデータの転送を行うのであれば、package さんに view OSAKA に属したアドレスを持たせて、そのアドレスから転送を行うようにする必要があります。まず、OS から変えてみましょう。pokemon さんに 192.168.0.252 を、package さんに 192.168.0.251 をインターフェースに割り当てます。

それらの設定を適応します。再起動でも大丈夫です。

続いて named.conf に新しい IP アドレスを指定して、DNS を再起動します。

次に各 view のアクセスリストを修正します。

最後に各 view のプライマリアドレスと、転送許可アドレス、そして、転送ソースアドレスを修正加筆します。こんな感じです。

では、データファイルのシリアル番号を大きくします。

新しいアドレスは既に root 権限でバインドしていますので、設定を読み直します。そうすると、セカンダリの osaka-home-xxxx と saopaulo-home-xxxx ファイルのタイムスタンプが変わるので、転送が起きてデータがアップデートされたことがわかります。

では、MX レコードを確認します。さて困りました。MX レコードの順番が view OSAKA と SAPAULO で同じです。そりゃそうです。同じデータファイルを使っているので 🙁

response-policy

解決策としてまず思い浮かぶのは、OSAKA と SAOPAULO でマスタファイルを別々にして別個に MX レコードを書き込む方法が簡単そうです。でも考えてください。この DNS サーバを使用するオフィスが 100 あるとすると、変更があるたびにこの 100 個のマスタファイルを全て編集したいですか？私はお断りです 🙂 そこで、便利な機能が response-policy です。response-policy に定義された zone は本来の zone データと異なる応答をすることができます。今回はこの MX レコードを response-policy で view SAOPAULO で使用してみたいと思います。まず、response-policy で使用する zone ファイルを作成します。

この response-policy を view SAOPAULO に適応します。重要なのは view OSAKA の通信は view OSAKA に定義された IP アドレス間のみで完結する必要があります。同様に view SAOPAULO の通信は view SAOPAULO に定義された IP アドレス間のみで完結する必要があります。

スプレッドシートに整理してアドレスを割り当てないと view の数が増えてくると頭がウニになってしまいます 🙂

結構複雑になってしまいました。では、設定を読みこませて動作確認してみましょう。まず pokemon さんから行います。pokemon さんは view OSAKA のデータが見えれば OK です。

どのインターフェースに問い合わせても期待通りの MX レコードを返してくれます。では package さんもテストしてみます。

動作確認

いずれのアドレスへの問い合わせに対しても package が最小の値を持っていますので、期待通りと言えます。最後にそれぞれの forwarders の動作確認をしてみます。pokemon さんは大阪に適したサイトのアドレスが得られれば OK のはずです。先ほどと同じように M$ のデータセンターを使って調べてみます。

ITM となっており、4ms 程度なので、まずまずというところでしょう。package さんはサンパウロに適したサイトのアドレスが返ってくれば OK のはずです。

CPQ となっており、ping は 280ms 程度となっています。package さんはサンパウロ用の DNS ですが、日本にあります。ですので、サンパウロのクライアントからであれば CPQ はまずまずと言えるはずです。因みに、サンパウロに置いている iPXE のサーバから同じアドレスに ping してみました。

いかがでしたでしょうか？日本の DNS サーバーにサンパウロのクライアントの面倒を見させるのはちょっとクレージーと思いますが、数値的にわかりやすくするために普通はありえない状況を再現てみました。もし、Windows Active Directory 統合 DNS を使用していて、なんだか遅いなぁ？と思っているそこの管理者のあなた、ちょっとした細工で皆さんに感謝されるかもしれません 🙂 Wndows AD の DNS は Windows 環境内のみでの使用にするのもいいかもしれません。

雨の日に訪れる京都錦市場は、人もいつもより少なく、コロナの影響も相まって、落ち着いた感じの傘いらずのお散歩コースとしてお勧めです。よく使わせてもらう駐車場は寺町御池あたりにある地下駐車場がお決まりになっています。地上にある目印でいうと、京都市役所のすぐ足元にあたりになると思います。駐車場は東西に長く御池通の地下にあり、駐車場の東の端の出口が地下街に続いており、その地下街から錦市場の入り口まで傘いらずで歩いてゆけます。錦市場の通りに入ってまず最初に目に入るのが本能寺の石碑です。ここが本能寺かぁ？と思いきや、本能寺の変があった本能寺はここから少し離れているそうで、そちらにも石碑のみが残っているそうで、こちらの本能寺は後に再建されたそうです。錦市場を南にずずっと歩いてゆくと、左手に錦天満宮があります。こちらは錦市場を訪れるたびに訪れて、財布をひっくり返して小銭でお賽銭にしておりました。こちらは、鳥居が周りのビルにメリ込んでいるということで有名です。自前の写真はなさそうでしたので、ネット検索で探してみてください。