DNSサーバ構築 – 百蔵の部屋

3つの基本

今の仕事の関係でDNSについてある程度の知見が溜まってきたので、忘れない内にここに纏めておきたいと思いこの記事を書いています。

今から表題の通りDNSサーバを構築していきますが、DNSを理解・構築するにはまず3つのサーバに大別して学習すると理解しやすいです。

権威サーバ
ゾーン転送サーバ
キャッシュサーバ

※解説する人によって各用語の呼称に違いがありますので適宜読み替えていただけたらと思います。

キャッシュDNS

上の図の様にエンドユーザが名前解決をしたい時、まずキャッシュDNSに問い合わせます。キャッシュDNSは自分が回答出来る場合は回答し、回答できない場合は権威DNSに問い合わせに行きます。

そして権威DNSの回答結果を成功/不成功を問わずキャッシュします。以降同じ問い合わせが来た場合は、キャッシュを元に回答します。別称ではフルリゾルバと言われます。

権威DNS

権威DNSとはあるゾーン及び、委任しているサブゾーンの情報を管理しているDNSのことです。例えばhoge.jpというゾーンを管理しているとして ……

※一部抜粋
www.hoge.jp.IN     A     192.168.1.1

上の様なゾーンファイルと呼ばれるものを持ち、www.hoge.jpのアドレスを聞かれた場合に192.168.1.1を返すものです。

更にDNSは階層構造になっているという話は聞いたことがあると思います。一番近くのキャッシュDNSはキャッシュに存在しないゾーンへの問い合わせが来た場合は、ヒントファイルというものを元に信頼されるルートサーバに問い合わせ、次に.jpや.workなどの所謂トップレベルドメインと呼ばれるゾーンを管理する権威DNSへ行き、更に目的のゾーンのhoge.jpを管理している権威DNSへ橋渡しされていきます。

逆説的に独自ドメインをインターネットに公開したい場合は、TLDにゾーン情報を登録する必要があることが分かると思います。これを管理している組織をレジストラと呼びます。お金が掛かるので今回は割愛しますが、今まで利用していた方でも初めて名前を知るという人もいるのではないかと思います。

ゾーン転送DNS

先に述べた2つのサーバだけでもDNSの機能自体は実現出来ます。しかしDNSというものは絶対に落としてはならないサービスであり、何重にも冗長をとる構成であることが一般的です。

ゾーン転送DNSは要するに負荷分散兼バックアップです。コピー元のDNSをマスター、転送先をスレーブと呼びます。詳しいことは分かりませんが、マスターでゾーンファイルを編集したりするとシリアルが増加します。スレーブはマスターに対して転送を要求する際、互いのシリアルを比較しマスターの方が大きい場合に同期を行います。

この後実際にそれぞれを構築してみて試験をする時に分かりますが、スレーブに対して問い合わせを行ってもマスターのように振舞います。ちなみに自分の知っている構成はプロバイダ側のスレーブがまず回答をし、スレーブが答えられない状態の時にマスターが回答するという構成でした……

想像に難くないかと思いますが階層構造をとっているのも負荷分散のためです。

構築

ではいよいよDNSサーバを構築していきましょう。まずは権威DNSから立てていきます。サブゾーンの権威DNSとゾーン転送DNS用に複数ホストもしくはVM上での構築になります。

キャッシュ：172.31.46.5
サブゾーン：172.31.47.104
ゾーン転送： 172.31.40.79

権威DNSの構築

BINDをインストールします、試験をする用にdigコマンドも同時にインストールします。BINDのバージョンについては多少の差異ならば問題ないと思います。

# yum -y update
# yum -y install bind bind-utils
# systemctl start named
# named -v
BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) <id:7107deb>

ポート53を開放します。

# firewall-cmd --add-service=dns --permanent
# firewall-cmd --reload

今回管理するゾーンはhoge.jpとします。コンフィグに以下の4行を追記します。

$ vi /etc/named.conf
~ 中略 ~
zone "hoge.jp" IN {
        type master;
        file "hoge.jp";
};

次にゾーンファイルを書いていきます。

$ vi /var/named/hoge.jp
$TTL 1D
@       3600    IN      SOA     ns.hoge.jp. mx.hoge.jp. (
                                2019103119;     serial
                                3H;             refresh
                                1H;             retry
                                1W;             expire
                                1H );           negative cache

        IN      NS      ns.hoge.jp.
        IN      MX 10   mx.hoge.jp.
ns      IN      A       172.31.46.5

www     IN      A       192.168.1.10

以上で権威DNSの構築は完了です。構文チェックして問題が無ければサービスを再起動します。

$ named-checkconf
$ named-checkzone hoge.jp /var/named/hoge.jp
# systemctl restart named

権威DNSの試験

成功すると先程設定したIPアドレスが帰ってくるかと思います。

$ dig @127.0.0.1 www.hoge.jp +short
192.168.1.10

キャッシュDNSの構築

先程構築した権威DNSを今度はキャッシュDNSとして動作させていきます。以降キャッシュDNSをマスター、サブゾーンを管理する委任先をサブホストと呼ぶことにします。

マスタ側のnamed.confのoptionsステートメントに再帰問い合わせの設定を追記します。

$ vi /etc/named.conf
options {
~ 中略 ~
        recursion yes;
        forwarders { 172.31.47.104; };
}

※recursionがnoになっていたら変更する。

ゾーンファイルhoge.jpにも委任先の情報を追記します。これが所謂グルーレコードです。

$ vi /var/named/hoge.jp
~ 中略 ~
sub     IN      NS      ns.sub.hoge.jp.
ns.sub  IN      A       172.31.47.104

次は委任先のサブホストを設定していきます。同様にBINDをインストールして下さい。firewallの設定も忘れずに……

マスター　：172.31.46.5
サブホスト：172.31.47.104

# yum -y update
# yum -y install bind bind-utils

サブホスト側のコンフィグは下記の通りに編集/追記します。

$ vi /etc/named.conf
options {
~ 中略 ~
        listen-on port 53 { 127.0.0.1; 172.31.47.104; };
        allow-query     { any; };
};

~ 中略 ~

zone "sub.hoge.jp" IN {
        type master;
        file "sub.hoge.jp";
};

サブゾーンファイルを作成します。

$ vi /var/named/sub.hoge.jp
$TTL 1D
@       3600    IN      SOA     ns.sub.hoge.jp. mx.sub.hoge.jp. (
                                2019103119;     serial
                                3H;             refresh
                                1H;             retry
                                1W;             expire
                                1H );           negative cache

                IN      NS      ns.sub.hoge.jp.
ns              IN      A       172.31.47.104

www             IN      A       1.1.1.1

キャッシュDNSの試験

構文チェックをして問題が無ければサービスを再起動してからマスター側から試験を行います。

$ dig @127.0.0.1 www.sub.hoge.jp A +short
1.1.1.1 ←が帰ってくれば成功
$ rndc dumpdb
$ cat /var/named/data/cache_dump.db
問い合わせ結果がキャッシュされている筈です

ちなみに今回行っている試験は特殊な状況であることを忘れてはいけません。キャッシュDNSは管理外のゾーンへの問い合わせが来た場合は、ヒントファイルを元にルートサーバに問い合わせるのが通常の動作だからです。

ゾーン転送DNSの構築

自分は面倒なのでゾーン転送用(以下スレーブ) を含めてAWSにインスタンスを3つ用意しておりますが、サブゾーン用のホストをゾーン転送用に代用しても構いません。

まずマスタ側のnamed.confのoptionsステートメントにゾーン転送の設定を追記します。

マスター：172.31.46.5
スレーブ：172.31.40.79

$ vi /etc/named.conf
options {
~ 中略 ~
        listen-on port 53 { 127.0.0.1; 172.31.46.5; };
        allow-transfer { 172.31.40.79; };
};

次にスレーブ側の named.confを編集します。

$ vi /etc/named.conf
options {
~ 中略 ~
        listen-on port 53 { 127.0.0.1; 172.31.40.79; };
};
~ 中略 ~
zone "hoge.jp" IN {
        type slave;
        file "slaves/hoge.jp";
        masters { 172.31.46.5; };
};

ゾーン転送DNSの試験

syslogにエラーが吐かれていなければサービスを再起動しスレーブ側で試験を行います。

$ dig @172.31.46.5 hoge.jp axfr +short
ns.hoge.jp. mx.hoge.jp. 2019103119 10800 3600 604800 3600
ns.hoge.jp.
10 mx.hoge.jp.
172.31.46.5
ns.sub.hoge.jp.
172.31.47.104
192.168.1.10
ns.hoge.jp. mx.hoge.jp. 2019103119 10800 3600 604800 3600
全引き可能なら成功

$ ls /var/named/slaves/
hoge.jp

$ dig @127.0.0.1 www.hoge.jp A +short
192.168.1.10

以上です。

終わりに

最後までお読みいただきありがとうございました。ざっくりと理解するために一部説明を省略しておりますので、全てを理解することは難しいかと思います。皆様のDNSを理解する一助になれたら幸いです。

コメントを残す