Knot DNS のセカンダリ構成方法｜既存のプライマリからゾーン転送を受ける設定とTSIG

Knot DNS をセカンダリ（スレーブ）にするには、knot.conf に「プライマリの場所（remote）」「NOTIFY を受け入れる許可（acl）」「どのゾーンをどこから取るか（zone の master）」の3つを書き、プライマリ側でもゾーン転送を許可します。この記事では、BIND など既存のプライマリから Knot DNS へゾーンを転送させる構成を、TSIG 鍵の作成、設定、動作確認、うまくいかないときの切り分けの順に説明します。Knot DNS をプライマリにしてほかのサーバーへ配信する側の設定は扱いません。

設定項目名は Knot DNS 3.x 系を前提にしています（2026年10月現在）。古い 2.x 系とは書き方が異なる部分があるため、手元のバージョンを knotd --version で確かめ、公式マニュアルの該当バージョンと照らし合わせてください。

構成の全体像

例として、次の2台を使います。

• プライマリ：192.0.2.1（BIND など。ゾーンの編集はこちらで行う）
• セカンダリ：198.51.100.2（Knot DNS。プライマリからコピーを受け取って応答する）

セカンダリの動きは次のとおりです。プライマリでゾーンが更新されると、プライマリから NOTIFY が届きます。Knot はそれを受けて SOA のシリアル番号を問い合わせ、自分の持っている番号より大きければ差分転送（IXFR）か全体転送（AXFR）でゾーンを取り込みます。NOTIFY が届かなくても、SOA レコードの refresh 間隔ごとに自分から確認しに行きます。

つまり、NOTIFY が通らなくても時間がたてば同期はされますが、反映が refresh の間隔ぶん遅れます。「しばらくすると直る」という症状は NOTIFY 側の設定漏れであることが多いので、両方が通るように組みます。

手順1：TSIG 鍵を用意する

IP アドレスだけでゾーン転送を許可すると、送信元を偽った問い合わせや設定ミスに弱くなります。プライマリとセカンダリで共通の TSIG 鍵を持ち、転送と NOTIFY に署名を付けるのが一般的です。

Knot には鍵を作る keymgr が付属しています。

keymgr -t xfr-key hmac-sha256

knot.conf にそのまま貼れる key: セクションが出力されます。BIND 側では、同じ名前・同じアルゴリズム・同じ秘密値を key 文として書きます（BIND 付属の tsig-keygen で作った鍵を Knot 側に書き写しても構いません）。秘密値はパスワードと同じ扱いで、設定ファイルの権限を絞り、リポジトリや共有チャットに貼らないようにしてください。

手順2：Knot DNS（セカンダリ）の設定

/etc/knot/knot.conf の例です。秘密値はダミーなので、手順1で作った値に置き換えます。

server:
    listen: [ 198.51.100.2@53, ::@53 ]

log:
  - target: syslog
    any: info

key:
  - id: xfr-key
    algorithm: hmac-sha256
    secret: your-base64-secret

remote:
  - id: primary
    address: 192.0.2.1@53
    key: xfr-key

acl:
  - id: notify_from_primary
    address: 192.0.2.1
    key: xfr-key
    action: notify

template:
  - id: default
    storage: /var/lib/knot

zone:
  - domain: example.com
    master: primary
    acl: notify_from_primary

各セクションの役割は次のとおりです。

• remote：相手サーバーの住所録です。アドレスと、そのサーバーとの通信に使う鍵を結び付けます。
• acl：外から来た要求のうち、何を許すかを決めます。セカンダリでは「プライマリからの NOTIFY」を許すだけで足ります。ゾーン転送を自分から取りに行く動作に acl は要りません。
• zone の master：このゾーンをどの remote から取得するかの指定です。複数台のプライマリがある場合はリストで並べられます。
• template の storage：受け取ったゾーンや差分の記録（ジャーナル）を置く場所です。knot ユーザーが書き込めるディレクトリにします。

セカンダリでは、ゾーンファイルを手で置く必要はありません。初回は Knot がプライマリから全体転送で取得し、保存先に書き出します。

設定を書いたら、文法を確認してから読み込みます。

knotc conf-check
systemctl enable --now knot   # 初回
knotc reload                  # 稼働中に設定を変えたとき

手順3：プライマリ（BIND）側の設定

セカンダリだけ設定しても、プライマリが転送を拒否すれば同期できません。BIND の named.conf の例です。

key "xfr-key" {
    algorithm hmac-sha256;
    secret "your-base64-secret";
};

zone "example.com" {
    type primary;
    file "/var/named/example.com.zone";
    allow-transfer { key xfr-key; };
    notify yes;
    also-notify { 198.51.100.2 key xfr-key; };
};

あわせて次の2点を確認します。

• ゾーンの NS レコードにセカンダリのホスト名が入っているか。NS に載っていないサーバーには、BIND は既定では NOTIFY を送りません（also-notify で明示すれば送ります）。
• ドメインの登録事業者（親ゾーン）に登録したネームサーバーにもセカンダリが含まれているか。ここに載せない限り、外部の利用者はセカンダリに問い合わせに来ません。

プライマリが BIND 以外（PowerDNS や NSD など）の場合も考え方は同じで、「セカンダリの IP と鍵で転送を許可」「セカンダリへ NOTIFY を送る」の2点を設定します。

手順4：同期できたか確認する

まず Knot 自身にゾーンの状態を聞きます。

knotc zone-status example.com

シリアル番号や、次回の refresh・expire までの時間が表示されます。表示形式はバージョンによって変わりますが、シリアルが空のままなら一度も転送に成功していません。

次に、プライマリとセカンダリの SOA シリアルを並べて比べます。

kdig +short @192.0.2.1 example.com SOA
kdig +short @198.51.100.2 example.com SOA

3番目の値（シリアル）が一致していれば同期できています。最後に、プライマリでレコードを1つ変えてシリアルを上げ、数秒でセカンダリに反映されるかを見ます。すぐ反映されれば NOTIFY も通っています。

手動で取り直したいときは次のコマンドを使います。

knotc zone-refresh example.com     # SOA を確認し、新しければ取り込む
knotc zone-retransfer example.com  # 差分ではなく全体転送をやり直す

うまくいかないときの切り分け

ログ（journalctl -u knot）を見ると、どの段階で止まっているかが分かります。可能性の高い順に確認します。

1. TCP 53番が通っていない：ゾーン転送は TCP を使います。UDP の問い合わせには答えるのに転送だけ失敗する場合、ファイアウォールやクラウドのセキュリティグループで TCP 53 を許可しているかを見ます。セカンダリから kdig +tcp @192.0.2.1 example.com SOA が返るかで切り分けられます。
2. プライマリが転送を拒否している：ログに REFUSED や NOTAUTH が出る場合です。BIND の allow-transfer に鍵や IP が入っているか、プライマリ側のログに拒否の記録があるかを確かめます。
3. TSIG 鍵の不一致：鍵名、アルゴリズム、秘密値のどれか1つでも違うと BADKEY や BADSIG になります。鍵名は大文字小文字や末尾のドットの扱いも含めて揃えます。
4. 時刻のずれ：TSIG は署名に時刻を含むため、2台の時計が数分以上ずれていると BADTIME で失敗します。両方で時刻同期（chrony など）が動いているか確認します。
5. シリアルを上げていない：プライマリでレコードを書き換えてもシリアルが同じなら、セカンダリは「更新なし」と判断します。ゾーンファイルを手で編集する運用では最も多いつまずきです。
6. 保存先に書き込めない：storage のディレクトリの所有者やパーミッション、SELinux などで knot プロセスが書き込めないと、転送後の保存で失敗します。

運用で気を付けること

• expire を過ぎると応答をやめる：プライマリと長時間通信できないと、SOA の expire を過ぎた時点でセカンダリはそのゾーンに答えなくなります。古いデータを配り続けないための仕様です。プライマリの停止が長引く計画作業では expire の値を事前に確認します。
• 監視：シリアルの一致を外部から定期的に比べると、同期の停止に早く気付けます。
• 変更は検証環境から：設定を変える前に knot.conf と保存先をバックアップし、knotc conf-check を通してから反映します。DNSSEC を使っている場合、署名はプライマリで行い、セカンダリは署名済みのゾーンをそのまま配るのが基本です。

まとめ

• セカンダリの Knot DNS には remote（プライマリの場所と鍵）、acl（NOTIFY の受け入れ）、zone の master を設定します。
• プライマリ側では、セカンダリの鍵で転送を許可し、NOTIFY を送る設定を忘れずに入れます。
• 同期の確認は knotc zone-status と、両サーバーの SOA シリアルの比較で行います。
• 失敗するときは TCP 53、転送許可、TSIG 鍵、時刻、シリアル、保存先の権限の順に確認します。

• DNSサーバーを自前で構築する方法（BINDのプライマリ／セカンダリ2台構成）
• DNSのSOAレコードの設定方法と各フィールドの意味