DNSSEC Look-aside Verification を使うべきでない3つの理由

DNSSEC は本来ルートゾーンから順番に証明していき、最後にホストのレコードを確認するという仕組みになっています。ところが、大人の事情で上位ゾーンに鍵を登録できない人のために、DNSSEC Look-aside Verification (DLV, RFC5074) という仕組みがあります。

DLV は、以下のような仕組みで動きます。

1. example.net をルートゾーンからの連鎖で証明しようとする
2. どこかで連鎖が止まっている(上位ゾーンに登録されていない)ため、確認できない
3. example.net.dlv.isc.org をに DLV レコード(DS レコードとほぼ同等)が登録されていないか確認する
4. 得られた DLV レコードを使って example.net の証明をする

この dlv.isc.org を DLV に使って良いというのは別途設定し、 trust anchor をリゾルバに登録しておきます。

これだけ見ると、一見便利そうなのですが、私は使うべきではないと思います。3つほど理由をあげます。

DLV を有効にすると遅くなる

本来の認証の連鎖が途切れた時に DLV が引かれますので、単純に2倍以上遅くなります。さらに、日本からだと dlv.isc.org の NS が遠くにあるので、かなり待たされます。これは単純にレスポンスの悪化につながります。

グラフは DNSSEC on, DNSSEC on + DLV有効, DNSSEC オフでそれぞれ名前を引いてみた場合の、レスポンスタイムになります(5回平均)。 jprs.jp は DNSSEC の鍵が正しく登録されているドメイン、yuryu.jp はされていないドメインになります。 計測は unbound 1.4.18 を用い、毎回の計測の前にリスタートしてキャッシュをクリアしています。また、実際のクエリタイムに近づけるために、 .jp 及び dlv.isc.org の SOA をクエリして、上位ゾーン情報はキャッシュ済みの状態です。

jprs.jp は上位ゾーンからの連鎖で正しく証明ができるので、 DLV のオンオフにかかわらずクエリタイムは一定です。ところが、 yuryu.jp のように証明できないドメインだと、 DLV のクエリが追加で走るのでとても遅くなります。 DNSSEC の on/off よりも重大なパフォーマンスの低下をもたらします。

DNSSEC がきちんと普及すれば問題ないのですが、DLV は「普及過程のためのworkaround」という位置づけです。ほとんどのドメインが署名されていない現状で、このパフォーマンス低下は許容できません。

鍵更新のポリシーが不透明

ルートゾーンの KSK は定期的に更新される、少なくとも5年に1度は更新されることになっています。また、 IANA によって鍵更新ポリシーや記録がきちんとメンテされています。 DLV のキーはこれと同等の基準では運用されていません。一応ポリシーは書かれてあるんですが、そこには「年1回 KSK 更新します」とあります。ところが実際には 2008年から鍵は更新されていません。

ソフトウェアのサポートが不十分

BIND は DLV の trust anchor も含めて自動更新に対応しています。ところが、 unbound の場合はルートゾーンの trust anchor については自動更新に対応しているものの、 DLV trust anchor は自動更新しません。

もし KSK が更新されたとなると、 trust anchor も含めてアップデートしなければなりませんが、これが人力になってしまいます。放置すると証明できないゾーンが生まれることになります。

そして、別の記事にも書きましたが、リゾルバによって挙動が異なる場合があります。利用者も少ないので、枯れているとは言いがたい状況です。

まとめ

以上3つの理由により、少なくとも現状は DLV を使うのは望ましくないと思います。 ルートゾーンが署名され、多くの ccTLD も署名されつつありますから、無理に DLV を用いて DNSSEC を導入するのではなく、上位ゾーンの対応を待つべきでしょう。