AレコードとDNSKEYレコードを併用する設定｜DNSSEC署名ゾーンでAレコードを運用・変更する手順

AレコードとDNSKEYレコードの併用とは、DNSSECで署名したゾーンの中でAレコードを運用することです。DNSKEYはゾーンの頂点（example.com）にだけ置く公開鍵で、Aレコードそのものに鍵を付けるわけではありません。各Aレコードには署名（RRSIG）が付き、その署名をDNSKEYで、DNSKEYを親ゾーンのDSレコードで確かめる、という鎖で正しさが保証されます。この記事では、この関係を押さえたうえで、署名ゾーンでAレコードを追加・変更するときの手順と、確認方法、止まりやすい場面を説明します。

各レコードの役割

DNSSECを有効にしたゾーンでは、Aレコードの周りに次のレコードが並びます。

• A: 名前とIPv4アドレスの対応。DNSSECを使っても内容は変わりません
• RRSIG: Aレコードの組（同じ名前のA全体）に対する署名。有効期限があります
• DNSKEY: ゾーンの頂点に置く公開鍵。一般に、ゾーン内のレコードを署名する鍵（ZSK、フラグ256）と、DNSKEYの組を署名する鍵（KSK、フラグ257）があります
• DS: 親ゾーン（.com など）に登録する、KSKの要約値。レジストラ経由で登録します
• NSEC / NSEC3: 「その名前やレコード型は存在しない」ことを証明するためのレコード

検証するリゾルバーは、Aレコードを受け取ると、RRSIGをDNSKEYで検証し、DNSKEYを親のDSで検証し、さらに上へとたどります。どこかで鎖が切れると、検証するリゾルバーは応答を捨てて SERVFAIL を返します。DNSSECの不具合が「サイトが落ちた」ように見えるのはこのためです。

大事なのは、DNSKEYやRRSIGを手で入力するものではないという点です。署名は、DNSサービスやDNSサーバーソフトが自動で作ります。署名機能の無いDNSサービスに、よそで見たDNSKEYを普通のレコードとして登録しても、DNSSECは有効になりません。

設定の進め方

1. 署名を有効にする

マネージドDNS（Cloudflare、Route 53、Google Cloud DNS など）では、DNSSECを有効にする設定を入れると、鍵の生成と署名をサービス側が行います。サービスによって、鍵の種類や署名の方式、表示されるDS値の形式が違うため、各サービスのドキュメントに沿って進めます（2026年10月現在の画面構成は変わることがあります）。

BINDで自前運用する場合は、dnssec-policy を使うと鍵の生成・署名・再署名を自動化できます。以下は例です。BINDのバージョンによって必要な指定が異なるため、使っている版のマニュアルで確かめてから適用してください。

zone "example.com" {
    type primary;
    file "/var/named/example.com.zone";
    dnssec-policy default;
    inline-signing yes;
};

設定を変える前に、ゾーンファイルと設定ファイルのバックアップを取ります。

2. 権威DNSで署名を確かめる

親にDSを登録する前に、権威DNSが署名付きで応答しているかを確かめます。

dig @ns1.example.net example.com DNSKEY +multi
dig @ns1.example.net www.example.com A +dnssec +norecurse

1つ目でフラグ256と257の鍵が返り、2つ目でAレコードとRRSIGが返れば、署名はできています。権威DNSが複数あるなら、すべてで確かめます。

3. 親ゾーンにDSを登録する

DNSサービスが示すDS値（または鍵の情報）を、ドメインを登録しているレジストラの管理画面で登録します。レジストラとDNSサービスが同じ会社の場合は、自動で登録されることもあります。DSの登録は、権威DNSの署名が全台で確認できてから行います。順番を逆にすると、署名の無い応答を検証できず、ドメイン全体の名前解決が止まります。

4. 検証が通るかを確かめる

DSが親ゾーンに反映された後、検証するリゾルバー経由で問い合わせます。

dig @1.1.1.1 www.example.com A +dnssec
delv @8.8.8.8 www.example.com A

dig の応答の flags: に ad があれば、そのリゾルバーで検証が通っています。delv は自身で検証を行い、成功すると fully validated のように表示します。DNSViz のような可視化サービスを使うと、鎖のどこに問題があるかを図で確認できます。

署名ゾーンでAレコードを変更するとき

Aレコードの追加・変更・削除そのものは、署名が無いゾーンと同じ操作です。違うのは、変更のたびに署名を作り直す必要がある点です。

• マネージドDNS: 多くの場合、保存と同時に再署名されます。応答時に署名を作る方式のサービスもあります
• BIND + dnssec-policy と inline-signing: 元のゾーンファイルを編集してシリアルを上げ、rndc reload すると、署名済みのゾーンが自動で更新されます
• **dnssec-signzone による手動署名**: 編集のたびに署名し直す必要があります。忘れると、新しいAレコードに署名が無い、または古い署名の期限が切れる、という形で SERVFAIL になります

変更後は、権威DNSで新しいAレコードとRRSIGが返ること、検証するリゾルバーで ad が付くことを確かめます。

dig @ns1.example.net new.example.com A +dnssec +norecurse
dig @1.1.1.1 new.example.com A

止まりやすい場面と確認方法

名前解決ができないとき、DNSSECが原因かどうかは、検証を無効にする +cd を付けて比べると分かります。

dig @1.1.1.1 www.example.com A
dig @1.1.1.1 www.example.com A +cd

普通の問い合わせは SERVFAIL で、+cd を付けると答えが返る場合、DNSSECの検証で失敗しています。原因は可能性の高い順に次のとおりです。

1. DNSサービスを移したのに旧DSが残っている: ネームサーバーを変えたとき、親のDSが旧サービスの鍵のままだと検証が通りません。移行前にDNSSECの扱いを決め、手順に沿ってDSを入れ替える（または一度外す）必要があります。
2. 署名の期限切れ: 手動署名や、署名の自動化が止まっている場合に起きます。RRSIGに含まれる有効期限を確かめます。
3. 一部の権威DNSだけ署名していない: セカンダリDNSが署名済みゾーンを受け取れていない場合などです。全台に +dnssec で問い合わせて比べます。
4. サブドメインを別DNSに委任している: sub.example.com のAレコードを委任先で管理しているなら、委任先も署名し、親ゾーン（example.com）にその委任先のDSを置くか、委任先を署名しない形にします。どちらにするかで設定が変わります。

緊急時に検証エラーを解消したい場合、レジストラでDSを削除すればDNSSECの検証は行われなくなりますが、親ゾーンとキャッシュに反映されるまで時間がかかります。DSのTTLも事前に把握しておくと、復旧の見通しが立てやすくなります。

まとめ

• DNSKEYはゾーンの頂点に置く公開鍵で、Aレコードには署名（RRSIG）が付く
• DNSKEYやRRSIGは手入力せず、DNSサービスやDNSサーバーに署名させる
• 有効化は「署名を確認、全台で確認、DSを登録、検証を確認」の順に進める
• Aレコードの変更は通常どおり行い、再署名と ad フラグで確認する
• 不具合時は +cd 付きの問い合わせと比べ、DSの残り・署名の期限・委任先を順に調べる

• DNSSEC を有効化する手順と注意点
• ネームサーバー変更時の注意点