2026年6月7日

DNSKEYレコードとNSレコードを併用する設定｜サブドメインの委任とセカンダリDNSでDNSSECの鎖を切らない構成

DNS・名前解決

DNSKEYレコードとNSレコードを併用するときに押さえる点は、「NSが指す権威DNSのすべてが、同じDNSKEYと署名を返すこと」と「委任の境目に、委任先の鍵に対応するDSを置くか、置かないかを決めること」の2つです。この2つがずれると、DNSSECで検証するリゾルバーが応答を捨て、名前解決が SERVFAIL で止まります。この記事では、NSとDNSKEYがDNSSECの鎖の中でどうつながっているかを整理し、サブドメインを別のDNSに委任する場合と、セカンダリDNSを追加する場合の設定と確認方法を説明します。

NSとDNSKEYの関係を整理する

NSレコードは「このゾーンの答えはどのDNSサーバーが持っているか」を示し、DNSKEYは「このゾーンの署名を確かめる公開鍵」を示します。DNSSECの検証では、この2つが次のようにつながります。

親ゾーンのNS（委任）: 親（.com や、サブドメインを委任する場合は example.com）に置かれ、子ゾーンの権威DNSを指します。委任のためのNSとグルーは、親では署名されません
親ゾーンのDS: 子ゾーンの鍵（主にKSK）の要約値です。親が署名するので、親の鍵で正しさが確かめられます
子ゾーンのDNSKEY: 子ゾーンの頂点に置く公開鍵です。DSと一致する鍵が含まれている必要があります
子ゾーンのNS: 子ゾーンの頂点にもNSがあり、こちらは子のDNSKEYで署名されます

つまり、NSは「どこへ聞きに行くか」、DSとDNSKEYは「聞いた答えが本物か」を担当します。NSが指すどのサーバーに問い合わせても、DSにつながるDNSKEYと有効な署名が返ってくる、という状態を保つのが設定の目標です。

親側のNSと子側のNSは、内容をそろえておくのが基本です。親だけに古いサーバーが残っていると、そのサーバーが署名の無い古いゾーンを返し、一部の問い合わせだけが失敗する、という分かりにくい症状になります。

ケース1：サブドメインを別のDNSに委任する

example.com を管理するDNSサービスとは別のDNSに、shop.example.com を委任する場面を考えます。親ゾーンの example.com がDNSSECで署名されているなら、委任のしかたは2通りです。

委任先も署名する（署名付きの委任）

委任先のDNSで shop.example.com の署名を有効にし、そのDSを親ゾーン（example.com）に登録します。DSを置く場所はレジストラではなく、example.com のゾーンを管理している自分のDNSサービスです。DSレコードを手で追加できるかどうかはDNSサービスによって違うため、ドキュメントで確かめてください（2026年10月現在）。

順番は次のとおりです。

委任先で署名を有効にし、DNSKEYと署名が返ることを確かめる
親ゾーンに委任のNSを置く
委任先のDNSKEYに対応するDSを親ゾーンに追加する
検証するリゾルバー経由で確かめる

DSを先に置いてしまうと、委任先が署名していない間、shop.example.com は検証に失敗します。

委任先は署名しない（署名の無い委任）

委任先のDNSがDNSSECに対応していない場合は、親ゾーンにNSだけを置き、DSは置きません。親が署名していれば、「この委任にはDSが無い」ことがNSECまたはNSEC3で証明されるため、リゾルバーは委任先を「検証しないゾーン」として扱い、名前解決は通常どおり行われます。

避けたいのは、委任先が署名していないのに、親にDSだけが残っている状態です。委任先のDNSを移したときや、署名をやめたときに起きやすいため、DSを置いたかどうかを運用メモに残しておきます。

ケース2：セカンダリDNSを追加する

可用性を高めるために、別会社のセカンダリDNSをNSに加える構成もよく使われます。DNSSECを有効にしたゾーンでこれを行うときは、どこで署名するかを先に決めます。

プライマリで署名し、署名済みのゾーンを転送する: プライマリが署名したゾーンをゾーン転送（AXFR/IXFR）でセカンダリに渡し、セカンダリはそのまま応答します。鍵は1組で済み、構成が分かりやすい方式です。セカンダリ側が署名済みゾーンをそのまま配れるかどうかを確かめます
各社がそれぞれ署名する（マルチサイナー）: 各DNSサービスが自分の鍵で署名します。この場合、どちらのサーバーに聞いても検証が通るよう、互いのZSKを自分のDNSKEYに含め、親には両方のKSKに対応するDSを置く必要があります。考え方はRFC 8901にまとめられていますが、他社の鍵を取り込める機能を持つDNSサービスは限られます

どちらの方式でも、NSに追加する前に、新しいセカンダリが署名付きの応答を返すことを確かめます。署名の無いサーバーをNSに入れた時点で、そのサーバーに当たった問い合わせは検証に失敗します。

設定を確かめるコマンド

親側の委任とDSを見る

親ゾーンの権威DNSに再帰なしで問い合わせると、委任のNSが見えます。.com の場合は、親の権威DNSの名前を dig com NS +short で調べられます。

dig @a.gtld-servers.net example.com NS +norecurse
dig @a.gtld-servers.net example.com DS +norecurse

サブドメインの委任なら、example.com の権威DNSに対して shop.example.com のNSとDSを問い合わせます。

子側のNSとDNSKEYを全台で見る

子ゾーンのNSが指すサーバーそれぞれに問い合わせ、DNSKEYと署名がそろっているかを比べます。

for ns in ns1.example-dns.net ns2.secondary-dns.net; do
  echo "== $ns"
  dig @"$ns" example.com DNSKEY +dnssec +norecurse +multi | grep -E "DNSKEY|RRSIG|key id"
  dig @"$ns" example.com NS +dnssec +norecurse +short
done

+multi を付けると、DNSKEYの行に鍵の識別番号（key id、DSのkey tagに当たる値）が表示されます。全台で同じ鍵が返り、その識別番号が親のDSと一致していれば、鎖はつながっています。

検証するリゾルバー経由で確かめる

dig @1.1.1.1 example.com NS +dnssec
delv @8.8.8.8 example.com NS

dig の応答の flags: に ad が含まれていれば、そのリゾルバーで検証が通っています。delv は自身で検証を行います。DNSVizのような可視化サービスでは、親のDSから子のDNSKEYまでの鎖と、NSごとの違いを図で確かめられます。

よくある失敗と直し方

可能性の高い順に並べます。

NSに署名していないサーバーが混ざっている: 全台に +dnssec で問い合わせ、RRSIGが返らないサーバーを探します。署名済みゾーンを配れるようにするか、NSから外します
DSと子のDNSKEYが一致しない: DNSサービスを移した後や鍵を更新した後に起きます。子のDNSKEYの識別番号と、親のDSのkey tagを比べ、DSを入れ替えます
親と子でNSの中身が違う: 親側に古いサーバーが残っていないかを確かめ、両方をそろえます
委任先が署名していないのにDSがある: 委任先を署名するか、親からDSを外します

DSやNSを書き換える前には、現在のレコードを控え、ゾーンのバックアップを取ってください。DSを外した場合も、親ゾーンとキャッシュに反映されるまでDSのTTL分の時間がかかります。

まとめ

NSは「どこへ聞くか」、DSとDNSKEYは「答えが本物か」を担う
NSが指す権威DNSのすべてが、同じDNSKEYと有効な署名を返す必要がある
サブドメインの委任では、委任先を署名してDSを親に置くか、署名せずDSを置かないかを決める
セカンダリDNSは、署名済みゾーンの転送か、マルチサイナーかを先に決める
確認は親の委任とDS、子の全台のDNSKEY、検証するリゾルバーの順に行う