【DNS入門 第7回】権威DNSサーバーの運用 ― ゾーン転送、TTL設計、安全な変更手順

「プライマリのゾーンを直したのに、セカンダリが古いままなんですけど…」
「来週サーバーを移すんですが、DNSはいつ切り替えればいいですか？」

権威DNSサーバーの運用で、いちばん事故が起きやすいのは変更作業です。しかも、DNSの事故はキャッシュの影響ですぐには元に戻せないのが怖いところです。

第5回・第6回では、ゾーンに書くレコードを見てきました。第7回では、そのレコードを置く権威DNSサーバーをどう運用するかを扱います。複数台での冗長化、ゾーン転送の仕組み、TTLの設計、そして安全な変更手順です。

---

プライマリとセカンダリ

権威DNSサーバーは、止まるとそのドメインの名前が引けなくなるため、複数台で運用します。

• プライマリ：ゾーンの元のデータ（ゾーンファイルやデータベース）を持ち、変更を行うサーバー
• セカンダリ：プライマリからゾーンの写しを受け取るサーバー

以前は「マスター／スレーブ」と呼ばれていましたが、現在の用語集RFC 9499ではプライマリ／セカンダリが使われ、BINDの設定もtype primary;、type secondary;と書きます。

両者はどちらも権威のある同じ答えを返し、問い合わせる側からは区別できません。NSレコードには両方を載せます。書き換えるのはプライマリだけで、セカンダリは転送で同じ内容になります。

なお、AD統合ゾーンはADの複製でどのドメインコントローラーでも更新でき、Route 53などのマネージドDNSは複製の仕組み自体を利用者から隠しています。

---

ゾーン転送：AXFR・IXFR・NOTIFY

セカンダリがプライマリからゾーンの写しを受け取ることを、ゾーン転送と呼びます。

1. プライマリでゾーンを更新すると、NOTIFY（RFC 1996）でセカンダリに変更を知らせる
2. 知らせを受けたセカンダリは、プライマリにSOAを問い合わせる
3. シリアル番号が自分の持つものより大きければ、転送を要求する

転送には、ゾーン全体を送るAXFR（RFC 5936）と、変更分だけを送るIXFR（RFC 1995）があり、どちらもTCPを使います。NOTIFYが届かなくても、セカンダリはSOAのREFRESHの間隔で自分から確認します。変更の検知は、NOTIFY（すぐ）とREFRESH（定期）の2通りというわけです。

ゾーン転送を誰にでも許さない

ゾーン転送を誰にでも許すと、ホスト名を含むゾーンの中身を丸ごと取得されてしまいます。社内のサーバー構成が外から丸見えになるので、攻撃者にとっては格好の下調べ材料です。

転送はセカンダリのアドレスとTSIGの鍵で限定し、外部からdig AXFR（Windowsはnslookupのls -d）で転送できないことを確認しましょう。

ポイント
・NOTIFYで知らせ、シリアルが増えていれば転送する
・全体のAXFR、差分のIXFR。どちらもTCP
・転送はセカンダリだけに許可する。外部から試して確認

---

シリアル番号の付け方と戻し方

冒頭の「プライマリを直したのにセカンダリが古いまま」は、ほぼこれが原因です。セカンダリはシリアルが増えたときだけ転送します。上げ忘れると、プライマリを直してもセカンダリは古いままという、古典的な事故になります。

全台のシリアルは、1台ずつ比べて確認します。

$ dig @ns1.example.jp example.jp SOA +short
$ dig @ns2.example.jp example.jp SOA +short

PS> (Resolve-DnsName example.jp -Type SOA -Server ns1.example.jp).SerialNumber

• 付け方：YYYYMMDDnn（年月日＋その日の通し番号2桁、RFC 1912）が分かりやすい。1日100回まで。自動で採番するツールやUNIX時刻を使う方式もある
• シリアルは32ビットの循環する数で、「大きい」の判定はRFC 1982の規則による。単純に小さい値へ戻すと、セカンダリは「古い」とみなして転送しない

誤って大きくしすぎたシリアルを戻す手順

たとえば、日付を打ち間違えて2026123101にしてしまい、2026092502に戻したいとします。

1. 2026123101 + 2147483647 = 4173606748に設定する（2^32を超えたら4294967296を引く）→ すべてのセカンダリに転送されたことをSOAで確認
2. 2026092502に設定する → 再びすべてのセカンダリへの転送を確認

セカンダリをすべて自分で管理しているなら、BINDのrndc retransfer example.jpでシリアルに関係なく転送し直す方法もあります。外部のセカンダリサービスを使っている場合は、上の2段階の手順が確実です。

---

TSIGとXoT

ゾーン転送の相手を確かめ、中身を守る仕組みです。

# 共有鍵を作る（プライマリとセカンダリで同じ鍵を持つ）
$ tsig-keygen -a hmac-sha256 xfr-key > /etc/bind/xfr-key.conf

# プライマリの named.conf（抜粋）
include "/etc/bind/xfr-key.conf";
zone "example.jp" {
    type primary; file "example.jp.zone";
    allow-transfer { key "xfr-key"; };
    also-notify { 198.51.100.53; };
};

# セカンダリの named.conf（抜粋。XoT なら tls を付ける）
zone "example.jp" {
    type secondary; file "example.jp.zone";
    primaries { 192.0.2.53 key "xfr-key"; };
};

• TSIG（RFC 8945）：共有鍵によるメッセージの署名で、ゾーン転送・NOTIFY・動的更新の相手が本物で、改ざんされていないことを確かめる。内容の暗号化はしない。IPアドレスだけの制限より確実
• XoT（DNS Zone Transfer over TLS、RFC 9103、2021年）：ゾーン転送をTLS（TCP/853）で暗号化する。ゾーンの中身を経路上で読まれたくない場合に使う。TSIGと組み合わせて使える（BIND 9.18以降のprimaries { ... tls 名前; }等）

---

TTLの設計

TTLは「変更の反映の速さ」と「問い合わせの量」のトレードオフです。レコードの性格ごとに目安を持っておきましょう。

レコード	TTLの目安	考え方
NS、NSのA/AAAA（グルー）	86400秒（1日）前後	めったに変えない。短くすると問い合わせが増えるだけ
通常のA/AAAA/CNAME	3600秒（1時間）	変更の反映の速さと、問い合わせの量のバランス
切り替えを予定しているもの、DNSで切り替えるフェイルオーバー	60〜300秒	早く反映させたいものだけ短くする
MX、TXT（SPF・DKIM・DMARC）	3600秒前後	変更は計画的に行える
SOAのMINIMUM（ネガティブキャッシュ）	300〜3600秒	「追加したのに引けない」時間の上限
Route 53 エイリアス（AWSのリソース宛て）	指定できない	ターゲット側の値が使われる（ELBは60秒）

TTLを短くすると変更はすぐ反映されますが、キャッシュが効かず、権威DNSへの問い合わせが増え、権威DNSが止まったときの影響もすぐに出ます。「普段は長め、変更の前だけ短く」が基本です。

なお、リゾルバーによってはTTLの下限・上限を独自に設けているため、TTLどおりに消えるとは限りません。

---

変更作業の手順：移行前にTTLを下げる

ここが第7回でいちばん大事なところです。Webサーバーの移設などで、Aレコードの値を変える場合の手順を見てみましょう。

時点	作業	確認
作業の数日前	対象レコードのTTLを下げる（例：86400→300）	すべての権威DNSで新しいTTLが返る
旧TTLの時間以上待つ	古いTTL（例：1日）でキャッシュされた分が消えるのを待つ	待たずに切り替えると、最大で旧TTLの間は古い値が残る
切り替え当日	レコードの値を新しいIPアドレスに変える	全台で dig @ns1 ... +norec（Resolve-DnsName -NoRecursion -Server）、SOAのシリアル
切り替え＋新TTL	大半のキャッシュが新しい値になる	新サーバーへのアクセスが増え、旧サーバーへのアクセスが減る
数日〜1週間	旧サーバーを止めずに残す	TTLを守らないクライアント・アプリケーションの対策
安定した後	TTLを元の値に戻す	戻し忘れると問い合わせが増えたまま

ポイントは、値を変える時点で、キャッシュに残る旧IPの寿命がすでに5分以下になっていることです。これなら、万一切り替えに問題があっても、元の値に戻せば5分程度で戻ります。

よくある失敗は、TTLを下げた直後に値を変えてしまうことです。TTLを下げる前に1日のTTLでキャッシュされた分は、下げた後も最大1日残ります。「旧TTLの時間以上待つ」を省略してはいけません。

補足が2つあります。

• 新しく作る名前は、作る前に問い合わせない。「存在しない」がネガティブキャッシュに残るため（第3回）
• DNS事業者の移行でNSを変えるときは、親ゾーン側のNSのTTLは自分では変えられないため、しばらく新旧の両方で同じ内容を返し続ける（第12回 問2）

---

動的更新

動的更新（RFC 2136）は、ゾーンファイルを手で編集する代わりに、ネットワーク越しのメッセージでレコードを追加・削除する仕組みです。

身近な例はADです。

• クライアントは自分のAを登録する
• ドメインコントローラーはSRVを登録する
• DHCPサーバーは、クライアントの代わりにA・PTRを登録する

AD統合ゾーンでは「セキュリティで保護された更新のみ」を選び、Kerberosを使うGSS-TSIG（RFC 3645）で認証します。LinuxではnsupdateとTSIGの鍵を使います。

注意したいのは、BINDでは変更がジャーナル（.jnl）に記録されるため、動的更新のゾーンファイルを直接編集してはいけないことです。手で直すときはrndc freezeで更新を止めて編集し、rndc thawで再開します。残り続ける古いレコードは、スカベンジング（第10回）で整理します。

---

スプリットホライズン

スプリットホライズン（スプリットDNS）は、問い合わせ元によって、同じ名前に違う答えを返す構成です。社内からはwww.example.jpに社内のアドレス、社外からは公開アドレスを返す、社内向けの名前を外に見せない、などに使います。

acl "internal" { 203.0.113.0/24; };
view "internal" {
    match-clients { internal; };
    zone "example.jp" { type primary; file "internal/example.jp.zone"; };
};
view "external" {
    match-clients { any; };
    recursion no;
    zone "example.jp" { type primary; file "external/example.jp.zone"; };
};

実現方法はいくつかあります。

• BINDのview（上の例。viewを使うと、すべてのゾーンをいずれかのviewに入れる）
• Windows ServerのDNSポリシー
• 社内DNSと公開DNSを別のサーバーに分ける
• Route 53のプライベートホストゾーン（第10回）

便利な反面、2つのゾーンを二重に管理することになり、片方だけの更新漏れが起きやすいのが弱点です。「社内からだけ引けない」「VPN接続中だけ違う」といった分かりにくい障害の原因にもなります（第11回）。どちらのviewで答えるかは、問い合わせ元のアドレスだけで決まることを覚えておきましょう。

---

ヒドゥンプライマリ

ヒドゥンプライマリ（hidden primary、隠れたプライマリ）は、プライマリをNSレコードに載せず、インターネットからの問い合わせに答えさせない構成です。

• プライマリはゾーンの編集とセカンダリへのゾーン転送だけを担当し、外からの問い合わせにはNSに載せたセカンダリだけが答える
• プライマリを外部から見えない場所に置けるため攻撃を受けにくく、ゾーンの編集や署名（DNSSEC、第9回）を安全な場所で行える
• セカンダリには、自社の別拠点のサーバーのほか、エニーキャストで運用されているDNS事業者のセカンダリサービスも使える
• 設定では、プライマリのallow-transferとNOTIFYの送り先をセカンダリに限定する

プライマリが止まっても、セカンダリはSOAのEXPIREまで答え続けるため、その間に復旧すればよいという余裕も生まれます。ただし、止まっていることに気づかなければ意味がないので、監視は欠かさないようにしましょう。

---

エニーキャスト

エニーキャストは、同じIPアドレスを複数の拠点から同時に経路広告し、利用者を経路上いちばん近い拠点へ届ける仕組みです。

DNSとの相性が良く、ルートサーバーは13の名前（12の運用組織）に対して、世界の2,000を超える拠点（2026年9月25日時点で2,045）がエニーキャストで動いています。TLD、Route 53などのDNS事業者、8.8.8.8などの公開リゾルバーも同じ方式です。

• 近い拠点が答えるため応答が速い
• DDoS攻撃の通信も各拠点に分散される
• 1拠点が止まっても、経路が切り替わって別の拠点が答える

注意点は、拠点のDNSが異常なのに経路広告を続けると、その周辺の利用者だけ名前が引けなくなることです。DNSの監視と経路広告を連動させます。どの拠点が答えたかはdig +nsidで確かめられます。

---

DNS製品の現在

主なDNS製品の状況です（2026年9月時点）。

製品	役割	現在の版（2026年9月）	特徴
BIND 9	権威・キャッシュ	9.20系（安定版、2028年まで）。9.18系は2026年6月でサポート終了。9.22は未リリース	最も広く使われる。機能が豊富
Unbound／NSD	キャッシュ／権威専用	Unbound 1.26、NSD 4.15	NLnet Labs。軽量、DNSSEC検証に強い
Knot DNS／Knot Resolver	権威／キャッシュ	Knot DNS 3.6、Knot Resolver 6.4	CZ.NIC。高性能、DNSSECの自動運用
PowerDNS	権威・キャッシュ・負荷分散	Authoritative 5.1、Recursor 5.4、dnsdist 2.1	データベースやAPIでゾーンを管理
Windows Server DNS	権威・キャッシュ	Windows Server 2025	AD統合ゾーン。2026年6月からDNSサーバーのDoHに対応
dnsmasq／CoreDNS	小規模のキャッシュ・DHCP／Kubernetes	dnsmasq 2.93、CoreDNS 1.14	ルーター・仮想化基盤／Kubernetesの標準
Infoblox 等のDDI製品	DNS・DHCP・IPアドレス管理の統合	—	画面とAPIで一元管理。大規模な社内網で採用

版は各開発元の公式サイトで確認したものです。Linuxのディストリビューションに含まれる版は、上流の版より古い番号のまま修正を取り込んでいることが多いため、配布元のサポート期間で判断します。

---

選び方と、権威とキャッシュの分離

用途	選択肢の例	選ぶときの観点
公開ゾーンの権威DNS	Route 53 等のマネージドDNS、NSD・Knot DNS・BIND＋セカンダリサービス	可用性（エニーキャスト）、DNSSEC、API・IaCでの管理
社内のキャッシュDNS	Unbound、BIND、Windows Server DNS	DNSSEC検証、フォワーディング、ログ・フィルタリング
AD環境の社内DNS	Windows Server DNS（AD統合ゾーン）	ADとの一体運用、保護された動的更新
大規模な社内網	Infoblox 等のDDI製品	DHCP・IPアドレス管理との統合、権限の分離
コンテナ・小規模	CoreDNS、dnsmasq	基盤の標準に合わせる

そして、製品を問わず守りたい原則があります。権威とキャッシュを同じサーバーで兼ねないことです。

理由は3つです。

1. アクセス制御が正反対：権威は誰からの問い合わせにも答え、キャッシュは社内からだけ受け付ける。兼ねるとオープンリゾルバーになりやすい（第9回）
2. 古いデータが残る：ドメインを別の事業者へ移した後も、兼用サーバーは自分の持つ古いゾーンで社内に答え続ける
3. 障害と攻撃が波及する：キャッシュへの攻撃や負荷（ランダムサブドメイン攻撃等）で権威の応答まで止まり、逆も起きる。役割ごとに更新・停止の計画も立てにくい

2つ目は特に厄介で、「社外からは新しいサイトが見えるのに、社内からだけ古いサイトが見える」という障害になります。

---

考えてみよう

1. あなたのドメインの権威DNSは何台で、どこに置かれていますか。同じデータセンターや同じ事業者に集中していませんか。
2. Webサーバーを別のクラウドへ移す作業が2週間後に決まりました。DNSについて、いつ、何をしますか。この記事の「変更作業の手順」のタイムラインに沿って作業計画を立ててみましょう。
3. 社内のDNSサーバーが、権威（社内ゾーン）とキャッシュを兼ねていないか確認してください。兼ねている場合、分けることの利点と手間を比べてみましょう。

ヒント：dig example.jp NS +shortとdig @各サーバー example.jp SOA +shortで、台数・置き場所・シリアルの一致を確認できます。PowerShellで全NSのシリアルを並べる例は第8回で紹介します。

---

まとめ

• 権威DNSはプライマリ＋セカンダリで複数台。NSには全台を載せる
• セカンダリはシリアルが増えたときだけ転送する。上げ忘れ・戻し方に注意
• ゾーン転送はセカンダリだけに許可し、TSIGで守る
• TTLは「普段は長め、変更の前だけ短く」。旧TTLの時間以上待ってから値を変える
• 動的更新のゾーンは直接編集しない（freeze→編集→thaw）
• スプリットホライズンは更新漏れに注意。権威とキャッシュは分ける

次回は、ここまでの知識を使って、digやPowerShellのコマンドで実際にDNSを調べる方法を見ていきます。

---

連載「DNS入門」全12回

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用（この記事）
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習