今回の元記事は、VeriSign Labs の DNSSEC Debugger というオンラインツールの結果ページです。
DNSSECというのは、ひとことで言うと DNSに暗号署名をつけて、返ってきた情報が改ざんされていないか確かめる仕組み です。
DNSは、たとえば「nic.de のIPアドレスはどれ?」と問い合わせたときに答えを返す、インターネットの電話帳みたいな存在です。
ただし普通のDNSは、答えの正しさを強く保証してくれません。そこで登場するのがDNSSEC。
署名付きのDNS情報をたどって、「この答えは本当に正規のものだよね?」を検証します。
DNSSEC Debugger は、その検証の流れをかなり細かく見せてくれるツールです。
正直、一般ユーザー向けというより DNS運用者やネットワーク好き向けの検査機 ですが、ログを読むとDNSSECの仕組みが立体的に見えてきます。こういうの、私はかなり好きです。
検査対象は nic.de。
.nic.de は、ドイツの .de ドメイン管理に関わる名前空間のひとつで、かなり重要そうな立ち位置です。
ツールの出力では、まず 「DS =20326/SHA-256 is now in the chain-of-trust」 と出てきます。
続いて DS =38696/SHA-256 も chain-of-trust に入ったと表示されます。
ここで出てくる chain-of-trust は、日本語にすると 信頼の連鎖 です。
「上位のDNSがこの鍵を信頼している」→「その鍵が下位のDNSを信頼する」→「さらにその下を信頼する」、というバトンリレーのような考え方です。
DNSSECは、いきなり「この答えを信じて!」とは言いません。
むしろ「親が子を保証し、さらにその子が孫を保証する」という、やや面倒だけど堅実な仕組みです。
この面倒さが、逆にセキュリティの強さになっています。
ログの最初の大きな山場は、ルートゾーン 「.」 の確認です。
ツールはまず、
./DNSKEY を問い合わせという流れをたどっています。
ここで DNSKEY は、ざっくり言えば DNSSEC署名を検証するための公開鍵 です。
鍵があって、署名があって、検証できる。これがDNSSECの基本セットです。
結果として、ルートゾーンの DNSKEY が複数見つかっています。
特に注目されているのは、keytag 20326 と 38696 です。
ツールはそれらを使って、ルートのDS情報と照合し、「このDNSKEYは信頼できる」と判断しています。
ここ、地味ですが重要です。
インターネットの最上位にあるルートが壊れていたら、下のすべてが崩れます。
なのでルートの検証が通っているのは、DNSSECの世界ではかなり心強いサインです。
続いてツールは、a.root-servers.net に対して nic.de/A を問い合わせています。
ここで A レコードというのは、ドメイン名をIPv4アドレスに対応づける情報 のことです。
ただし、見ているのは nic.de そのもののAレコードだけではなく、途中の委任情報です。
de. の NS レコードが並び、さらに de. の DS レコードも返ってきます。
このあたりで出てくる NS は、そのゾーンの面倒を見るDNSサーバー を示すもの。
つまり「.de の答えは、このサーバーたちに聞いてね」という案内板です。
そして重要なのが DS レコード。
DSは Delegation Signer の略で、親ゾーンが「この子ゾーンのDNSKEYはこれだよ」と保証するための情報です。
ログでは、
de. IN DS (26755 8 2 ...)RRSIG で署名されているDNSKEY =54393 で検証できるという流れになっています。
つまり、
ルートの鍵 → .de のDS → .de のDNSKEY
という信頼のつながりが確認できているわけです。
これはDNSSECの本質そのものです。
「正しい親が、正しい子を紹介している」ことを、暗号で証明する。
口約束ではなく、機械で検証できるのが強いですね。
続いて l.de.net に対して de/DNSKEY を問い合わせています。
ここで返ってきた de ゾーンの DNSKEY は複数あり、keytag 32911 と 36046 のような値が見えます。
ログの抜粋は途中で省略されていますが、全体としては de ゾーンの鍵も取得し、そこから下位の nic.de をたどる準備ができています。
この段階で面白いのは、DNSSECが「ただ鍵を持っている」だけでは足りないことです。
親ゾーンのDSと、子ゾーンのDNSKEYが一致すること が必要です。
さらに、そのDNSKEYで署名されたRRSIGを検証できて、初めて「信頼できる」と言えます。
この二重三重の確認、面倒ではあるんですが、セキュリティ的にはかなり筋がいいと思います。
雑に言うと、身分証を見せるだけではなく、紹介状も確認している ようなものです。
ログには何度も RRSIG が出てきます。
これは Resource Record Signature の略で、DNSレコードの集合に対する電子署名です。
たとえば、DNSKEYレコードのセットに対してRRSIGがつくと、
ことを検証できます。
今回のログでは、
RRSIG =20326 and DNSKEY =20326/SEP verifies the DNSKEY RRsetDS =26755/SHA-256 verifies DNSKEY =20326/SEPのように、署名と鍵の整合性が確認されています。
ここでの SEP は Secure Entry Point の略で、ざっくり言えば そのゾーンの信頼の入口になる鍵 です。
全部の鍵が同じ重みというわけではなく、DNSSECでは「この鍵を信頼の起点として扱う」という役割分担があります。
ログ全体を、人間向けに超ざっくり言い換えるとこうです。
de のDSとDNSKEYを照合するde の信頼がつながったので、さらに nic.de 側へ進むつまり、nic.de のDNSSEC検査は、親から子へとたどる検証の連続 です。
この流れが通ると、名前解決の途中で答えが改ざんされていない可能性が高いと判断できます。
個人的に面白いのは、DNSSECが思っていた以上に「登場人物が多い」ことです。
ふつうのユーザーは、ブラウザでURLを打てば終わりです。
でもその裏では、こんなふうに何段階もの確認が走っている。
しかもDNSSECを有効にすると、その確認プロセス自体がかなり見える形で残る。これはなかなかロマンがあります。
一方で、運用者目線だとかなりシビアです。
どこか1か所でもDSやDNSKEYの整合性が崩れると、名前解決に失敗しうるからです。
DNSSECは強いけれど、設定ミスに優しくない。ここはかなり現実的な弱点だと思います。
このDNSSEC Debuggerの結果から読み取れるのは、nic.de に至るDNSSECの信頼経路が順に検証されている ということです。
特に、
de のDSとDNSKEYの照合がきちんと進んでいるのが見えます。
DNSSECは普段は意識されませんが、こういうログを見ると「DNSってただの住所録ではなく、かなり繊細な信頼システムなんだな」と実感します。
正直、最初は難解です。でも読み解けるようになると、かなりおもしろい世界です。