DNSSECチェック

DNSSECがふさぐ穴

コンピューターが「example.comのアドレスは？」と尋ねると、答えは保護されていない小さなパケットで返ってきます。本来のDNSには、受け取った側が誰の書いたものかを確かめる手段がありません。あなたとネームサーバーの間にいる者や、偽の答えをリゾルバーのメモリに紛れ込ませた者は、訪問者やメールを自分の選んだマシンへ送ることができます。

DNSSECは署名を加えます。ゾーンの所有者はすべてのレコードの組に秘密鍵で署名し、対になる公開鍵をDNSKEYレコードとしてゾーンに公開します。答えを受け取ったリゾルバーはその署名（RRSIG）も受け取り、レコードが所有者の公開したものとまったく同じであることを検証できます。DNSSECは何も暗号化せず、どの名前を調べたかも隠しません。答えが本物であることを証明する、それだけです。

指紋の連鎖

データと同じ場所に置かれた公開鍵では、たいした証明になりません。偽造者は両方を差し替えられるからです。そこで各ゾーンは、一つ上のゾーンに保証してもらいます。親ゾーンは子の鍵の短い指紋（ダイジェスト）であるDSレコードを公開し、自分の鍵でそれに署名します。親の鍵も同じようにその親が保証し、それがルートゾーンまで続きます。リゾルバーがあらかじめ知っておく必要があるのはルートの鍵だけで、これはリゾルバーのソフトウェアに同梱されています。

example.comの場合、経路は次のとおりです。ルートの鍵、ルートにあるcomのDS、comの鍵、comにあるexample.comのDS、example.comの鍵、署名されたレコード。一つでも欠けたり間違ったりしていれば、証明は失敗します。

DSレコードは、DNSホストの外にある部分です。レジストラーを通じてレジストリに渡され、失敗の多くはこの分担から生まれます。

このチェックが行うこと

ルート、トップレベルゾーン、そしてあなたのドメインまでの各ゾーンについて、当サーバーは親にあるDSレコードとゾーンのDNSKEYレコードを読み取ります。検証をオフにした状態（「checking disabled」フラグ）で公開リゾルバー経由で読むため、壊れたゾーンでも中身を調べられます。鍵ごとにキータグを計算し、DSごとに同じハッシュ関数（RFC 4034）で鍵からダイジェストを計算し直して、1バイトずつ比較します。

次に、検証を行う三つの公開リゾルバー（Cloudflare、Google、Quad9）に、今度は検証をオンにしてドメインのSOAレコードを尋ねます。答えを検証できたリゾルバーはADフラグ（「認証済みデータ」）を立てます。問題を見つけたリゾルバーはSERVFAILを返します。指紋の照合は当サーバーが自分で行いますが、署名の検証はしません。その判定はリゾルバーに任せています。

このチェックはさらに、廃止済みまたは弱いアルゴリズム（RSA/MD5、DSA、RSA/SHA-1、DS内のSHA-1ダイジェスト）、古い鍵の残りのDS、有効期限まで3日を切った署名を指摘し、存在しない名前の証明にゾーンがNSECとNSEC3のどちらを使っているかも示します。

壊れた連鎖を直す

壊れた連鎖は、DNSSECがまったくない状態より悪いものです。検証リゾルバーが答えを拒否するからです。よくある経緯はこうです。ドメインを新しいDNSホストへ移したが、古いDSレコードがレジストラーに残り、それがもう存在しない鍵を指している。

1. すぐに復旧したい場合は、レジストラーでDSレコードを削除します。ドメインは未署名になり、キャッシュが切れれば（通常1日以内に）誰にとっても動くようになります。
2. DNSSECを維持したい場合は、現在のDNSホストのDNSSECページを開き、表示されるDSレコード（キータグ、アルゴリズム、ダイジェストタイプ、ダイジェスト）をコピーして、古いものと置き換える形でレジストラーに入力します。
3. 次の引っ越しの前には、まずDSレコードを削除して1日待ち、ネームサーバーを変更してから、署名して新しいDSを公開します。

「設定が途中」の場合は、DSレコードを公開して作業を終えるか、DNSホストで署名をオフにしてください。