DNSゾーン転送とは？BIND9でプライマリ・セカンダリDNSを設定する方法

こんにちは、InfraAcademyを運営しているryuです。

今回は、DNSゾーン転送の仕組みとBIND9での設定方法を初心者向けに解説します。

DNSを勉強していると、プライマリDNSやセカンダリDNS、AXFR、IXFRといった言葉が出てきます。名前だけ見ると難しそうですが、基本は1台目のDNSサーバーが持つゾーン情報を、2台目へ同期する仕組みです。

私自身、エンジニアとして10年以上サーバーやネットワークに触れてきましたが、DNSは設定項目を暗記するより、どのサーバーが正しい情報を持ち、どこへ同期されるのかを整理した方が理解しやすいと感じています。

この記事では、ゾーン転送の役割から、BIND9を使ったプライマリ・セカンダリ構成、確認方法、うまくいかないときの切り分けまで順番に説明します。

DNSゾーン転送とは？¶

DNSゾーン転送とは、あるDNSサーバーが管理しているゾーン情報を、別のDNSサーバーへ転送する仕組みです。

以前の記事では簡単にDNSのバックアップと説明していました。間違いではありませんが、実際にはバックアップというより、複数の権威DNSサーバーで同じゾーン情報を持ち、可用性を高めるための同期機能と考える方が正確です。

そもそもゾーンとは？¶

DNSのゾーンとは、特定のドメインについてDNSサーバーが管理している範囲です。

例えば example.com のゾーンには、WebサーバーのAレコード、別名を表すCNAMEレコード、メール配送先のMXレコード、DNSサーバー自身を表すNSレコードなどが保存されます。

DNSそのものがまだ曖昧な場合は、先にこちらの記事を読んでおくと分かりやすいです。

【関連記事】DNSとは？名前解決の仕組みを初心者向けに解説

プライマリDNSとセカンダリDNSの違い¶

ゾーン転送では、主にプライマリDNSとセカンダリDNSという2種類のサーバーが登場します。

役割を整理すると、次のようになります。

古い資料では、master / slaveという表記もよく使われています。BIND9では現在も互換性のため使えますが、設定や説明ではprimary / secondary、primariesという表現が使われるようになっています。

セカンダリDNSがあると、プライマリDNSが一時的に停止しても名前解決を継続しやすくなります。

AXFRとIXFRの違い¶

ゾーン転送には、AXFRとIXFRという2つの方式があります。

最初は名前を暗記する必要はありません。全部を転送するか、変更分だけを転送するかの違いです。

セカンダリDNSは、プライマリDNSのSOAレコードに含まれるSerial Numberを確認します。自分が持っているSerial Numberより新しければ、必要に応じてゾーン転送を行います。

そのため、手動でゾーンファイルを変更した場合は、SOAレコードのSerial Numberを更新することが重要です。

BIND9でゾーン転送を設定してみよう¶

ここからは、Ubuntu上のBIND9を使って実際にゾーン転送を設定します。

今回は次の構成を例にします。

BIND9の基本設定がまだ分からない場合は、先にDNSサーバーを1台構築して名前解決できる状態まで進めてください。

【関連記事】BIND9でDNSサーバーを構築する方法

プライマリDNSのゾーンファイルを確認する¶

まず、プライマリDNSに example.com のゾーンを用意します。

例えば /etc/bind/db.example.com を次のように設定します。

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
        2026091401
        3600
        1800
        604800
        86400
)

@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

ns1 IN  A   192.168.100.107
ns2 IN  A   192.168.100.108
www IN  A   192.168.100.50

ここで大切なのがNSレコードです。

プライマリとセカンダリの両方を、このゾーンを担当するDNSサーバーとして登録しています。また、ゾーン内容を変更したら 2026091401 のようなSerial Numberも増やします。

プライマリDNSでゾーン転送を許可する¶

続いて /etc/bind/named.conf.local を編集します。

プライマリDNSの設定例は次のとおりです。

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
    allow-transfer { 192.168.100.108; };
};

allow-transfer には、ゾーン転送を許可するセカンダリDNSのIPアドレスを指定します。

ここはセキュリティ上とても重要です。誰からでもAXFRできる設定にすると、外部からゾーン情報をまとめて取得される可能性があるため、必要なDNSサーバーだけに制限します。

最近のBIND9では、送信側のゾーン転送を明示的な allow-transfer で許可する構成がより重要になっています。

設定ファイルとゾーンをチェックする¶

BIND9を再起動する前に、文法ミスがないか確認します。

まず設定ファイル全体を確認します。

sudo named-checkconf

続いてゾーンファイルを確認します。

sudo named-checkzone example.com /etc/bind/db.example.com

OK と表示されれば、基本的な形式は問題ありません。

実務でも、いきなりサービスを再起動するより、先に named-checkconf と named-checkzone を実行する方が安全です。10年以上エンジニアをしてきた中でも、このような事前確認を習慣にするだけで設定ミスによる切り戻しはかなり減らせます。

セカンダリDNSを設定する¶

次に、192.168.100.108のセカンダリDNSを設定します。

/etc/bind/named.conf.local に次の設定を追加します。

zone "example.com" {
    type secondary;
    file "db.example.com";
    primaries { 192.168.100.107; };
};

primaries で、ゾーン情報を取得するプライマリDNSを指定します。

古い設定例では masters が使われていますが、現在は primaries が推奨される表現です。既存環境で masters を見かけても、すぐに間違いというわけではありません。

セカンダリ側では、ゾーンファイルを手作業で編集しません。BIND9がプライマリから受け取った情報を保存します。

Ubuntuでは、セカンダリ側の書き込み可能なゾーンファイルは通常 /var/cache/bind/ 配下で管理されます。

BIND9を再起動する¶

設定を保存したら、プライマリとセカンダリの両方でBIND9を再起動します。

sudo systemctl restart bind9

状態も確認しておきましょう。

sudo systemctl status bind9

エラーが出ている場合は、先に設定ファイルの文法やゾーンファイルを見直します。

ゾーン転送できたか確認する¶

設定しただけで終わらず、本当にセカンダリDNSが名前解決できるか確認します。

例えば dig を使い、セカンダリDNSへ直接問い合わせます。

dig @192.168.100.108 www.example.com

192.168.100.50 が返ってくれば、セカンダリDNSがゾーン情報を持っていることを確認できます。

許可された環境からAXFRそのものを確認する場合は、次のように実行できます。

dig @192.168.100.107 example.com AXFR

このコマンドがどこからでも成功する状態は避けてください。allow-transfer で許可したセカンダリDNSなど、必要な送信元だけから転送できる構成にします。

ゾーン転送できないときの確認ポイント¶

DNSの設定は、1か所直せば必ず解決するとは限りません。

私がトラブルを切り分けるときは、設定、Serial Number、通信、ログの順番で確認します。

Serial Numberが増えているか¶

プライマリ側のゾーンファイルを変更しても、SOAのSerial Numberが古いままだと、セカンダリ側が新しいゾーンだと判断できません。

変更したらSerial Numberを更新し、named-checkzone でも確認してください。

TCP 53番ポートが通るか¶

通常のDNS問い合わせではUDPを使う場面が多いですが、一般的なAXFRやIXFRのゾーン転送ではTCP 53番ポートを利用します。

ファイアウォールを設定している場合は、プライマリとセカンダリの間でTCP 53番が通るか確認します。

ログを確認する¶

Ubuntu環境では、systemdのjournalからBIND9のログを確認できます。

sudo journalctl -u bind9 -f

ゾーン転送が開始されたのか、拒否されたのか、設定ファイルの読み込みに失敗したのかを確認できます。

Linuxログの見方を詳しく知りたい場合は、こちらの記事も参考にしてください。

【関連記事】Linuxのログ監視方法｜tail・less・journalctlを解説

DNSゾーン転送で覚えておきたいこと¶

DNSゾーン転送は、単にファイルをコピーする仕組みではありません。

プライマリDNSで管理しているゾーン情報をセカンダリDNSへ同期し、複数の権威DNSサーバーで名前解決を継続できるようにする仕組みです。

最初はAXFRとIXFRの違いまで完璧に覚えなくても構いません。プライマリ、セカンダリ、SOAのSerial Number、allow-transfer の4つを理解できれば、基本的な構成はかなり見えてきます。

InfraAcademyでは、DNSだけでなく、IPアドレス、ルーター、Linux、サーバー構築などを実際に操作しながら学べます。

DNSは単体で暗記するより、ネットワーク全体の流れと一緒に学ぶ方が理解しやすい分野です。

[InfraAcademyでLinux・ネットワークを学ぶ]https://engineer-ninaritai.com/)

参考¶

• Ubuntu Server documentation - Domain Name Service
• BIND 9 Administrator Reference Manual