DNSSECとは ― DNS応答の正当性を検証する仕組み

DNSSEC（DNS Security Extensions）は、DNSの応答のすり替えを見分ける仕組みです。応答をすり替えられると、正しいドメイン名を入れても偽のサイトへ誘導されます。DNSSECはDNSの応答に電子署名を付け、受け取った側が本物かどうかを検証できるようにします。

検証できるのは、応答が正しい持ち主のものであることと、途中で書き換えられていないことの2点です。名前からは暗号化を思い浮かべがちですが、DNSSECは通信の内容を暗号化しません。目的は偽の応答を見分けることで、内容を隠すことではありません。署名には、公開鍵暗号の秘密鍵と公開鍵を使います。

キャッシュDNSサーバは、PCの代わりに問い合わせをして、結果を一時的に記憶するサーバです。従来のDNSでは、このサーバは受け取った応答を正しいものと信じるしかありません。応答の送り主が本物かどうかを確実に確かめる手段が、DNSの仕組みの中にないためです。

この弱点を突くのが、DNSキャッシュポイズニングです。攻撃者は偽の応答を送り込み、キャッシュDNSサーバに記憶させます。記憶された偽の情報は本物として扱われ、受け取る側には偽物と判別できません。利用者は、正しいドメイン名を入力しても、フィッシングサイトに誘導されるおそれがあります。

DNSSECは、応答に署名を付けることで、この偽物を見分けられるようにします。署名は、ゾーンを管理する側が秘密鍵で作ります。ゾーンとは、example.comのように同じ管理者が管理するDNSの範囲です。攻撃者は秘密鍵を持たないため、正しい署名を付けた偽の応答は作れません。この手口は、中間者攻撃で通信に割り込む経路の1つにもなります。

DNSSECでは、DNSに新しい種類のレコードを足します。仕組みの中心になるのは、次の3つです。

署名の対象は、同じ名前で同じ種類のレコードをまとめた組（RRset）です。例えばwww.example.comのAレコードが2つあれば、その2つを1組として署名します。

署名はゾーンの秘密鍵で作り、DNSKEYに入れた公開鍵で検証します。DSに入るハッシュ値の性質は、ハッシュ関数の記事で説明しています。DSは親ゾーンに置くため、example.comのDSはcomゾーンに入ります。対応するDNSKEYは、example.comゾーンに入ります。

KSKとZSK：鍵の役割分担

ゾーンの鍵は、役割によって2種類に分けて運用するのが一般的です。ZSK（Zone Signing Key）は、ゾーンのレコードに署名する鍵です。KSK（Key Signing Key）は、ZSKを含むDNSKEYの組に署名する鍵です。

こう分けると、ZSKは頻繁に交換する方針にできます。KSKは有効期間を長くして、親ゾーンから指される鍵として同じものを長く使えます。親のDSが指すのは、DNSKEYの組に署名する側の鍵、つまりKSKです。検証の手順は、2つの鍵を区別しません。分けるのは運用上の取り決めです。

署名を確かめるには、署名に使った鍵が本物だと分かっている必要があります。偽の鍵で偽の署名を付けられては、検証の意味がありません。

そこで、鍵そのものが本物かどうかを、1つ上の親ゾーンの情報で確かめます。親ゾーンは、子ゾーンのDNSKEYのハッシュ値をDSとして持ち、そのDSに親の署名を付けます。この連なりを信頼の連鎖（chain of trust）と呼びます。

連鎖の起点は、トラストアンカーです。キャッシュDNSサーバにあらかじめ設定しておく公開鍵（またはそのハッシュ値）を指します。多くの場合は、ルートの公開鍵を1つだけ設定します。トラストアンカーは、DNSの外の信頼できる方法で入手します。

次の図は、www.example.comのAレコードを検証する流れです。example.comのゾーンは署名されているものとします。

検証するのは、キャッシュDNSサーバです。ルートから順にたどり、途中で1か所でも確かめられなければ、その先は信じません。PCの中の問い合わせを出す機能（スタブリゾルバ）が自分で検証する形もありますが、ここでは扱いません。

連鎖は、途中のゾーンがすべて署名されて初めて成り立ちます。JPRSの資料によると、署名の正式運用は、ルートゾーンが2010年7月に始まりました。 .jpは2011年1月、.comは2011年3月です。DNSSECは、ゾーンを管理する側と応答を受け取る側の両方が対応して、初めて働きます。

鍵や署名に問題が起きたときの扱いは、場面によって違います。検証がどこで止まり、応答がどう扱われるかが変わります。

検証に失敗した応答は使われません。キャッシュDNSサーバは、問い合わせたPCにエラー（RCODE 2、SERVFAIL）を返します。この失敗は攻撃だけでなく、設定ミスやデータの破損でも起こります。親にDSが無い場合は、失敗ではなく、署名のないゾーンとして扱われます。子ゾーンを検証するかどうかは、親のDSで決まります。

守るもの

• 応答が、ゾーンの正しい持ち主のものであること
• 応答が、途中で書き換えられていないこと

守らないもの

• 問い合わせと応答の内容を隠すこと
• DoS攻撃を防ぐこと
• 署名されていないドメインの応答

内容を隠すのは、DNSの通信を暗号化するDoHやDoTの役割です。DNSSECはDNSのデータそのものを守り、DoHとDoTは通信路を守ります。DNSの記事でも、両者は目的の違う別の仕組みとして紹介しています。DNSに公開鍵を置いて署名を確かめる考え方は、SPF・DKIM・DMARCの記事で説明するDKIMにも使われています。

• RFC 4033（DNSSECの目的と用語、提供するもの・しないもの）
• RFC 4034（RRSIG・DNSKEY・DSレコードの中身）
• RFC 4035（検証の手順、検証に失敗したときの扱い）
• ICANN「DNSSEC – What Is It and Why Is It Important?」（信頼の連鎖とトラストアンカー。多くのリゾルバはルートの公開鍵だけを設定すること）
• JPRS「DNSSECの概要と今後の展開」（2011年4月現在。DNSキャッシュポイズニングとの関係、信頼の連鎖、ルート・.jp・.comの運用開始時期）