セカンダリーDNS（スレーブDNS）の構築方法｜BINDによる冗長化構成を理解する
KoAN
目次
セカンダリーDNS（スレーブDNS）の構築方法
DNSはインターネットや企業システムを支える重要なインフラです。
そのため、DNSサーバが1台しかない構成では、そのサーバが停止した瞬間に名前解決ができなくなるリスクがあります。
この問題を解決するために利用されるのがセカンダリーDNS（Secondary DNS）です。
セカンダリーDNSはプライマリDNSサーバからゾーン情報を自動取得し、障害発生時にも名前解決を継続できるようにする仕組みです。
本記事ではRocky LinuxとBINDを利用してセカンダリーDNSサーバを構築する方法を解説します。
セカンダリーDNSとは
セカンダリーDNSは、プライマリDNSサーバが保持するゾーン情報を複製して保持するDNSサーバです。
以前はスレーブDNS（Slave DNS）と呼ばれていました。
現在はプライマリDNS（Primary DNS）、セカンダリーDNS（Secondary DNS）という表現が一般的になっています。
なぜセカンダリーDNSが必要なのか
DNSサーバが1台だけの場合です。
DNS Server
↓
障害発生
↓
名前解決不可
セカンダリーDNSがある場合です。
Primary DNS
Secondary DNS
片方が停止してもサービスを継続できます。
DNSの冗長化構成
一般的な構成です。
ns1.example.com
192.168.60.10
ns2.example.com
192.168.60.11
両方とも権威DNSサーバとして動作します。
利用者は自動的に利用可能なDNSサーバへ問い合わせます。
ゾーン転送とは
セカンダリーDNSはゾーン情報を自動取得します。
この仕組みをゾーン転送（Zone Transfer）と呼びます。
Primary DNS
↓
Zone Transfer
↓
Secondary DNS
管理者が手動で同期する必要はありません。
AXFRとは
AXFRはゾーン全体を転送する方式です。
AXFR
↓
全ゾーン転送
初回同期時によく利用されます。
IXFRとは
IXFRは差分転送方式です。
IXFR
↓
変更部分のみ転送
通信量を削減できます。
今回の構成
Primary DNS
192.168.60.10
Secondary DNS
192.168.60.11
ドメイン
example.com
Primary DNS側設定
named.confを編集します。
# vi /etc/named.conf
ゾーン定義です。
zone "example.com" IN {
type master;
file "example.com.zone";
allow-transfer {
192.168.60.11;
};
};allow-transferとは
ゾーン転送を許可する相手を指定します。
allow-transfer {
192.168.60.11;
};セキュリティ上非常に重要です。
指定しないと誰でもゾーン転送できる場合があります。
ゾーンファイル例
$TTL 3600
@ IN SOA ns1.example.com. root.example.com. (
2026060801
28800
14400
3600000
86400
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
ns1 IN A 192.168.60.10
ns2 IN A 192.168.60.11
www IN A 192.168.60.20NSレコードを複数登録する
重要なポイントです。
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
これによって利用者は両方のDNSサーバを認識できます。
Secondary DNS側設定
named.confを編集します。
# vi /etc/named.conf
ゾーン設定です。
zone "example.com" IN {
type slave;
masters {
192.168.60.10;
};
file "slaves/example.com.zone";
};type slaveとは
セカンダリーDNSとして動作する指定です。
type slave;
プライマリDNSからゾーン情報を取得します。
mastersとは
プライマリDNSサーバを指定します。
masters {
192.168.60.10;
};ゾーン取得元になります。
slavesディレクトリ
取得したゾーンファイルの保存場所です。
file "slaves/example.com.zone";
BINDが自動生成します。
手動作成は不要です。
設定確認
Primary DNSです。
# named-checkconf
Secondary DNSです。
# named-checkconf
エラーが無いことを確認します。
サービス起動
両サーバで起動します。
# systemctl restart named
ゾーン転送確認
セカンダリー側で確認します。
# ls -l /var/named/slaves/
ゾーンファイルが生成されていれば成功です。
ログ確認
ゾーン転送状況を確認します。
# journalctl -u named
成功例です。
zone example.com/IN:
Transfer completed
digで確認する
Primary DNSへ問い合わせます。
# dig @192.168.60.10 www.example.com
Secondary DNSへ問い合わせます。
# dig @192.168.60.11 www.example.com
両方同じ結果になることを確認します。ゾーン更新の確認
Primary DNS側のゾーンファイルを変更します。
test IN A 192.168.60.30
その後シリアル番号を更新します。
2026060802
namedを再読み込みします。
# rndc reload
数分後にSecondary DNSへ反映されます。シリアル番号が重要な理由
セカンダリーDNSはSOAレコードを確認します。
2026060801
↓
2026060802
番号が増加していれば更新を開始します。
変更してもシリアル番号を更新しなければ転送されません。
TCP53番ポートが必要
通常のDNS問い合わせはUDP53番です。
しかしゾーン転送はTCP53番を利用します。
ファイアウォール設定に注意してください。
ファイアウォール設定
# firewall-cmd --add-service=dns --permanent
# firewall-cmd --reload両サーバで設定します。
よくあるトラブル
allow-transfer未設定
ゾーン転送が拒否されます。
シリアル番号未更新
変更内容が反映されません。
TCP53番遮断
ゾーン転送に失敗します。
masters設定ミス
Primary DNSへ接続できません。
SELinux制限
slavesディレクトリへ書き込めない場合があります。
実務で覚えておきたいポイント
- セカンダリーDNSは冗長化のために構築する
- ゾーン転送で自動同期する
- allow-transferは必ず制限する
- シリアル番号管理が重要
- TCP53番ポートが必要
- NSレコードは複数登録する
まとめ
セカンダリーDNSはプライマリDNSのゾーン情報を複製し、DNSサービスの可用性を向上させる仕組みです。
BINDではtype slaveとmasters設定により簡単に構築できます。
また、ゾーン転送にはAXFRやIXFRが利用され、シリアル番号によって変更を検知します。
実運用ではDNSサーバの冗長化は必須に近い要件であり、セカンダリーDNSの理解はDNS管理者にとって重要な知識となります。
