先日、DNS over httpsについての記事を書きました。今回はDNSSECについて取り上げます。
DNS over httpsは通信経路の暗号化により、通信内容の盗聴や中間者攻撃を防ぐことを目的としています。
これに対して、DNSSECは受け取ったDNSクエリが改竄されていないことや、正当なDNSコンテンツサーバから受け取ったものであることを担保するものです。
そのため、「DNSSECを導入したから、DNS over httpsは要らない」というものではなく、相互に補完する機能であるという点です。
DNSSECとはどういう仕組みなのかについて書いて行きます。
たとえば、www.example.co.jpというWebサーバがあるとします。example.co.jpゾーンを管理しているDNSサーバをns.example.co.jpとします。同ゾーンのリソースレコード（問い合わせの回答）からハッシュ値を求め、これに対してns.example.co.jpの秘密鍵で署名します。
そして、example.co.jpゾーンにTXTレコードで公開鍵を記述しておきます。
問い合わせたクライアントは得られた公開鍵で署名を検証します。返ってきたDNSクエリからハッシュ値を求め、これと比較して値に差異がなければ、情報が正しいことを確認出来ます。
クライアントとサーバの間での電子署名の検証というだけであれば、これで良いです。
ここで問題になるのは、「ns.example.co.jpというDNSサーバの正当性をどうやって担保するのか？」という点です。これだけでは、ns.example.co.jpに置かれている公開鍵が本物なのかどうかを判断する基準がありません。ちょうどSSLサーバ証明書におけるオレオレ証明書みたいなものですね。
「俺が正しいと言ってるから、この証明書は正しいんだ！」と言っても、誰も信用してくれませんよね。
SSLサーバ証明書の場合も、デジサート（Symantecから継承）やグローバルサインなどの大手認証局が発行することで正当性を担保しています。（認証局同士の相互認証により、各認証局の正当性は担保されています）
DNSSECの場合は、自ゾーンの正当性を親ゾーンが担保し、親ゾーンはその親ゾーンが担保する…というように、親子間のゾーン連鎖により信頼性を担保します。（ルートサーバには署名がなされていないそうですが、一部のトップレベルドメインには管理下のゾーンの公開鍵が公開されているそうです）
DNSSECでは「署名の検証」というプロセスがありますので、通常の問い合わせよりも余分に時間がかかることになります。
DNSSECの鍵や署名に関するトピックスもありますが、次の機会に改めて書くことにします。
