OCI Public DNSに対するDNSSECのサポートを発表

※ 本記事は、Tim Sammutによる”Announcing OCI Public DNS support for DNSSEC“を翻訳したものです。

Oracle Cloud Infrastructure (OCI) Public DNSサービスに対するドメイン・ネーム・システム・セキュリティ拡張(DNSSEC)のサポートを発表できることを嬉しく思います。OCI Public DNSサービスとDNSSECは、世界中のすべてのOCI商用リージョンで使用できます。DNSSECは、パブリック・インターネット上でDNSレスポンスを検証するために暗号的に設計されています。OCI上のDNSSECはオプションであり、DNS応答のインライン署名を利用して使いやすさと複雑さを軽減し、無償で提供されます。

DNSSECの利点

DNSSECは、公開キー暗号化を使用して、パブリック・インターネット上のDNSレスポンスの信頼性と整合性を検証する業界標準です。また、DNSSECを使用すると、組織はDNSレコードの非存在を暗号化してアサートできます。DNSSEC対応のトップ・レベル・ドメインにパブリックDNSドメインがあるすべての組織(comなど)は、DNSSECを使用できます。有効にすると、DNSSECはドメインの所有者が説明したとおりに、認証DNSレスポンスを容易にし、ネットワークを転送するときに変更されていないことを表します。これは、キャッシュ・ポイズニングやDNSレスポンスの改ざんなど、DNSに対する一般的な攻撃の影響を排除するように設計されています。

DNSキャッシュ・ポイズニング攻撃では、次の図に示すように、攻撃者は DNSサーバーのキャッシュに悪意のあるエントリを配置します。これらの悪意のあるDNSエントリは、Webサイトまたはアプリケーション・トラフィックを攻撃者が制御する宛先にリダイレクトします。この攻撃を成功させるため、攻撃者は、ターゲットとなるサーバーがクエリーを満たすために再帰を実行する必要があることを想定して、ターゲットとなる DNSサーバーに DNSクエリーを送信します(手順1)。再帰では、ターゲット・サーバーが独自の DNSクエリーを他の DNSサーバーに送信する必要があります(手順2)。攻撃中、攻撃者はターゲット・サーバーのDNS問合せへの悪意のあるレスポンスを提供するDNSレスポンスでターゲット・サーバーをフラッディングします(ステップ3)。これらの不正応答の1つが DNSサーバーのクエリーに必要なパラメータと一致し、実際の応答の前に到着した場合、攻撃者は成功し、ターゲット・サーバーが不正なデータをキャッシュに配置します(手順4)。不正な DNS応答がキャッシュされている間、ターゲット・サーバーは、ほかの DNSクライアントからの DNS照会に応答して、攻撃者が提供したデータを提供します。

DNSSECは、ターゲット指定されたサーバーが、有効なDNSSEC RRSIGレコードがないため、攻撃者からの悪意のあるDNSレスポンスを受け入れることを拒否するため、この攻撃を軽減します。このレコードは、悪意のあるデータが他のユーザーに影響を与える可能性のあるキャッシュに入るのを防ぎます。

OCIでのDNSSECの概要

DNSSEC署名付きDNSレスポンスを検証するには、DNSSECによって提示される信頼をゾーンに分離できず、かわりに相互に信頼できる場所から拡張する必要があります。DNSSECの場合、トラスト・アンカーと呼ばれる相互に信頼できる場所はDNSルートです。DNSSECを有効にするゾーンの上にあるすべてのゾーンは、それ自体がDNSSEC対応である必要があるため、DNSSECでDNSレスポンスに署名する機能が含まれている必要があります。

たとえば、ゾーン tim-at-oracle.comでDNSSECを有効にするには、「com」ゾーンとルートゾーン(.)がすべてDNSSECをサポートしている必要があります。DNSSECのサポートは、多くのDNSドメイン・レジストラの多くのトップレベル・ドメインに存在します。ただし、ドメインに対するサポートが存在するかどうかが不明な場合は、DNSドメイン・レジストラに問い合わせてサポートを確認してください。

ゾーンのDNSSECに関連する公開キー暗号化では、公開キーと秘密キーの1つまたは2つのペアが使用されます。DNSSECでは単一のキー・ペアを使用できますが、OCIでは常にキー署名キー(KSK)およびゾーン署名キー(ZSK)と呼ばれる2つのキー・ペアが使用されます。KSKは暗号学的にゾーンのZSKに署名し、ZSKはゾーン内の個々のリソース・レコード・セット(RRSET)に署名します。OCIのDNSSECにより、OCIはKSKを作成しますが、お客様がKSKを管理し、ZSKは完全にOCIによって作成および管理されます。新しいDNSレコード・タイプであるDSレコードを使用して、親ゾーンを子ゾーンにリンクします。

DNSSECキーとその用途を視覚化すると役立ちます。次の図は、DNSルート・ゾーンからサンプル・ゾーン(tim-at-oracle.com)までのKSK、ZSKおよびDSレコードを示しています。

DNSSECは、DNS自体で必要な暗号化キー、キー・ダイジェストおよび署名を新しいDNSレコード・タイプの形式で配布することで、その目標を提供します。DNSSECをサポートするために、次の新しいDNSレコード・タイプが追加されました:

• DS: これらのレコードは、DNSドメイン・レジストラまたは他の親ゾーンに追加され、KSKの暗号化ダイジェストが含まれます。ドメインの親ゾーンに追加されたネームサーバー(NS)レコードが DNSをまとめて“glue”するのと同様に、DSレコードは、DNSのルートにあるトラスト・アンカーからゾーンに信頼チェーンを接続するのに役立ちます。
• DNSKEY: これらのレコードには、ゾーン内のKSKおよびZSKからの公開キーが格納されます。これらのレコードのKSK公開鍵は暗号学的に自己署名され、ZSK公開鍵はKSKによって署名されます。
• RRSIG: これらのレコードには、特定のRRSETの署名が含まれます。RRSETは、レコードや名前など、同じタイプのDNSレコードのセットです(www.tim-at-oracle.com.など)。
• NSECおよびNSEC3: これらのレコードは、DNSレコードの非存在をアサートします。これらのレコードはRRSIGとともに送信されるため、その非存在は暗号的に保証されます。

DNSSECは、主に2つの方法でインターネット上のクライアントにメリットをもたらします。まず、各コンピュータ上のDNSスタブ・リゾルバ(基本的にDNSクライアント)は、重いリフト自体を実行できます。DSおよびDNSKEYレコードから公開キーを収集し、多数のDNSレスポンスで関連する署名を検証するために必要なDNS問合せを送信します。署名が有効な場合は、受信したDNS情報(www.tim-at-oracle.com.からのIPアドレスなど)が使用されます。受信した情報がDNSSECで正しく検証されない場合、情報は拒否され、使用されません。このオプションは、最終的に最も選択肢が多いですが、スタブ・リゾルバを検証するDNSSECを選択、インストールおよび構成する必要があるため、最も複雑なオプションでもあります。

または、DNSスタブ・リゾルバは、DNSサーバーを使用してDNSSECの作業を実行できます。この場合、クライアントは、インターネット・サービス・プロバイダ(ISP)または事業主でDNSSEC検証をDNSサーバーに延期します。このモデルでは、スタブ・リゾルバ・クライアントの助けを借りて、使用可能なDNSSEC情報を検証することによって再帰DNSサーバーが検証されます。受信した DNS応答が変更されたか、またはDNSSECに対して無効であった場合、再帰サーバーはクライアントにサーバー障害(SERVFAIL)エラーを返します。米国の多くの家庭用インターネット・ユーザーは、このシステムを透過的に使用しています。ほとんどの場合、DNSSECのセキュリティ上のメリットを得るために、このアプローチを検討します。

まとめ

DNSSECは、パブリック・インターネット上のDNSデータの整合性を認証するように設計されています。この機能はすべてのDNSゾーンにとって重要ですが、金融アプリケーション、医療システム、政府システムなど、攻撃者にとって望ましい標的となるシステムにとっては極めて重要です。政府機関のDNSゾーンなど、規制コンプライアンスのためにDNSSECが必要になる場合があります。OCI Public DNSのためのDNSSECのリリースにより、OCIでホストされているパブリック・ゾーンのDNSに対するキャッシュ中毒および中間者攻撃の脅威を軽減できるようになりました。

Oracle Cloud InfrastructureでのDNSSECの有効化の詳細は、ドキュメントを参照してください。