2026年6月10日

Knot DNS で複数ゾーンを管理する設定｜template で共通設定をまとめ、追加・更新・確認を楽にする

DNS・名前解決

Knot DNS で多くのゾーンを扱うときは、ゾーンごとに同じ設定を繰り返さず、共通の設定を template にまとめて、各ゾーンは domain と使う template を書くだけにするのが基本です。この記事では、ゾーンファイルの置き場所の決め方、template の書き方、プライマリとセカンダリの混在、ゾーンの追加・更新の反映、増えたときの確認方法を順に説明します。

内容は Knot DNS 3.x 系を前提にしています（2026年10月現在）。設定項目の名前や既定値は版によって変わることがあるため、knotd --version で手元の版を確かめ、同じ版の公式ドキュメント（knot.conf のリファレンス）と照らし合わせてください。

最初に決めておくこと

ゾーンが数十、数百と増えてから並べ方を変えるのは手間がかかります。設定を書く前に次を決めます。

ゾーンファイルの置き場所：例として /var/lib/knot/zones/。パッケージによって既定の場所が異なります。
ファイル名の規則：ゾーン名.zone（例：example.com.zone）のように、ゾーン名から機械的に決まる形にします。後述の %s で1行にまとめられるからです。
手で編集するゾーンと自動で更新されるゾーンを分けるか：セカンダリとして受け取るゾーンや、DNSSEC の署名で Knot が内容を書き換えるゾーンは、手で編集するゾーンとディレクトリを分けておくと取り違えを防げます。
設定の管理方式：Knot はテキストの設定ファイル（knot.conf）でも、設定データベースでも動かせます。まずはテキストの設定ファイルで始め、運用に合わせて検討するのが分かりやすい進め方です。

template を使った基本の knot.conf

プライマリとして複数ゾーンを配り、1台のセカンダリへ転送する例です。鍵の値はダミーです。

server:
    listen: [ 192.0.2.1@53, 2001:db8::1@53 ]

log:
  - target: syslog
    any: info

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

remote:
  - id: secondary1
    address: 198.51.100.2@53
    key: xfr-key

acl:
  - id: to-secondary1
    address: 198.51.100.2
    key: xfr-key
    action: transfer

template:
  - id: default
    storage: "/var/lib/knot/zones"
    file: "%s.zone"
    semantic-checks: on

  - id: primary
    storage: "/var/lib/knot/zones"
    file: "%s.zone"
    semantic-checks: on
    notify: secondary1
    acl: to-secondary1

zone:
  - domain: example.com
    template: primary
  - domain: example.net
    template: primary
  - domain: example.org
    template: primary

ポイントは次のとおりです。

**id: default の template** は、template を指定していないゾーンに使われます。全ゾーンに共通する最低限の設定をここに置きます。
**file: "%s.zone"** の %s はゾーン名（末尾のドットなし）に置き換わり、storage からの相対パスとして扱われます。この例では /var/lib/knot/zones/example.com.zone を読みます。
**notify はゾーンが更新されたときに知らせる相手、acl** の action: transfer はゾーン転送を許す相手です。IP アドレスだけでなく TSIG 鍵も組み合わせるのが一般的です。IP だけの許可は、設定ミスや送信元の偽装に対して弱くなります。
**semantic-checks: on** にすると、NS の不足やグルーの矛盾など、文法は正しくても意味的におかしい内容を読み込み時に検出します。ゾーンが多いほど、人の目で見落とす誤りを拾えるので有効にしておく価値があります。

template に書いた項目は、ゾーン側に同じ項目を書けば上書きできます。特定のゾーンだけ NOTIFY 先を増やしたい、といった例外はゾーン側に書き、共通の部分は template に残します。

セカンダリとして受け取るゾーンも同じ設定で扱う

同じ Knot で、別のプライマリからゾーンを受け取る場合は、用途別の template を追加します。

remote:
  - id: hidden-primary
    address: 192.0.2.100@53
    key: xfr-key

acl:
  - id: from-hidden-primary
    address: 192.0.2.100
    key: xfr-key
    action: notify

template:
  - id: secondary
    storage: "/var/lib/knot/secondary"
    file: "%s.zone"
    master: hidden-primary
    acl: from-hidden-primary

zone:
  - domain: example.jp
    template: secondary

master は「どこからゾーンを取得するか」、acl の action: notify は「どこからの NOTIFY を受け入れるか」です。プライマリを指す項目の名前は版によって扱いが変わる可能性があるため、手元の版のリファレンスで確認してください。受け取ったゾーンは storage の場所に書き出されるので、手で編集するゾーンとはディレクトリを分けています。

ゾーンの追加と削除

テキストの設定ファイルで運用している場合、ゾーンの追加は次の流れになります。

# 1. ゾーンファイルを置き、単体で検査する
kzonecheck -o example.info /var/lib/knot/zones/example.info.zone

# 2. knot.conf の zone に domain と template を追記し、設定を検査する
knotc conf-check

# 3. 設定を読み直す（再起動は不要）
knotc reload

# 4. 読み込まれたか確認する
knotc zone-status example.info

knotc reload は設定と変更のあったゾーンを読み直します。削除は knot.conf から該当の domain を消して同じく conf-check と reload を行います。設定から消しても、ゾーンファイルやジャーナルなどのデータは残ることがあるので、不要になったファイルは確認してから片付けます。

ゾーンの数が多い場合は、include で別ファイルに分ける方法や、設定データベースを使って knotc conf-begin から knotc conf-commit までの操作で稼働中にゾーンを追加する方法もあります。設定データベースはテキストの設定ファイルとは管理の仕方が変わり、バックアップや差分の見方も変わるため、移行する前に検証環境で手順を固めてください。

ゾーンを更新したときの反映

ゾーンファイルを手で編集したら、SOA のシリアル番号を上げてから、そのゾーンだけ読み直します。

kzonecheck -o example.com /var/lib/knot/zones/example.com.zone
knotc zone-reload example.com

シリアルを上げ忘れると、Knot 自身は新しい内容で答えても、セカンダリは「更新なし」と判断して古い内容を配り続けます。複数のサーバーで答えが食い違う原因として多いものです。

もう一つ注意したいのが、Knot がゾーンファイルへ内容を書き戻す動きです。DNSSEC の自動署名や動的更新（DDNS）を使うと、Knot は変更をジャーナルに記録し、設定によってはゾーンファイルにも書き戻します。手で書いたコメントや並び順が消えたり、編集中のファイルと食い違ったりするのはこのためです。手で編集するファイルを Knot に書き換えさせたくない場合は、zonefile-sync や zonefile-load、journal-content といった項目の組み合わせで「ゾーンファイルは人が管理し、Knot は差分をジャーナルに持つ」形にできます。既定値と組み合わせの意味は版によって異なるため、リファレンスで確認してから template に入れてください。

ゾーンが増えたときの確認ポイント

全ゾーンの状態：knotc zone-status をゾーン名なしで実行すると、すべてのゾーンの状態をまとめて表示します。セカンダリのゾーンで転送が失敗し続けていないか、シリアルが期待どおりかを定期的に見ます。
ログ：読み込みに失敗したゾーンは syslog（journalctl -u knot など）に記録されます。1つのゾーンに誤りがあっても他のゾーンは動き続けることが多いため、気付きにくい点に注意します。
外部からの応答：kdig @192.0.2.1 example.com SOA +norec でシリアルを確認し、セカンダリでも同じ値が返るかを見ます。
メモリとディスク：Knot はゾーンをメモリに展開し、ジャーナルや DNSSEC の鍵をデータベースに保存します。ゾーンの数と大きさに応じて増えるため、追加前後で使用量を見比べます。
登録事業者側の設定：Knot にゾーンを追加しても、ドメインの登録事業者でネームサーバーをこのサーバーに向けない限り、外部からの問い合わせは来ません。

ゾーンの一覧そのものをセカンダリへ自動で伝えたい場合は、カタログゾーン（RFC 9432）があります。Knot は 3.x 系で対応していますが、生成側・受け取り側それぞれの設定項目や対応範囲は版によって異なるため、両方のサーバーの版を確認してから検討してください。

変更前の準備

knot.conf、ゾーンファイル、Knot のデータ用ディレクトリ（ジャーナルや鍵の保存先）をバックアップします。DNSSEC を使っている場合、鍵を失うと署名を続けられなくなります。
新しい template やゾーンは、検証環境で knotc conf-check と kzonecheck を通してから本番に入れます。
template を変更すると、それを使うすべてのゾーンに影響します。変更後は代表的なゾーンだけでなく、zone-status で全体を確認します。

まとめ

共通の設定は template にまとめ、ゾーンは domain と template を書くだけにします。file: "%s.zone" でファイル名をゾーン名から決めると設定が短く保てます。
プライマリ用とセカンダリ用など、用途ごとに template を分け、保存先のディレクトリも分けます。
追加は kzonecheck、knotc conf-check、knotc reload の順に行い、更新時はシリアルを上げてから knotc zone-reload で反映します。
Knot がゾーンファイルへ書き戻す設定を把握し、手で編集するファイルとの食い違いを防ぎます。