DNSSEC運用を鍵のライフサイクルから見る －OCTO-035の紹介－

ICANNが公開している技術政策文書シリーズの中から、OCTO-035 Observing DNSSEC Key Lifecyclesを紹介します。

OCTO-035はICANNのOCTOから公開されている文書で、インターネット環境におけるDNSSEC鍵のライフサイクルについて観察したことをまとめています。本文書の主な想定読者と目的は以下のとおりです。

• DNSSEC署名を行っているDNS権威サーバ運用者: 自身の運用を振り返り、他のゾーンやTLDの運用と比較し、行った変更の影響を視覚化する。
• プロトコル開発者: プロトコルの使用状況を確認し、プロトコルやその一部について概念的にしか理解されていないことは何かを視覚化する。

本文書では視覚化による分析を行っていますが、要約の都合上、視覚化されたグラフなどはここでは掲載しません。ご興味のある方は、原文をご覧ください。

DNSSECには公開鍵暗号が利用され、鍵の管理は重要な運用事項です。一般的な鍵のライフサイクルは下のようになっており、DNSSECではキャッシュの影響を考慮して調整されているものの、大まかにこのパターンに従っています。

• creation: 鍵ペアを作成した状態
• distribution: 復号もしくは検証に使用してもらうため、また、この鍵ペアが確かに検証者が意図した相手に所有されていることを認識してもらうため、公開鍵を配布している状態
• active use: 暗号化や署名、復号や検証のために鍵ペアが利用されている状態
• retirement: 鍵ペアの利用を終了し、もしくは鍵ペアがもう利用されていないことを検証者に認識してもらっている状態
• elimination: 鍵ペアを削除した状態

DNSSECと鍵の概要

インターネット用語1分解説やインターネット10分講座でも解説していますが、DNSSECとはDNSに対し、データ作成元の認証やデータの完全性を確認できるように仕様を拡張するものです。データの作成元は、DNSSEC秘密鍵を用いて署名を行い、また、データを参照する側のDNSリゾルバ（クライアント）は、 送られてきたデータの署名をDNSSEC公開鍵で検証することで、情報が正しいものかどうかを判断します。

DNSSECで使用する鍵ペアにはKey Signing Key (KSK)とZone Signing Key (ZSK)の2種類があります。ZSKはゾーン内のリソースレコードセット(RRset)に対する署名・検証に使用され、KSKはZSK公開鍵に対する署名・検証に使用されます。それぞれの公開鍵はDNSKEY RRとして、署名はRRSIG RRとして公開されており、KSK公開鍵のハッシュ値をDS RRとして親ゾーンの権威サーバに登録・公開することで、Root Zoneから一つひとつのRRsetまでが鎖のように繋がり完全性を担保しています。

KSKとZSKでは役割が異なることから、本文書ではそれぞれ異なる標準的なライフサイクルを提示しています。

ZSKの標準的なライフサイクルは以下の5段階に分けられます。

• Created: 鍵は作成されたがまだ公開鍵がDNS上で公開されていない状態
• Pre-view: 公開鍵がDNSKEY RRとして公開されたがまだ署名応答していない状態
• Active use: 公開鍵がDNSKEY RRとして公開され、署名応答している状態
• Post-view: 公開鍵がDNSKEY RRとして公開されているが、署名応答をやめた状態
• Discarded: 公開鍵がDNS上で公開されなくなり、鍵が削除された状態

このライフサイクルを外れる最も一般的な例は、アルゴリズムロールオーバーです。これはDNSSECに使用する暗号アルゴリズムを変更する際に行うもので、鍵が作成された後署名応答を開始してから公開鍵がDNSKEY RRとして公開されます。

一方、KSKの標準的で簡略化されたライフサイクルは以下の5段階に分けられます。

• Created: 鍵は作成されたがまだ公開鍵がDNS上で公開されていない状態
• Un-chained: 公開鍵がDNSKEY RRとして公開され署名を作成している状態
• Chained (Active): 公開鍵がDNSKEY RRとして公開され、署名応答しており、親ゾーンでDS RRが公開されている状態
• De-chained: 公開鍵がDNSKEY RRとして公開されているが署名応答をやめた状態
• Discarded: 公開鍵がDNS上で公開されなくなり、鍵が削除された状態

ZSKのライフサイクルとの大きな違いは、親ゾーンのDS RRが関係してくる点です。KSKの更新はほとんどの場合、当該ゾーン管理者と親ゾーン管理者の2者が連携して行います。当該ゾーン管理者は新しいKSKの公開鍵をDNSKEY RRとして公開し署名応答しますが、親ゾーン管理者は新しいKSKを指すDS RRを子ゾーンの名前で親ゾーンにて公開し、かつ親ゾーンのZSKでそのDS RRsetを署名する必要があります。

このように、鍵管理の一側面として鍵のライフサイクルを定義すること、特に鍵更新においては更新前後それぞれの鍵のライフサイクルに従った入れ替えを行うことで、DNSSECをより安全に運用できると考えられます。

Root zoneでのライフサイクル

Root zoneでは2010年中頃からDNSSEC運用を開始しましたが、本文書では2011年7月1日から2021年7月10日の約10年分のデータを使用しています。

ZSKは四半期ごとに変更されています。ZSKのライフサイクルをみると、まず10-12日間のPre-view期間があった後、四半期のActive use状態になり、10日間のPost-view期間を経てDiscardされていることがわかります。ある時刻にActive useとなっているZSKは一つのみです。

KSKはこれまで1度だけ変更されました。tag 19036である変更前の鍵は2018年10月11日までChained (Active)状態であり、同日から2019年1月11日までDe-chained状態になりました。その後2019年3月20日までの間はrevoked bitがセットされた状態で公開され続けました。一方、tag 20326である変更後の鍵は2017年7月11日から未署名ではあるものの、DNSKEY RRとして公開されました。2018年10月11日にはtag 19036の鍵がChained (Active)状態から外れると同時に署名応答を開始し、tag 20326の鍵がChained (Active)状態になりました。

gTLDでのライフサイクル

gTLDでの例として、2012年以前にほとんどの商用gTLDを運用していた3組織があげられています。これら3組織は2009年にDNSSECの運用を開始しており、10年以上の運用経験があるといえます。各運用者でのライフサイクルの詳細は要約の都合上省略しますが、大規模な運用者であっても運用途中にDNSSECへのアプローチを再考・変更していることが視覚化により分かりました。人員の入れ替えや技術の発達などの要因はプロトコル開発中には考慮されていませんが、運用者はそれぞれに対応する必要があります。

ccTLDでのライフサイクル

ccTLDでの例として、運用開始当初に鍵更新を自動化した運用者、アルゴリズムロールオーバーを2回行った運用者、一度も鍵更新を行っていない運用者の3組織があげられています。1つ目の運用者では、自動化を導入したものの、数回の手作業でのオペレーションがあったことがわかります。2つ目の運用者では、さまざまな困難が伴うとされているアルゴリズムロールオーバーをどのように実施したのかが、視覚化により分析されています。3つ目の運用者では、10年間ずっと同じ鍵を使用し続けており、DNSSECの運用によるオペレーションミスやセキュリティインシデントが報告されていません。

まとめ

本文書では、あらゆるドメイン名でのDNSSEC鍵のライフサイクルを視覚化することによって、多くのことが推測・分析できることが分かりました。DNSSECが普及し始めてから今日に至るまで、レジストリは自動化やさまざまな試行錯誤の上で進歩してきています。

DNSSECの運用においては、ゾーンの状態やトラストチェーンの維持が注目されがちですが、本文書では鍵の視点に立ってライフサイクルを視覚化することで、新たな観点からDNSSEC運用を観察・評価することができました。この観点は、実際の運用計画や評価においても参考に値するでしょう。

一部の運用者は、プロトコル開発者が予期していた手順と異なる手順を取っていました。単に運用者が適切でない手段をとっていたというケースもありますが、なんらかの運用者側の理由に基づいた手段をとっているということもしばしばあります。つまり、新しい技術の普及戦略においては、運用者への教育に圧力をかけるのではなく、プロトコル開発の初期段階から運用側の現実を考慮すべきであるといえ、この点はDevOpsの概念にも通じるところがあります。

今回の観測では、各々の変更の際に検証エラーが発生したかどうか、変更による影響はどの程度だったのかという点が抜け落ちています。本文書の作成中はCOVID-19の影響で国をまたいだ調査が難しかったことから、「行動制限が解除されれば各運用者への追加の聞き取り調査も可能だろう」としています。

DNSSECの運用において特に懸念される、権威サーバ側の設定変更による名前解決への詳しい影響について、個々の運用例での運用者による評価など、今後の調査でさらに一般の運用者に対する有益な情報提供が可能となることを期待します。