イベントレポート
Internet Week 2017
「KSKロールオーバーはまだ終わっていない」~今年の「DNS DAY」の話題から
2017年12月13日 06:00
「向き合おう“グローバル”インターネット」をテーマに、11月28日から12月1日まで開催された「Internet Week 2017」。その中から、いくつかのセッションの模様をお伝えする。
- がんばりすぎないルーティングとは? 日本人はギリギリ運用しすぎ?(12月1日付記事)
- IoT機器のマルウェア感染、国内で1日8000台を観測、一番の狙われどころはtelnet(12月5日付記事)
- Wi-Fiストレージ「ポケドラ」の脆弱性・出荷停止から学んだ、IoTハードウェアメーカーとしての取り組み(12月6日付記事)
- 変化するDNSとサーバー証明書の関係~「ランチのおともにDNS」より(12月8日付記事)
- 「KSKロールオーバーはまだ終わっていない」~今年の「DNS DAY」の話題から(この記事)
- シンガポールとAPNICから見た、アジアと日本のインターネット(12月15日付)
- 1995年ごろのAPNICやISOCや「インターネットマガジン」を振り返る(12月15日付)
11月30日にはDNSに関する話題を集めたプログラム「DNS DAY」が開催され、今年も盛り沢山な発表が用意されたが、ここではDNS DAYを契機とし、ルートゾーンKSKロールオーバーにまつわるこれまでの経緯と現在の状況について、重点的に取り上げる。
ユーザー数あたりのクエリ数は頭打ち? 全TLDのドメイン名数の合計も初めて減少
DNS DAYで恒例となっている、各関係者がDNSに関するこの1年間の動向をまとめて報告する「DNS Update」。その発表の中から、興味深いデータをいくつかピックアップする。まず、株式会社日本レジストリサービス(JPRS)の平林有理氏から報告された「JP DNS Update」から、JPドメイン名の登録数の推移(図1)とJP DNSへのクエリ数の推移(図2)を紹介する。
これらを見ると、登録数・クエリ数のいずれも堅調な伸びを示していることが分かる。特に、クエリ数については2012年1月の月間総クエリ数を100%としたときの伸び率が2017年11月1日の時点で188%ということなので、増加割合はまだまだ大きく、JPドメイン名がよく使われていることが見て取れる。
続いて、NTTコミュニケーションズ株式会社の小坂良太氏による「DNS Update~フルサービスリゾルバー[*1]~」から、長期的クエリ(DNSの問い合わせ)の傾向と分析を紹介する。
この発表で興味深いのは、クエリ数自体は増加し続けているが、総クエリをユーザー数で割った値(ユーザーあたりのクエリ数)の増加は鈍化傾向にあるという点である(図3)。
小坂氏からは、鈍化した原因はまだ不明だが、宅内ルーターはオンになっているがネットをあまり使わないユーザーが増加したか、あるいは海外を含む網外からのIPアドレスが多く検出されたことで平均値が下がったからではないかという見立てが示された。また、図4に示されるように、1日あたり1000以下のクエリしか送信しないユーザーの割合が増加していることも示された。こうした変化については、今後の調査と分析に期待したい。
JPRSの宇井隆晴氏による「DNS Update~ドメイン名全般~」からは、全TLDのドメイン名数の合計が微減したという数字を紹介する。2016年6月には3億3460万件であったが、2017年6月には3億3190万件になっている。宇井氏によると、「毎年報告してきたが、ドメイン名数の合計が減ったのは初めて」とのことであった。このデータはVeriSignが四半期ごとに発表している統計情報使用しているとのことだが、図5に示されたグラフでは、赤で示されたccTLDの数が大きく減っていることが確認できる。近年では、中国の国内政策により.cnのドメイン名数が大きく変動するケースが見受けられたり、gTLD化しているccTLDが期間限定で行うキャンペーンの開始・終了により登録数を大きく変動させたりといった事例が観測されているので、今回の減少の背景にも、そうした何かしらの変動要因があったのかもしれない。
また、宇井氏からは、政治的・社会的な話題として、EUのGDPR(General Data Protection Regulation:一般データ保護規則)がWhoisに影響を及ぼしていることが示された。GDPRとは、2016年4月27日に採択され、2018年5月25日からすべてのEU加盟国に直接かつ一律に適用されることになる、EUの個人情報保護制度である(この件についてご興味のある方は、一度記事にしている[*2]のでそちらを参照していただきたい)。
GDPRが怖いのは、GDPRの域外適用や、執行および制裁の強化といった点などに不明点が多いことにある。さらに、違反した際の制裁金が非常に高額であることから、事業者側はどうしても防衛的にならざるを得ない。Whoisの提供はgTLDレジストリ/レジストラの基本的な役割の1つであり 、インターネットの円滑な運用において重要な役割を担っているため、過大な影響が出ないことを望みたい。
ルートゾーンKSKロールオーバーの本質とは
DNSSECは一言で言うと、「本物のDNS応答を本物だと確認できるようにするようにするための技術」である。DNSSECになじみのない方のために、その仕組みについて改めて簡単に説明する。
DNSは、インターネットにとって欠かせない基盤技術の1つである。しかし、その仕様上、悪意のある第三者がフルサービスリゾルバーに外部から偽の応答を注入可能であることが以前から問題視されてきた(この攻撃手法は「DNSキャッシュポイズニング[*3]」と呼ばれる)。そこで、権威DNSサーバーからの応答に偽造不可能な電子署名(以下、単に署名と記述する)を付加し、フルサービスリゾルバー側で「付加された署名を検証することで、本物のDNS応答を本物だと確認できるようにする」というのがDNSSECの基本的な仕組みである。
DNSSECの重要な概念の1つに、「信頼の連鎖」がある。信頼の連鎖とは、DNSSEC署名に使われた鍵が正当なものであることを、DNSの階層構造に対応したかたちで証明するための仕組みである。
信頼の連鎖は、自分の鍵から生成されたDSレコードを親ゾーンに登録し、そのDSレコードを親ゾーンが自分の鍵で署名・公開することで構築される。実際のDNSSECではゾーンごとにZSK(ゾーン署名鍵)とKSK(鍵署名鍵)の2種類の鍵が使われ、親ゾーンへの登録にはKSKから生成されたDSレコードを用いるが、信頼の連鎖の原理は同じである。
分かりにくいかもしれないので、jpとルートゾーンの間で説明しよう。jpゾーンは信頼の連鎖を構築するため、jpのKSKから生成されたDSレコードをルートゾーンに登録し、ルートゾーンではjpゾーンから受け取ったDSレコードを自分のZSKで署名・公開する。
ポイントは、信頼の連鎖の構築には「親ゾーンへのDSレコードの登録」と「親ゾーンにおけるDSレコードの署名・公開」の2つが必要であるということである。
では、ルートゾーンではどのようになるのか。ルートゾーンには親が無いため、親ゾーンにDSレコードを登録することができない。そのため、DNSSECではルートゾーンのKSKの検証鍵(公開鍵)そのもの、または検証鍵に対応するDSリソースレコードを署名検証する「DNSSECバリデーター」にあらかじめインストールしておき、信頼の起点として扱う。DNSSECではこれを「トラストアンカー」と呼んでいる。
つまり、世界中で稼動しているすべてのDNSSECバリデーターは、ルートゾーンのKSKに対応する情報(公開鍵またはDSレコード)を、トラストアンカーとして保持していることになる。そのため、ルートゾーンのKSKを更新(ロールオーバー)する場合、DNSSEC検証をしているこれらのDNSSECバリデーターのすべてのトラストアンカーを、新しいKSKに対応したものに更新する必要がある[*4]。このことが、現在話題になっているルートゾーンKSKロールオーバーの本質である。
関係者にも突然であったKSKロールオーバーの延期
インターネットにおけるルートサーバーの重要性、そして、今回のルートゾーンKSKロールオーバーが2010年のDNSSECの運用開始後初の実施であることから、作業を進めるにあたり専門家によるデザインチームがICANNに組織され、技術的な検討と実施計画の立案が行われた。この計画に従い、新KSK(KSK-2017)が2016年10月27日に作成され、2017年7月11日にルートゾーンで公開されている。
その後、2017年9月19日のルートゾーンZSKのロールオーバー[*5]に伴うDNSKEYリソースレコードの応答サイズの増加と2017年10月11日のKSK-2017による署名開始に際し、国内外のさまざまな関係者から、対応状況の再確認が呼び掛けられた。
2017年9月19日の応答サイズの増加は予定通りに実施され、特に問題の発生は報告されなかった。しかし、2017年9月27日に、10月11日に予定されていたKSK-2017による署名開始を延期する旨が、ICANNから突然発表された[*6]。今回、「KSKロールオーバー」と題されたセッションにおいて行われたJPRSの米谷嘉朗氏の報告でも、今回の延期は関係者にとっても寝耳に水であったことが見て取れる(図7、図8)。
簡単に言えば、調査対象となったDNSSECバリデーターのうち約5%が現KSK(KSK-2010)のみを保持している状況であり、ルートゾーンKSKロールオーバーに必要な準備がされていない、かつ、5%という数字は無視できないということである。
図9は2017年5月~11月におけるトラストアンカーの保持状況を調査したものであるが、作業延期の発表後、赤丸で示された部分にあるようにKSK-2010とKSK-2017の両方を保持している割合が減り、KSK-2010のみに戻したところが意外とあることが見て取れる。RFC 5011によるトラストアンカーの自動更新を有効にしている場合、今回の作業延期により自動的にKSK-2017が削除されることはないため、この部分の変化についてはサーバーの管理者が、新しいトラストアンカーを手動で削除したのではないかと推測されている。
米谷氏は発表の最後で「ルートゾーンKSKロールオーバーは終わっていません」とし、今回はKSK-2017による署名開始、およびそれ以降の関連作業が延期になっただけであり、作業そのものが停止されたわけではないこと、作業に失敗して設定を元に戻した(ロールバックした)わけではないことが示され、フルサービスリゾルバーの運用者に対し、対応の継続が呼び掛けられた。
より重要になる情報収集
今回のDNS DAYでは、ここで取り上げた話題以外にも、「DNSに対するDoS攻撃とその対策」や「グローバルのDNS事情」といった、興味深いテーマで発表が行われている。Internet Weekでは一定期間が経過した後に資料が公開されるが、やはりその場でしか公開されない資料や発言はとても重要である。また、DNS DAYに続いて行われたDNSOPS.jpが主催する「日本DNSオペレーターズグループBoF」においても多様な話題が取り上げられた。
情報収集が以前にも増して重要になってきている今、このような場に参加することの意味はより大きくなってきているのではないだろうか。
[*1]……ユーザーからのクエリを受け付け、名前解決を実行するDNSサーバー。フルサービスリゾルバーは、キャッシュDNSサーバーとも呼ばれる。
[*2]……参照:不明点の多いEUの「一般データ保護規則(GDPR)」、日本の企業はどう対応すべきか
[*3]……DNSキャッシュポイズニング(JPRS用語辞典)
[*4]……運用コストの軽減のため、トラストアンカーを自動更新するための仕組みがRFC 5011として標準化されている。また、最新版の「BIND」や「Unbound」には、現・新双方のトラストアンカーがプリインストールされている。
[*5]……ルートゾーンのZSKは3カ月ごとに更新されている。
[*6]……ICANNから発表された延期の理由が、JPRSのDNS関連技術情報とJPNICのブログで解説されている。
参考:ルートゾーンKSKロールオーバーについてのご質問とその回答(JPRS)
参考:延期となったKSKロールオーバーについて(JPNIC Blog)