DNSSECの仕組みについて

DNSSEC（DNS Security Extensions）は、DNSの応答が正しい管理者によって作成されたものか、また途中で改ざんされていないかを検証するための仕組みです。

DNSは、ドメイン名とIPアドレスを対応づけるインターネットの重要な基盤です。

たとえば、ユーザーがWebサイトにアクセスするとき、ブラウザやOSはDNSを使って「このドメイン名に対応するIPアドレスは何か」を調べます。

しかし、従来のDNSには、返ってきた応答が本当に正しいものかを強く確認する仕組みがありません。

そのため、攻撃者が偽のDNS応答を返したり、DNSキャッシュを汚染したりすると、ユーザーが本物のサイトではなく偽サイトへ誘導される可能性があります。

DNSSECは、このようなリスクに対して、DNSデータに電子署名を付けることで、DNS応答の真正性と完全性を検証できるようにする技術です。

DNSSECを一言でいうと

DNSSECとは、DNSレコードに電子署名を付け、DNS検証リゾルバがその署名を確認することで、DNSデータの正しさを検証できるようにする仕組みです。

もう少し簡単に言うと、DNSSECは次のような役割を持ちます。

このDNS応答は、本当に正しい管理者が作成したものか？
途中で改ざんされていないか？
存在しないという応答も本当に正しいか？

これらを検証するための仕組みがDNSSECです。

ただし、DNSSECはDNS通信を暗号化する技術ではありません。

DNSSECが提供するのは、主に次の2つです。

DNSSECが提供するもの	内容
データの出所認証	正しいゾーン管理者が作成したDNSデータであることを確認する
データの完全性検証	DNSデータが途中で改ざんされていないことを確認する

一方で、DNSSECは次のような機能は提供しません。

DNSSECが提供しないもの	内容
DNS通信の暗号化	問い合わせ内容や応答内容を隠すわけではない
Web通信の暗号化	HTTPSの代わりにはならない
フィッシング対策の完全な代替	攻撃者が取得した別ドメインまでは防げない
マルウェア対策	悪意あるサイトそのものを判定する技術ではない

つまり、DNSSECは「DNSを暗号化する仕組み」ではなく、DNSデータが本物かどうかを検証する仕組みです。

なぜDNSSECが必要なのか

DNSは、インターネットの住所録のような役割を持っています。

たとえば、ユーザーが次のようなドメインにアクセスするとします。

example.com

このとき、コンピューターはDNSに対して次のように問い合わせます。

example.com のIPアドレスは何ですか？

DNSサーバーは、通常であれば次のように応答します。

example.com のIPアドレスは 93.184.216.34 です

しかし、通常のDNSでは、この応答が本当に正しいものかを厳密に確認できません。

攻撃者がDNS応答を偽装した場合、次のような偽の応答が返される可能性があります。

example.com のIPアドレスは 203.0.113.10 です

もし 203.0.113.10 が攻撃者の用意した偽サイトだった場合、ユーザーは本物のサイトにアクセスしているつもりで、偽サイトへ誘導されてしまいます。

このような攻撃は、DNSキャッシュポイズニングやDNS応答の改ざんなどと呼ばれます。

DNSSECは、こうした偽造・改ざんされたDNS応答を、検証リゾルバ側で検出し、通常の有効な応答として利用者に渡さないようにするための仕組みです。

厳密に言えば、DNSSECは攻撃者が偽の応答を送ること自体を物理的に止めるわけではありません。

しかし、攻撃者が正しい秘密鍵を持っていなければ、有効な電子署名を作成できません。

そのため、DNSSEC検証リゾルバは偽の応答を検証に失敗させ、不正な応答として扱うことができます。

DNSSECの基本的な仕組み

DNSSECでは、DNSレコードに対して電子署名を作成します。

通常のDNSでは、たとえば次のようなAレコードが返されます。

example.com.  A  93.184.216.34

DNSSECでは、このDNSレコードに対応する署名情報も一緒に扱います。

example.com.  A      93.184.216.34
example.com.  RRSIG  A ...

この RRSIG が電子署名です。

検証リゾルバは、DNSレコードとRRSIGを照合し、公開鍵を使って署名を検証します。

署名が正しければ、そのDNSデータは改ざんされていないと判断できます。

逆に、DNSレコードが途中で書き換えられていれば、署名検証に失敗します。

DNSSECでは、主に次のようなレコードが使われます。

レコード	役割
RRSIG	DNSレコードセットに対する電子署名
DNSKEY	署名を検証するための公開鍵
DS	親ゾーンに登録される、子ゾーンDNSKEYのハッシュ情報
NSEC	存在しない名前やレコードタイプを証明するためのレコード
NSEC3	NSECをハッシュ化し、ゾーン内の名前を列挙されにくくする仕組み

これらのレコードを組み合わせることで、DNSSECはDNSデータの真正性と完全性を検証します。

DNSSECの中心となる「信頼の連鎖」

DNSSECを理解するうえで重要なのが、信頼の連鎖です。

英語では Chain of Trust と呼ばれます。

DNSは階層構造になっています。

.
└── com
    └── example.com
        └── www.example.com

一番上にはルートゾーン . があります。その下に .com や .jp などのTLDがあり、さらにその下に example.com のような個別ドメインがあります。

DNSSECでは、このDNSの階層構造に沿って信頼をつないでいきます。

ルートゾーン
  ↓
TLDゾーン
  ↓
個別ドメインのゾーン

たとえば、www.example.com のAレコードを検証する場合、検証リゾルバは次のような流れで確認します。

ルートゾーンのDNSKEYを信頼アンカーとして検証
↓
ルートゾーンにある .com のDSレコードを確認
↓
.com のDNSKEYから計算したハッシュがDSレコードと一致するか確認
↓
.com にある example.com のDSレコードを確認
↓
example.com のDNSKEYから計算したハッシュがDSレコードと一致するか確認
↓
example.com のDNSKEYで www.example.com のAレコードのRRSIGを検証

このように、上位ゾーンから下位ゾーンへと信頼をつなげることで、最終的なDNSレコードの正しさを確認します。

信頼アンカーとは

DNSSECの検証には、最初に信頼できる起点が必要です。

この起点を信頼アンカーと呼びます。

通常、DNSSEC検証リゾルバは、ルートゾーンの公開鍵を信頼アンカーとして持っています。

そこから、ルートゾーン、TLD、個別ドメインへと順番に信頼をたどっていきます。

信頼アンカーがあることで、検証リゾルバは次のように判断できます。

ルートの鍵は信頼できる
↓
ルートが .com の鍵情報を示している
↓
.com が example.com の鍵情報を示している
↓
example.com が www.example.com のDNSレコードに署名している

この構造により、DNSSECはDNSの階層全体で信頼を構築します。

DNSSECで使われる主なレコード

ここからは、DNSSECで使われる代表的なレコードを詳しく見ていきます。

RRSIGレコード

RRSIGレコードは、DNSレコードセットに対する電子署名です。

DNSSECでは、個々のDNSレコード単体ではなく、同じ名前・同じ種類・同じクラスのレコードのまとまりであるRRsetに対して署名します。

たとえば、次のようなAレコードがあるとします。

example.com.  A  192.0.2.10
example.com.  A  192.0.2.20

この2つは、どちらも example.com のAレコードなので、1つのRRsetとして扱われます。

DNSSECでは、このRRsetに対して署名を作成します。

example.com.  RRSIG  A ...

検証リゾルバは、Aレコードの内容とRRSIGを使って、応答が改ざんされていないかを確認します。

もし攻撃者がAレコードのIPアドレスを書き換えた場合、RRSIGの検証に失敗します。これにより、不正なDNS応答を検出できます。

DNSKEYレコード

DNSKEYレコードは、DNSSECの署名を検証するための公開鍵を格納するレコードです。

DNSSECでは、ゾーン管理者が鍵ペアを用意します。

秘密鍵：DNSレコードに署名するために使う
公開鍵：署名を検証するためにDNSKEYとして公開する

秘密鍵はゾーン管理者が厳重に管理し、外部には公開しません。
一方、公開鍵はDNSKEYレコードとしてDNS上に公開されます。

検証リゾルバは、このDNSKEYを使ってRRSIGを検証します。

つまり、DNSKEYは「この署名が正しいかどうかを確認するための公開鍵」です。

DSレコード

DSレコードは、親ゾーンと子ゾーンの信頼をつなぐためのレコードです。

DSは Delegation Signer の略です。

たとえば、example.com がDNSSECに対応している場合、example.com のDNSKEYに関する情報を、親ゾーンである .com に登録します。

ただし、DSレコードにDNSKEYそのものが入るわけではありません。

DSレコードには、子ゾーンのDNSKEYから計算したハッシュ値、つまりダイジェストが入ります。

検証リゾルバは、次のように確認します。

親ゾーンに登録されているDSレコードを取得する
↓
子ゾーンのDNSKEYを取得する
↓
子ゾーンのDNSKEYからハッシュ値を計算する
↓
その値が親ゾーンのDSレコードのDigestと一致するか確認する

一致すれば、親ゾーンが子ゾーンの鍵を正しく示していると判断できます。

DSレコードには、一般的に次のような情報が含まれます。

項目	内容
Key Tag	対象のDNSKEYを識別する値
Algorithm	DNSKEYで使われるアルゴリズム
Digest Type	ハッシュ方式
Digest	DNSKEYから計算されたハッシュ値

DSレコードは、DNSSECにおける信頼の連鎖を作るうえで非常に重要な役割を持っています。

NSECレコード

NSECレコードは、DNSSECで「存在しない」という応答を検証可能にするためのレコードです。

DNSでは、存在するレコードだけでなく、存在しない名前や存在しないレコードタイプについても応答する必要があります。

たとえば、次のような問い合わせがあったとします。

nosuchname.example.com のAレコードはありますか？

本当に存在しない場合、DNSサーバーは「存在しません」と返します。

しかし、DNSSECでは、この「存在しません」という応答も正しいものか検証できなければなりません。

攻撃者が、本当は存在する名前に対して「存在しません」と偽る可能性があるからです。

NSECは、次のような形で不存在を証明します。

ある名前と次の名前の間には、他の名前は存在しません

また、NSECは名前が存在しないことだけでなく、その名前に特定のレコードタイプが存在しないことの証明にも使われます。

たとえば、example.com という名前自体は存在するが、MXレコードは存在しない、という場合にも、否定応答の検証に関係します。

NSEC3レコード

NSEC3は、NSECと同じく不存在証明のための仕組みですが、名前をハッシュ化して扱う点が特徴です。

NSECでは、ゾーン内の名前の並びが見えるため、ゾーン内のホスト名を列挙されやすいという問題があります。これをゾーンウォーキングと呼びます。

NSEC3では、名前をそのまま示すのではなく、ハッシュ化した値を使って不存在を証明します。

これにより、ゾーン内の名前をそのまま列挙されにくくできます。

ただし、NSEC3を使えば完全に列挙リスクがなくなるわけではありません。

辞書攻撃や設定内容によっては、名前を推測される可能性があります。

そのため、NSEC3は「ゾーン内の名前の列挙を完全に防ぐ仕組み」というより、列挙を困難にする仕組みと理解するのが正確です。

KSK・ZSK・CSKの違い

DNSSECでは、署名に使う鍵を役割ごとに分けて運用することがあります。

代表的なのが、KSKとZSKです。

鍵	正式名称	主な役割
KSK	Key Signing Key	DNSKEY RRsetを署名する鍵
ZSK	Zone Signing Key	A、AAAA、MX、TXTなど通常のRRsetを署名する鍵
CSK	Combined Signing Key	KSKとZSKの役割を兼ねる鍵

KSKとは

KSKは、Key Signing Keyの略で、主にDNSKEY RRsetを署名するために使われる鍵です。

KSKは、親ゾーンのDSレコードと関係します。

たとえば、example.com のKSKに対応するDSレコードが、親ゾーンである .com に登録されます。

そのため、KSKを変更する場合は、親ゾーン側のDSレコードも適切に更新する必要があります。

この作業に失敗すると、信頼の連鎖が切れてしまい、DNSSEC検証に失敗する可能性があります。

KSKは信頼の連鎖に関わる重要な鍵であるため、慎重に管理されます。

ZSKとは

ZSKは、Zone Signing Keyの略で、ゾーン内の通常のDNSレコードに署名するために使われる鍵です。

たとえば、次のようなレコードセットに署名します。

Aレコード
AAAAレコード
MXレコード
TXTレコード
CNAMEレコード

ZSKは、ゾーン内のDNSデータに対する署名を作るための鍵です。

一般的な運用では、KSKよりもZSKの方が頻繁にロールオーバーされることがあります。

CSKとは

CSKは、Combined Signing Keyの略で、KSKとZSKの役割を1つの鍵で兼ねる運用方式です。

DNSSECでは、運用上の都合からKSKとZSKを分ける構成がよく使われますが、仕様上、必ず分けなければならないわけではありません。

1つの鍵でDNSKEY RRsetと通常のRRsetの両方に署名する構成もあります。これがCSKです。

近年では、マネージドDNSサービスなどでCSK構成が使われるケースもあります。

DNSSECの検証フロー

ここでは、www.example.com のAレコードを検証する場合を例に、DNSSECの検証フローを見てみましょう。

ルートゾーンの信頼アンカーを使う

DNSSEC検証リゾルバは、あらかじめルートゾーンの信頼アンカーを持っています。

この信頼アンカーを起点に、DNSSECの検証が始まります。

ルートゾーンからTLDのDSレコードを確認する

次に、リゾルバはルートゾーンから .com のDSレコードを取得します。

ルートゾーンは、自身のDNSKEYで .com のDSレコードに対する署名を提供します。

検証リゾルバは、ルートのDNSKEYを使って、この署名を検証します。

TLDのDNSKEYを確認する

次に、リゾルバは .com のDNSKEYを取得します。

そして、そのDNSKEYからハッシュ値を計算し、ルートゾーンにある .com のDSレコードのDigestと一致するかを確認します。

一致すれば、.com のDNSKEYは信頼できると判断できます。

TLDから対象ドメインのDSレコードを確認する

次に、.com ゾーンから example.com のDSレコードを取得します。

このDSレコードは、example.com のDNSKEYに対応するハッシュ情報です。

.com のDNSKEYを使って、このDSレコードの署名を検証します。

対象ドメインのDNSKEYを確認する

次に、example.com のDNSKEYを取得します。

そして、そのDNSKEYからハッシュ値を計算し、.com に登録されている example.com のDSレコードのDigestと一致するか確認します。

一致すれば、example.com のDNSKEYは信頼できると判断できます。

最終的なAレコードのRRSIGを検証する

最後に、example.com のDNSKEYを使って、www.example.com のAレコードに付いているRRSIGを検証します。

検証に成功すれば、次のように判断できます。

www.example.com のAレコードは、example.com の正当な鍵で署名されており、改ざんされていない

このようにして、DNSSECはルートから目的のドメインまで信頼をたどり、最終的なDNSレコードの正しさを確認します。

DNSSECの検証結果の状態

DNSSECの検証結果は、主に次のような状態に分類されます。

状態	意味
Secure	署名検証に成功した状態
Insecure	DNSSECで保護されていないが、その状態が正当と判断された状態
Bogus	署名されているはずなのに検証に失敗した状態
Indeterminate	検証に必要な情報が不足して判断できない状態

Secure

Secureは、DNSSECの信頼の連鎖がつながっており、署名検証に成功した状態です。

この場合、検証リゾルバはそのDNSデータを正当なものとして扱います。

Insecure

Insecureは、対象のゾーンがDNSSECで保護されていないが、その未署名状態が正当だと判断された状態です。

たとえば、親ゾーンに子ゾーンのDSレコードが存在しないことを確認できた場合、検証リゾルバは次のように判断します。

この子ゾーンはDNSSEC署名対象ではない

この場合、署名検証はできませんが、ただちに不正とは判断されません。

重要なのは、Insecureは「危険な応答」という意味ではないことです。

あくまで「DNSSECで保護されていない状態が、信頼の連鎖上、正当と判断された」という意味です。

Bogus

Bogusは、DNSSECの検証に失敗した状態です。

たとえば、次のような場合にBogusになります。

RRSIGが期限切れになっている
DSレコードとDNSKEYが対応していない
DNSレコードが改ざんされている
署名アルゴリズムが不正である
鍵ロールオーバーに失敗している

DNSSEC検証リゾルバは、Bogusと判断した応答を通常の有効なDNS応答としては扱いません。

多くの場合、利用者にはSERVFAILとして返されます。

そのため、ユーザー側では次のように見えることがあります。

サイトにアクセスできない
サーバーが見つからない
名前解決に失敗する

実際にはWebサーバーが停止しているのではなく、DNSSECの検証に失敗している可能性があります。

DNSSECで防げること

DNSSECは、DNS応答の偽造や改ざんを検出するための仕組みです。

厳密には、攻撃そのものを完全に発生させない技術ではありません。

しかし、偽造・改ざんされたDNS応答を検証に失敗させ、利用者に渡さないようにすることで、実質的な防御効果を発揮します。

DNSキャッシュポイズニング対策

DNSキャッシュポイズニングとは、DNSリゾルバのキャッシュに偽のDNS情報を入れ込む攻撃です。

たとえば、攻撃者が次のような偽情報をリゾルバに記憶させようとします。

bank.example のIPアドレスは攻撃者のサーバーです

通常のDNSでは、条件がそろうとこのような偽情報がキャッシュされ、利用者が偽サイトへ誘導される可能性があります。

DNSSECでは、正しい秘密鍵を持たない攻撃者は有効な署名を作れません。

そのため、偽のDNSレコードが混入しても、DNSSEC検証リゾルバは署名検証に失敗し、その応答を正当なものとして扱いません。

DNS応答の改ざん検出

通信経路上の攻撃者がDNS応答を書き換えた場合でも、DNSSECが有効であれば改ざんを検出できます。

たとえば、本来の応答が次のようなものだったとします。

example.com.  A  93.184.216.34

攻撃者がこれを次のように書き換えたとします。

example.com.  A  203.0.113.10

DNSレコードの内容が変わると、RRSIGの検証に失敗します。

そのため、検証リゾルバはこの応答を不正なものとして扱えます。

不存在応答の偽装対策

DNSSECでは、存在しない名前やレコードタイプについても検証できます。

たとえば、攻撃者が本当は存在するドメインに対して、

その名前は存在しません

と偽る可能性があります。

DNSSECでは、NSECやNSEC3によって不存在応答も署名付きで検証できます。

これにより、「存在しない」という応答が本当に正しいものかを確認できます。

DNSSECで防げないこと

DNSSECは重要なセキュリティ技術ですが、万能ではありません。

ここでは、DNSSECでは防げない代表的なものを整理します。

DNS通信の盗聴

DNSSECはDNS応答に署名を付ける仕組みであり、DNS通信を暗号化する仕組みではありません。

そのため、DNS問い合わせや応答の内容は、通信経路上で観測される可能性があります。

DNS通信のプライバシーを守るには、次のような技術が使われます。

技術	役割
DoH	DNS over HTTPS。DNS通信をHTTPSで暗号化する
DoT	DNS over TLS。DNS通信をTLSで暗号化する
DoQ	DNS over QUIC。DNS通信をQUICで暗号化する

DNSSECとDoH / DoT / DoQは役割が異なります。

DNSSEC：DNSデータが本物かを検証する
DoH / DoT / DoQ：DNS通信経路を暗号化する

両者は競合するものではなく、併用できる技術です。

HTTPSの代替

DNSSECは、Webサイトとの通信内容を暗号化するものではありません。

Webサイトとの通信を暗号化し、サーバー証明書を使ってWebサーバーを認証するのはHTTPSです。

DNSSECとHTTPSの違いは次の通りです。

項目	DNSSEC	HTTPS
対象	DNSデータ	Web通信
主な目的	DNS応答の真正性・完全性の検証	通信の暗号化・Webサーバー認証
暗号化	しない	する
改ざん検出	DNSレコードに対して行う	HTTP通信に対して行う
利用場面	DNSキャッシュポイズニング対策など	Webサイトの安全な通信

DNSSECを導入していても、WebサイトがHTTPで配信されていれば、Web通信は暗号化されません。

逆に、HTTPSを使っていても、DNSSECがなければDNS応答改ざんのリスクは別途残ります。

DNSSECとHTTPSは、どちらか一方で十分という関係ではなく、異なるレイヤーを守る補完的な技術です。

偽ドメインの取得

DNSSECは、正規に登録された別ドメインを防ぐ仕組みではありません。

たとえば、本物のドメインが次のようなものだとします。

example-bank.com

攻撃者が、見た目の似た次のようなドメインを取得したとします。

examp1e-bank.com

このドメインが正規に登録され、DNSSECで正しく署名されていれば、DNSSEC上は「そのドメインのDNS応答は正しい」と判断されます。

DNSSECが検証するのは、あくまで「そのドメインのDNSデータが正しいか」です。

ドメイン名そのものがユーザーをだます目的で取得されたかどうかまでは判定しません。

そのため、フィッシング対策には、DNSSECだけでなく、ブランド監視、証明書監視、メール認証、URLフィルタリング、ユーザー教育なども必要になります。

DNSSECと関連技術の違い

DNSSECは、DoH、DoT、HTTPS、DANEなどと混同されることがあります。

それぞれの違いを整理しておきましょう。

技術	役割
DNSSEC	DNSデータの真正性・完全性を検証する
DoH	DNS通信をHTTPSで暗号化する
DoT	DNS通信をTLSで暗号化する
DoQ	DNS通信をQUICで暗号化する
HTTPS	Web通信を暗号化し、Webサーバーを認証する
DANE	DNSSECを使ってTLS証明書や公開鍵情報を検証する

特にDNSSECとDoH / DoTは、役割が大きく異なります。

DNSSECは「データが本物か」を確認する
DoH / DoTは「通信経路を暗号化する」

たとえるなら、DNSSECは「書類に押された正式な印鑑を確認する仕組み」であり、DoH / DoTは「その書類を封筒に入れて運ぶ仕組み」です。

DNSSEC導入の流れ

ドメイン管理者がDNSSECを導入する場合、一般的には次のような流れになります。

DNS事業者とレジストラがDNSSECに対応しているか確認する

まず、利用しているDNSホスティングサービスとレジストラがDNSSECに対応している必要があります。

DNS事業者がDNSSEC署名を提供していても、レジストラ側でDSレコードを登録できなければ、信頼の連鎖は完成しません。

確認すべきポイントは次の通りです。

DNSホスティングサービスがDNSSEC署名に対応しているか
レジストラでDSレコードを登録できるか
利用しているTLDがDNSSECに対応しているか
DNSSECの鍵管理を自動化できるか

ゾーン署名を有効化する

DNS事業者の管理画面でDNSSECを有効化します。

マネージドDNSサービスでは、多くの場合、DNSKEYの生成、RRSIGの作成、署名更新などを自動で行ってくれます。

一方、自前で権威DNSサーバーを運用している場合は、鍵生成、ゾーン署名、署名更新、鍵ロールオーバーなどを自分で管理する必要があります。

DSレコードをレジストラに登録する

DNSSECのゾーン署名を有効化しただけでは、信頼の連鎖は完成しません。

親ゾーンにDSレコードを登録する必要があります。

通常は、レジストラの管理画面でDSレコードを設定します。

DSレコードの登録に必要な情報は、一般的に次のようなものです。

項目	内容
Key Tag	鍵を識別する値
Algorithm	DNSKEYのアルゴリズム
Digest Type	ハッシュ方式
Digest	DNSKEYから計算されたハッシュ値

DSレコードを正しく登録することで、親ゾーンから子ゾーンへの信頼の連鎖がつながります。

DNSSECの検証を行う

DNSSECを有効化したら、必ず検証を行います。

代表的な確認方法として、dig コマンドがあります。

dig +dnssec example.com
dig +trace +dnssec example.com

また、DNSSEC Analyzerのような検証ツールを使うこともできます。

確認すべきポイントは次の通りです。

DSレコードが正しく登録されているか
DNSKEYとDSレコードが対応しているか
RRSIGが有効期限内か
信頼の連鎖がルートから対象ドメインまでつながっているか
検証リゾルバでSERVFAILになっていないか

DNSSECは、導入後の確認が非常に重要です。

DNSSECで起こりやすい運用ミス

DNSSECはセキュリティを高める一方で、設定ミスがあるとサイト全体の名前解決に影響することがあります。

特に注意したいのは次のようなケースです。

DSレコードとDNSKEYの不一致

最も典型的なトラブルの1つが、親ゾーンのDSレコードと子ゾーンのDNSKEYが対応していないケースです。

たとえば、DNS事業者を変更したにもかかわらず、レジストラ側のDSレコードが古いDNS事業者の情報のまま残っていると、検証に失敗します。

この場合、検証リゾルバは次のように判断します。

親ゾーンが示す鍵情報と、子ゾーンが提示するDNSKEYが対応していない

その結果、Bogusとなり、名前解決できなくなる可能性があります。

DNS事業者を移行する場合は、DNSSECの扱いを特に慎重に確認する必要があります。

RRSIGの期限切れ

DNSSECの署名には有効期限があります。

署名の更新が止まると、RRSIGが期限切れになり、DNSSEC検証に失敗します。

マネージドDNSサービスでは自動更新されることが多いですが、自前運用の場合は署名更新の自動化が重要です。

RRSIGが期限切れになると、DNSレコード自体が正しくても、検証リゾルバからは不正な応答として扱われることがあります。

鍵ロールオーバーの失敗

DNSSECでは、鍵を定期的に更新することがあります。

これを鍵ロールオーバーと呼びます。

鍵ロールオーバーでは、新しい鍵の公開、署名の切り替え、DSレコードの更新、古い鍵の削除などを適切な順序で行う必要があります。

順序を誤ると、検証リゾルバが正しい信頼の連鎖をたどれなくなり、名前解決障害につながります。

DNS事業者移行時のDNSSEC設定漏れ

DNSSECを有効にしたドメインでDNS事業者を移行する場合は、通常のNS切り替え以上に注意が必要です。

移行前後でDNSKEYやDSレコードの整合性を保つ必要があるためです。

移行手順を誤ると、DNSサーバーは応答しているのに、DNSSEC検証リゾルバでは名前解決できないという状況が起こります。

安全に移行するには、DNS事業者やレジストラの推奨手順に従うことが重要です。

場合によっては、次のような手順が必要になります。

移行先DNSでDNSSEC署名を準備する
↓
新しいDNSKEYに対応するDSレコードを親ゾーンに登録する
↓
TTLを考慮して反映を待つ
↓
NSレコードを切り替える
↓
旧DSレコードや旧DNSKEYを適切に削除する

ただし、実際の手順は利用サービスによって異なるため、事前確認が不可欠です。

DNSSEC導入のメリット

DNSSECを導入する主なメリットは次の通りです。

DNS応答の改ざんを検出できる

DNSSECを導入すると、DNS応答が途中で改ざんされた場合に検出できます。

攻撃者がIPアドレスを書き換えようとしても、有効な署名を作成できなければ、検証に失敗します。

これにより、ユーザーが偽のDNS応答をもとに不正なサーバーへ誘導されるリスクを下げられます。

DNSキャッシュポイズニング対策になる

DNSSECは、DNSキャッシュポイズニング対策として有効です。

リゾルバのキャッシュに偽のDNSデータが混入しても、署名検証に失敗すれば、そのデータは正当な応答として扱われません。

特に、金融、EC、SaaS、公共機関など、ドメインの信頼性が重要なサイトでは導入価値が高いといえます。

DNSを信頼基盤として活用しやすくなる

DNSSECによってDNSデータの信頼性が高まると、DNSを他のセキュリティ技術の信頼基盤として活用しやすくなります。

代表例がDANEです。

DANEでは、TLS証明書や公開鍵に関する情報をDNSに登録し、その情報をDNSSECで保護します。

これにより、DNSを使った証明書検証の補助的な仕組みを構築できます。

DNSSEC導入のデメリット・注意点

DNSSECにはメリットがある一方で、導入時に注意すべき点もあります。

設定ミスが名前解決障害につながる

DNSSEC最大の注意点は、設定ミスがあるとドメイン全体の名前解決に影響する可能性があることです。

たとえば、次のようなミスがあると検証に失敗します。

DSレコードの登録ミス
DNSKEYの更新ミス
RRSIGの期限切れ
鍵ロールオーバーの失敗
DNS事業者移行時のDS削除漏れ

DNSSEC検証リゾルバでは、これらの問題があるドメインをBogusとして扱い、名前解決に失敗する可能性があります。

そのため、DNSSECは「有効化すれば終わり」の機能ではありません。

導入後の監視や運用設計が重要です。

DNS応答サイズが大きくなる

DNSSECでは、通常のDNSレコードに加えて、RRSIG、DNSKEY、DS、NSEC、NSEC3などの情報を扱います。

そのため、DNS応答サイズが大きくなります。

応答サイズが大きくなると、環境によってはUDPの断片化やTCPフォールバックが発生することがあります。

現在のDNS環境ではEDNSなどにより大きな応答を扱いやすくなっていますが、古いネットワーク機器や不適切なファイアウォール設定がある場合は注意が必要です。

鍵管理が必要になる

DNSSECでは、秘密鍵を安全に管理する必要があります。

また、鍵のロールオーバー、署名更新、DSレコード更新などの運用も必要です。

マネージドDNSサービスを利用している場合は多くの作業が自動化されますが、自前運用では運用負荷が高くなります。

すべての利用者環境で検証されるとは限らない

対象ドメインがDNSSECに対応していても、利用者が使っているリゾルバがDNSSEC検証を行っていなければ、DNSSECの効果は限定的です。

DNSSECの恩恵を受けるには、どこかの段階でDNSSEC検証が行われる必要があります。

多くの場合、検証はユーザーの端末ではなく、ISPやパブリックDNSの再帰リゾルバで行われます。

したがって、DNSSECを導入する側だけでなく、検証するリゾルバ側の対応も重要です。

Webサイト運営・マーケティング視点でのDNSSEC

Webサイト運営やWebマーケティングの観点では、DNSSECは直接的にCVRや検索順位を上げる施策ではありません。

DNSSECを導入したからといって、検索順位が大きく上がる、広告効果が改善する、ページ表示速度が劇的に速くなる、といったものではありません。

しかし、DNSSECはブランド保護やセキュリティ基盤の強化という意味で重要です。

特に次のようなサイトでは導入価値が高いといえます。

サイト種別	DNSSECの重要性
金融・銀行系サイト	非常に高い
ECサイト	高い
SaaS・ログイン系サービス	高い
公共機関・自治体サイト	高い
医療・教育機関サイト	高い
ブランドサイト	中〜高
個人ブログ	必須ではないが導入価値はある

DNSSECは、ユーザーが正しいDNS情報を取得できるようにするための基盤技術です。

特に、なりすまし、偽サイト誘導、DNS改ざんによるブランド毀損が大きなリスクになるサイトでは、セキュリティ対策の一部として検討する価値があります。

一方で、DNSSECは運用ミスによる障害リスクもあるため、導入時には次の点を確認することが重要です。

DNS事業者がDNSSECを自動管理してくれるか
レジストラでDSレコードを正しく登録できるか
DNS移行時のDNSSEC手順が明確か
障害時にDNSSEC検証エラーを調査できる体制があるか
RRSIGやDS不一致を監視できるか

マーケティング担当者が直接DNSSECを運用するケースは少ないかもしれませんが、サイトの信頼性・ブランド保護・セキュリティ要件を考えるうえで、DNSSECの役割を理解しておくことは有益です。

DNSSECの仕組みまとめ

DNSSECは、DNSに電子署名を追加し、DNSデータの正しさを検証できるようにする仕組みです。

全体の流れをまとめると、次のようになります。

ゾーン管理者がDNSレコードを用意する
↓
秘密鍵でDNSレコードセットに署名する
↓
RRSIGとDNSKEYをDNS上で公開する
↓
親ゾーンにDSレコードを登録する
↓
検証リゾルバがルートから信頼の連鎖をたどる
↓
DNSKEYとRRSIGを使ってDNSデータを検証する
↓
検証に成功すればSecureとして扱う
↓
検証に失敗すればBogusとして扱う

最後に、重要ポイントを整理します。

項目	内容
DNSSECの目的	DNSデータの出所認証と完全性検証
暗号化の有無	DNSSEC自体は通信を暗号化しない
主要レコード	RRSIG、DNSKEY、DS、NSEC、NSEC3
信頼の仕組み	ルートから対象ドメインまでの信頼の連鎖
DSレコードの役割	親ゾーンに子ゾーンDNSKEYのハッシュ情報を登録する
RRSIGの役割	RRsetに対する電子署名
DNSKEYの役割	署名検証用の公開鍵
NSEC / NSEC3の役割	不存在応答を認証付きで証明する
防げること	偽造・改ざんされたDNS応答の検出と拒否
防げないこと	DNS通信の暗号化、HTTPSの代替、偽ドメイン取得の防止
運用上の注意	DS不一致、RRSIG期限切れ、鍵ロールオーバー失敗

DNSSECは、DNSをより信頼できるものにするための重要な技術です。

ただし、DNSSECだけですべてのセキュリティリスクを解決できるわけではありません。

Webサイトの安全性を高めるには、DNSSECに加えて、HTTPS、HSTS、適切な証明書管理、DoH / DoT、メール認証、フィッシング対策などを組み合わせることが重要です。

DNSSECはその中でも、名前解決の正しさを支える基盤的な技術だと理解するとよいでしょう。

以上、DNSSECの仕組みについてでした。

最後までお読みいただき、ありがとうございました。