Salesforceはマルチ署名DNSSECを採用し、実行に移す

現在の DNSSEC セキュリティ プロトコルを複数の DNS プラットフォームに拡張する計画が Salesforce の支援を受けており、このアプローチの最初の概念実証実装が木曜日に発表されました。

CRM モンスターおよびトラフィック管理会社 NS1 のエンジニアは、異なる DNS プロバイダーから複数の公開キーを取得し、独自の DNS レコードに署名して公開できる実用的な REST API を持っていると主張しています。

言い換えれば、彼らは、やや厳格な DNSSEC プロトコルを拡張してより柔軟に動作させる方法、特にジオルーティング (ユーザーが物理的な場所に応じて誘導される) や負荷分散などの最新のトラフィック管理アプローチと連携する方法を考案したのです。

両社は、このアプローチにより、企業は既存のトラフィック管理アプローチを踏襲しながら、なりすましやキャッシュポイズニング攻撃の制限など、DNSSEC が提供する追加のセキュリティの恩恵を受けることができるため、DNSSEC の広範な導入に対する障壁がさらに 1 つ取り除かれると主張しています。

このアプローチはインターネット技術タスクフォース（IETF）によって推進されており、現在3回目のイテレーションが進行中です。これは厳密には新しい標準ではなく、企業がDNSSECに違反することなく、異なるDNSプロバイダーの独自拡張機能を利用できるようにするための運用プラクティスのセットです。その目的は、他社が追随できる実用的なソリューションを提供することです。

「マルチ署名 DNSSEC は、最適なパフォーマンスを保証する主要な独自機能を犠牲にすることなく冗長性とセキュリティの両方を可能にすることで、DNSSEC 導入の障壁を排除する上で重要な進歩を遂げています」と NS1 の主任ソフトウェア エンジニア Jan Včelák 氏は説明しています。

この戦略により、各DNSプロバイダーは提供するレコードに個別のゾーン署名鍵を使用できますが、すべてのプロバイダーが使用するDNSSEC鍵の全体セットについて合意する必要があります。これにより、複数のDNSプロバイダー間でレコードの真正性を検証できるようになります。

NS1とSalesforceは、オープンソースのDNSシステムBINDと連携し、実用的なシステムを開発しました。「当社のREST APIにより、NS1 DNSは署名に使用される公開鍵を取得できるだけでなく、最終的なDNSKEYレコードセットとその署名を公開することもできます」とVčelák氏は説明しました。

「同時に、NS1と一般的なオープンソースDNSサーバー（例えばBIND）をマルチ署名DNSSEC構成で実行できるようにするオープンソースコンポーネントを構築しています。」彼はこのアプローチについて詳しく説明した長いブログ記事を書いています。

転換点？

多くの企業が複数の DNS プラットフォームを使用しているのは事実ですが (多くの場合、1 つのプロバイダーに障害が発生した場合でもオンライン状態を維持できるようにバックアップとして使用しています)、複数の DNS プラットフォームのサポートが不足していることが、DNSSEC のより広範な導入にとってどれほど大きな問題であるかは明らかではありません。

NS1 の主任エンジニアである Shane Kerr 氏はThe Registerに対し、「複数の DNS ベンダーを導入し、それぞれの高度な DNS 機能を活用しながら、DNSSEC 認証済みの回答を提供したいと考えている企業がある」と語った。

その意味で、この新しいアプローチは「DNSSECを導入したいが、導入できるかどうか不安だった組織にとって、大きな障害を取り除く」と彼は主張する。また、このアプローチは「既にDNSSECを導入しているが、自社のビジネスに役立つDNSベンダーの非標準機能を利用したい」企業にも活用できる可能性があると指摘する。

Cloudflare のようにダイナミック DNS レコードをすでに作成している企業はいくつかあるが、カー氏は、このアプローチは「単一のベンダー独自のものではなく」、複数のプラットフォームで利用できる点で斬新だと述べている。

彼は、このアイデアが「プロトコル レベルの変更を伴わず、実際の問題を解決する」という点から好意的に受け止められていると主張し、このアイデアが IETF の精査を通過すると確信している。

彼はさらにこう付け加えた。「概念実証の実装はすでに完了しています。2つ目の実装が登場するまで待つことになるかもしれませんが、IETFではそれは必須ではありません。また、このドキュメントはDNSSECの専門家にとって明確で、基本的に自明であるため、抵抗は起こりそうにありません。」

NS1とSaleforceが、ロードバランシングやジオルーティングといった標準を推進するのではなく、なぜこのアプローチに注力しているのかと尋ねられたカー氏は、次のように述べている。「標準化には長い時間がかかり、標準化には常にイノベーションを制限するというトレードオフが伴います。高度なDNS機能のための標準的なアプローチを採用したとしても、複数のDNSプロバイダー間で署名責任を共有する必要性は常に存在します。」

長い道のり

DNSSECプロト​​コルは2005年に正式に公開されましたが、普及は遅々として進みませんでした。2008年にセキュリティ研究者のダン・カミンスキー氏がDNSの根本的な欠陥を発見し、DNSSECを最善の解決策として推奨したことで、DNSSECは飛躍的な発展を遂げました。

これを受けて、米国政府は2009年にインターネットのルートゾーンにDNSSECによるデジタル署名を求めるようになりましたが、導入は依然として進んでいませんでした。2011年に.comトップレベルドメインがようやくDNSSECを導入した時、誰もが転換点を迎えたと認めました。しかし、実際にはそうではありませんでした。

その後、ICANN は、すべての新しいトップレベル ドメインがインターネットに追加される前に、プロセスの一環として DNSSEC を実装することを要求しました。これにより、人々の信頼が高まり、DNSSEC 上で動作する DANE などの新しい安全なプロトコルの開発が開始されました。

しかし、プロトコルの複雑さと緊急性の欠如により、導入は依然として低迷しています。昨年末、Cloudflareは導入をワンクリックにまで短縮することに成功しました。そして今年1月、DNS自体への新たな攻撃が相次いだことを受け、米国国土安全保障省は緊急指令を発出し、すべてのユーザーにDNSSECプログラムを可能な限り早期に導入するよう求めました。翌月には、DNSを監督するICANNも同様の措置を取りました。

より大きな抑制

結局のところ、複数のDNSプラットフォームを利用できることが、最終的に人々がDNSSEC導入に踏み切るきっかけとなるかどうかは議論の余地があります。さらに、複数のDNS専門家が指摘しているように、より安全なDNSの普及を阻む最大の要因は、ゾーンの署名取得ではなく、署名されたレスポンスの検証なのです。

Salesforce と NS1 が推進する新しいアプローチは、「ゾーンに署名しない言い訳を排除する」ことになるが、検証がなければ何の進展もない。

「BIND、PowerDNS、Knotなどのソフトウェアツールを使えばゾーンへの署名と最新化が非常に簡単に行えるにもかかわらず、DNSSECは専門外のDNS運用者にとってオンプレミスで実装するには依然として複雑すぎます」と、レジストリCentralNicの最高イノベーション責任者であるギャビン・ブラウン氏は説明する。「DSレコード情報をレジストラ経由でレジストリに手動で送信する必要があり、これは煩雑でエラーが発生しやすいプロセスです。」

レコードの送信を自動化するプロトコルがあり、これは当時、DNSSEC への別の障壁を取り除くものとしても歓迎されましたが、これも採用率は非常に低いものでした。

別の DNS ベテランは、「まずすべての ISP (携帯電話プロバイダーなどを含む) に検証を有効にしてもらわない限り、ゾーンの署名は得られないだろうと分かりました。検証が有効になってしまえば、ゾーンの署名を支持するのは簡単です。」と述べています。

「米国でも他の国でも、ゾーンの署名に関する議論しか目にしたことがありません。署名付きゾーンを推進する人たちに、代わりに検証機能の有効化を推進するよう何度も説得しようとしましたが、失敗しました。」

したがって、DNSSEC を複数のプラットフォームで動作させるというこの新しいアプローチは、一部のプラットフォームでは機能し、実装に踏み切るきっかけになるかもしれませんが、安全な DNS が標準になるまでには、まだ長い道のりがあるようです。®