JP4876168B2 - 名前チャレンジ可能ゾーン - Google Patents

Description

ＤＮＳ(Domain Name System)は、１又は複数のネットワーク上の分散データベースにおけるドメイン名に関連付けられた情報を格納するシステムである。格納された情報は、ドメイン名に関連付けられたＩＰ(Internet Protocol)アドレスを含む。ドメイン名空間は、ドメイン名のツリーとして考えることもできる。ツリーにおける各ノード又は葉は、リソースのレコードと関連付けられていて、ドメイン名に関連付けられた情報を持つ。ツリーはゾーンに分けられる。ゾーンは権限のあるＤＮＳサーバにより権限的に供給される接続されたノードの集合である。ＤＮＳサーバは１又は複数のゾーンをホストする。

テキストベースのファイルを使用すること又はディレクトリシステムを使用することにより、ゾーンを格納できる。ゾーンは、マシン名、ＩＰアドレス又は他のドメイン情報における変更を取り扱うために、クライアントマシンからの動的なアップデートを許可するよう構成できる。動的アップデートはセキュアであるかもしれないが、セキュアでないかもしれない。セキュアなアップデートはクライアントマシン及びＤＮＳサーバ間のセキュリテイコンテキスト(security context)のネゴシエーション(negotiation)を必要とするかもしれない。セキュアなアップデートを使用することは、登録された名前のオリジナルのオーナーのみが存在するレコードへの変更を行えることを必要とする。同じ名前についての他のクライアントマシンによる登録(registration)の試みは拒否される。セキュアなアップデートはドメイン証明書をアップデートし、テキストベースのファイルを使用して格納されるゾーンに利用可能でない。

セキュアでないアップデートは、クライアントが新しい登録を作成又は存在する登録を修正することを可能にする。存在するデータについてのセキュアでないアップデートは、オリジナルのオーナーに制限されない。従って、別のマシンは、同じ名前についての動的アップデートを実行するかもしれない。これが故意になされた場合、これは名前ハイジャック攻撃(name hijacking attack)として知られている。セキュアでないアップデートはドメイン証明書を必要とせず、ゾーンにどんなストレージシステムが使用されるかに関わらず使用できる。しかし、セキュアでないアップデーを使用することにより、クライアントは名前ハイジャック攻撃に対して脆弱性を有し、ゾーン内の名前の一意性を保証できない。

以下は、読者に基本的な理解を提供するために開示の簡略化された概要を示す。この課題を解決するための手段は、開示の広範囲の概要ではなく、本発明の鍵／重要な要素を特定又は本発明の範囲を明確化しない。この唯一の目的は、後に示されるより詳細な説明への前置きとしての簡単な形式でここで開示されているいくつかの概念を表すことである。

ここで開示されたものは、名前チャレンジ可能ゾーンを実装するための方法及びシステムのための様々な技術及び技法である。説明された技術の一実装に従って、ＤＮＳサーバ名前についてのアップデートを受信する時、ＤＮＳサーバはホスト名が適用可能ゾーンに既に存在するかどうかを見てチェックする。名前についてのレコードが既にある場合、ＤＮＳサーバは、オリジナルの登録者及びアップデートを送信するクライアントデバイスの識別が、これらのソースＩＰアドレスと比較することにより同じであるかどうかを決定する。ソースＩＰアドレスが同じである場合、アップデートは許可される。ソースＩＰアドレスが異なる場合、ＤＮＳサーバはオリジナルの登録者にＤＮＳクエリを送信する。オリジナルの登録者がＤＮＳクエリに応答する場合、アップデートは拒否される。オリジナルの登録者がＤＮＳクエリに応答しない場合、アップデートは許可される。

添付の図面とあわせて考慮される以下の詳細な説明を参照することによってより良く理解されるのと同じように、付随する特徴の多くはより容易に理解される。

この説明は、添付の図面と照らして読まれる以下のより詳細な説明からより理解される。

名前チャレンジを実装するための例示的なシステムを示すブロック図である。 ＤＮＳゾーンを管理するための例示的なユーザインターフェースを示すスクリーンショットである。 ＤＮＳゾーンのプロパティを閲覧及び編集するための例示的なユーザインターフェースを示すスクリーンショットである。 名前チャレンジを実装するための例示的な処理を示すフロー図である。 本発明のある態様が実装される例示的なコンピューティング環境を示す図である。

添付の図面において同様の参照番号は同様の部分を指定するのに使用される。

添付の図面と併せて以下で提供される詳細な説明は、当面の例の説明として意図し、当面の例が構成又は利用できる形式のみを表すことを意図しない。この説明は、例の機能並びに例を構成及び操作するためのステップのシーケンスを説明する。しかし同じ又は同等の機能及びシーケンスは、異なる例により達成されるかもしれない。

図１はＤＮＳサーバ１０２上の１又は複数のゾーンについての名前チャレンジを実装するための例示的なシステム１００を示すブロック図である。ＤＮＳサーバ１０２は、１０４、１０６又は１０８などの１又は複数のクライアントデバイスに通信的に結合されている。ＤＮＳサーバ１０２は１１０、１１２又は１１４などの１又は複数のゾーンをホストする。各ゾーンは、ドメイン内のクライアントデバイスへのＩＰアドレスのマッピングなどのドメイン情報を格納する１又は複数のレコードを含む。１又は複数のゾーンは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）システムなどのディレクトリシステムにファイルバック（file-back）又は統合される。１又は複数のゾーンは、クライアントデバイス名、ＩＰアドレス又は他のドメイン情報における１又は複数の変更を扱うために、クライアントデバイスからの動的アップデートを許可するよう構成できる。動的アップデートはセキュアであるかもしれないが、セキュアでないかもしれない。セキュアなアップデートはクライアントマシン及びＤＮＳサーバ間のセキュリテイコンテキストのネゴシエーションを必要とするかもしれない。セキュアなアップデートは、ドメイン名を登録したオリジナルのクライアントデバイスのみがそのドメイン名と関連付けられたレコードに変更を行えることを必要とするかもしれない。同じ名前について試みる他のクライアントマシンからの登録(registration)は拒否されるだろう。

セキュアでないアップデートは、クライアントが新しい再登録を生成又は存在する登録を修正することを可能とする。存在するデータについてのセキュアでないアップデートはオリジナルのオーナーに制限されない。図１に示されるようにシステム１００は、セキュアでない動的アップデートを可能にし、存在する登録に衝突（コンフリクト、conflict）するアップデートに対する名前チャレンジを実装する。１０４、１０６又は１０８などの各クライアントデバイスは、ＤＮＳサーバ１０２に１２０、１２２又は１２４などのアップデートを送信することができる。ＤＮＳサーバ１０２がアップデートを受信するとき、ＤＮＳサーバは、ホスト名が適用可能ゾーンに既に存在するかどうかをチェックして見る。ホスト名についてのレコードが既にある場合、ＤＮＳサーバ１０２は、オリジナルの登録者及びアップデートを送信するクライアントデバイスの識別が、これらのソースＩＰアドレスと比較することにより同じであるかどうかを決定する。ソースＩＰアドレスが同じである場合、アップデートは許可される。ソースＩＰアドレスが異なる場合、ＤＮＳサーバはオリジナルの登録者にＤＮＳクエリを送信することができる。オリジナルの登録者がＤＮＳクエリに応答する場合、アップデートは拒否される。オリジナルの登録者がＤＮＳクエリに応答しない場合、アップデートは許可される。ＤＮＳサーバ１０２は、要求されたアップデートの許可又は拒否をクライアントデバイスに通知するために、アップデートを要求したクライアントデバイスに、１３０、１３２又は１３４などの応答を送り返す。

例えば、ゾーン１１０はドメイン「corp.contoso.com」についてのレコードを格納する。ゾーン１１０は、クライアントデバイス１０４から受け取った登録により生成された「comp.corp.contoso.com」についてのアドレス（Ａ）レコードを有する。クライアントデバイス１０４は「corp.contoso.com」ドメインに結合されたホスト名「lab-comp」を有する。

第１のシナリオにおいて、クライアントデバイス１０４がそのレコードＡをリフレッシュ(refresh)するために「lab-comp.corp.contoso.com」についての動的アップデートを送信すると仮定する。権限のあるＤＮＳサーバ１０２が見つかるとき、「corp.contoso.com」ゾーンにおける「lab-comp」についてのレコードＡに対する任意の存在するデータをチェックする。「lab-comp」についてのレコードＡが存在する。従って、ＤＭＳサーバは、オリジナルの登録者のソースアドレス及びアップデートを送信するクライアントデバイスのソースアドレスが同じであるかどうかを見てチェックする。ソースアドレスは同じである。従ってＤＮＳサーバ１０２はアップデートを許可する。アップデートは処理され、アップデートの成功はクライアントデバイス１０４へ返される。

第２のシナリオにおいて、クライアントデバイス１０５は、そのＩＰアドレスの登録の試みにおいて、「lab-comp.corp.contoso.com」についての動的アップデートを送信すると仮定する。権限のあるＤＮＳサーバ１０２が見つかるとき、「corp.contoso.com」ゾーンにおける「lab-comp」についての任意の存在するレコードＡをチェックする。「lab-comp」についてのレコードＡが既に存在する。従って、ＤＭＳサーバは、オリジナルの登録者のソースアドレス及びアップデートを送信するクライアントデバイスのソースアドレスが同じであるかどうかを見てチェックする。オリジナルの登録者はクライアントデバイス１０４であり、クライアントデバイス１０５はアップデートを送信しているので、それらのソースＩＰアドレスは同じでない。ＤＮＳサーバ１０２はアップデートを拒否するかもしれない。ＤＮＳサーバ１０２はクライアントデバイス１０４にＤＮＳクエリを送信することができる。ＤＮＳクエリに応答してクライアントデバイス１０４から確認応答(acknowledgement)を受信する場合、ＤＮＳサーバ１０２はアップデートを拒否する。クライアントデバイス１０４からＤＮＳクエリへの応答が受信されない場合、ＤＮＳサーバ１０２はアップデートを許可する。

図２−３はＤＮＳゾーンを管理するための例示的なユーザインターフェースを示すスクリーンショット２００及びスクリーンショット３００を示す。図２に示されるシステムにおいて、_msdcs.dnsregression.com２０２、bar.com２０４、dnsregression.com２０６及びセキュアでないゾーン２０８を含む複数のＤＮＳゾーンが存在する。ユーザは管理されたＤＮＳゾーンを選択でき、選択されたゾーンの１又は複数のプロパティを編集できる。図３に示されるように、ユーザはビューを選択及び／又はセキュアでないゾーン２０８のプロパティを編集している。各ゾーンについて、ユーザはゾーンについての動的アップデートが可能にするかどうかを選択できる。ユーザが動的アップデートを可能にすることを選択する場合、ユーザはセキュアなアップデートのみを可能にすることを選択でき、又はユーザはセキュア及びセキュアでないアップデートの両方を可能にすることを選択できる。図３に示される例において、ユーザは３０２に示されるように、セキュア及びセキュアでないアップデートの両方を可能にすることを選択した。セキュアでないアップデートが可能となるとき、ユーザは３０４に示されるように、ユーザはセキュアでないアップデートについての名前チャレンジを可能にすることを選択できる。名前チャレンジが可能にされると、図４の例示的な処理によってより詳細が説明されるように、ＤＮＳサーバは存在する名前についての任意のアップデートをチャレンジする。

図４は、名前チャレンジ可能ゾーンについての例示的な処理を示すフロー図である。図４の説明が他の図を参照してなされる一方で、図４に示される例示的な処理は、任意の特定の図のシステム又は他のコンテンツに関連付けられているとして限定されることを意図しないことを理解されたい。さらに、図４の例示的な処理が操作の実行の特定の順序を示す一方で、１又は複数の代替の実施形態において、操作は異なる順序となってもよいことを理解されたい。さらに、図４の例示的な処理に示されるステップ及びデータのいくつかは必須ではなく、いくつかの実装において省くこともできる。最後に、図４の例示的な処理が複数の分離したステップを含む一方で、いくつかの環境においてはこれらの操作のいくつかは結合及び同時に実行できることを認識されたい。

４０２において、ＤＮＳサーバにおいて、第１のクライアントデバイスから名前についてのアップデートを受信する。アップデートはホスト名を含む。４０４において、ＤＮＳサーバがアップデートについての権限のあるゾーンをホストするかどうかに関しての決定がなされる。ホストする場合、処理は４０８に進む。ホストしない場合４０６においてアップデートは拒否される。アップデートについての権限のあるゾーンをホストするＤＮＳサーバが見つかる場合、４０８において、ホスト名についてのレコードが既にあるかどうかを決定するためにゾーンをチェックする。ホスト名についてのレコードが既にあるかどうかを決定するステップにおいて、１又は複数のタイプの１又は複数のレコードをチェックできる。チェックされるかもしれない例示的なレコードのタイプは、アドレス（Ａ）レコード、ＩＰｖ６アドレスレコード及びＣＮＡＭＥ（Canonical Name）レコードを含むがこれらに限定されない。

ホスト名についてのレコードが見つからない場合、４３０において、アップデートは許可される。ホスト名についてのレコードが既にある場合、４１２において、ホストレコードに関連付けられたソースＩＰアドレスが決定される。４１４において、ホストレコードに関連付けられたソースＩＰアドレスが、第１のクライアントデバイスのソースＩＰアドレスと比較される。ＩＰアドレスが一致する場合、４２０において、アップデートは許可される。ＩＰアドレスが一致しない場合、４１６において、ＤＮＳクエリがホストレコードに関連付けられたＩＰアドレスを有する第２のクライアントデバイスに送信され、４１８において、第２のクライアントデバイスからの応答があるかどうかに関しての決定が成される。ＤＮＳクエリに応答して第２のクライアントデバイスから確認応答を受信する場合、４２２において、アップデートは拒否される。第２のクライアントデバイスからＤＮＳクエリへの応答を受信しない場合、４２２において、アップデートは許可される。アップデートが許可され、１又は複数の他のＤＮＳサーバがゾーンのコピーを有する場合、アップデートは１又は複数の他のＤＮＳサーバに反復できる。

図５は本発明のある態様において実装される例示的なコンピューティング環境を示す。コンピューティング環境５００が、ここで説明された様々な技術を採用できる唯一の適切なコンピューティング環境ではなく、ここに説明される技術の使用又は機能の範囲に関して任意の限定を提案する意図はないことを理解されたい。また、コンピュータ環境５００はここに示される全てのコンポーネントを必須的に必要とするものとして解釈されるべきではない。

ここに説明される技術は、他の多くの一般目的又は特定目的のコンピューティング環境又は構成で動作可能である。ここで説明される技術での使用に適している構成の良く知られているコンピューティング環境及び／又は例は、上述のシステム又はデバイスなどの任意を含むパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス若しくはラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、分散コンピューティング環境を含むがこれらに限定されない。

図５を参照して、コンピューティング環境５００は、一般目的のコンピューティングデバイス５１０を含む。コンピューティングデバイス５１０のコンポーネントは、処理ユニット５１２、メモリ５１４、ストレージデバイス５１６、入力デバイス５１８、出力デバイス５２０及び通信接続５２２を含むことができるがこれらに限定されない。

処理ユニット５１２は、１又は複数の一般又は特定目的のプロセッサ、ＡＳＩＣ又はプログラマブル論理チップを含むことができる。コンピューティングデバイスの構成及び種類によって、メモリ５１４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）又はこの２つのいくつかの組み合わせであることができる。コンピューティングデバイス５１０は、磁気又は光ディスク又はテープを含むがこれらに限定されない追加のストレージ（リムーバブル及び／又はリムーバブルでない）を含むこともできる。このような追加のストレージはストレージ５１６により図５に示される。コンピュータストレージメディアは、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータなどの情報の格納のための任意の方法又は技術において実装される、揮発性及び不揮発性、リムーバブル及びリムーバブルでないメディアを含む。メモリ５１４及びストレージ５１６はコンピュータストレージメディアの例である。コンピュータストレージメディアは、所望の情報を格納するために使用でき、コンピューティングデバイス５１０によりアクセスできる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ(digital versatile disk)又は他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ若しくは他の磁気ストレージデバイス、又は任意の他のメディアを含むがこれらに限定されない。任意のこのようなコンピュータストレージメディアはコンピューティングデバイス５１０の一部であることができる。

コンピューティングデバイス５１０は、コンピューティングデバイス５１０がネットワーク５３０を介する他のコンピューティングデバイスなどの他のデバイスと通信することを可能にする通信接続５２２を含むこともできる。通信接続５２２は通信メディアの例である。通信メディアは一般に、搬送波又は他の転送メカニズムなどの変調されたデータ信号において、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータを組み込み、任意の情報伝達メディアを含む。「変調されたデータ信号」という用語は、１又は複数のその特性セットを有する信号、又は信号において情報をエンコードするためのこのような方式で変更された信号を意味する。限定ではなく例として、通信メディアは、有線ネットワーク又は直接有線接続などの有線メディア、及びアコースティック、無線周波、赤外線及び他の無線メディアなどの無線メディアを含む。コンピュータ可読媒体という用語は、ここで使用されるように、ストレージメディアを含む。

コンピューティングデバイス５１０は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス及び／又は他の任意の入力デバイスなどの入力デバイス５１８も含むことができる。１又は複数のディスプレイ、スピーカー、プリンター及び／又は任意の他の出力デバイスなどの出力デバイス５２０もまた含まれる。

本発明は、多くの例示的な実装の観点で説明されてきたが、本発明は説明された実装に限定されず、添付の特許請求の範囲の精神及び範囲内の修正及び代替物で実行できることを当業者は理解されたい。この説明はしたがって、限定の代わりに例示としてみなされることとなる。

Claims (19)

1. 第１のクライアントデバイスからＤＮＳ(Domain Name System)サーバでアップデートを受信するステップであって、前記アップデートはホストネームを含む、受信するステップと、
   前記ＤＮＳサーバが前記アップデートについて権限のあるゾーンをホストするかどうかを決定するステップと、
   前記ホスト名についてのレコードが既にあるかどうかを決定するステップと、前記レコードが既にある場合、
   前記ホスト名に関連付けられたＩＰ(Internet Protocol)アドレスを決定するステップと、
   前記ホスト名に関連付けられた前記ＩＰアドレスが前記第１のクライアントデバイスのソースＩＰアドレスと一致するかどうかを決定するステップと、
   前記ＩＰアドレスが一致する場合に、前記アップデートを許可するステップと、
   前記ホスト名に関連付けられた前記ＩＰアドレスが前記第１のクライアントデバイスの前記ソースＩＰアドレスに一致しない場合、前記ホスト名に関連付けられた前記ＩＰアドレスを有する第２のクライアントデバイスにＤＮＳクエリを送信するステップと
   を備えたことを特徴とする方法。
2. 前記ホスト名についてのレコードが無い場合、前記アップデートを許可するステップをさらに備えたことを特徴とする請求項１記載の方法。
3. 前記ＤＮＳクエリに応答して前記第２のクライアントデバイスから確認応答(acknowledgement)を受信する場合、前記アップデートを拒否するステップをさらに備えたことを特徴とする請求項１に記載の方法。
4. 前記ＤＮＳクエリに応答して前記第２のクライアントデバイスから確認応答を受信しない場合、前記アップデートを許可するステップをさらに備えたことを特徴とする請求項１に記載の方法。
5. 別のＤＮＳサーバに前記アップデートを反復するステップをさらに備えたことを特徴とする請求項１に記載の方法。
6. 前記ホスト名についてのレコードが既にあるかどうかを決定するステップは、複数のタイプの複数のレコードをチェックするステップをさらに備えたことを特徴とする請求項１に記載の方法。
7. 前記レコードのタイプの１つはアドレス（Ａ）レコードであることを特徴とする請求項６に記載の方法。
8. 前記レコードのタイプの１つはＩＰｖ６アドレスレコードであることを特徴とする請求項６に記載の方法。
9. 前記レコードのタイプの１つはＣＮＡＭＥ(Canonical Name)レコードであることを特徴とする請求項６に記載の方法。
10. 前記ゾーンはファイルに格納されることを特徴とする請求項１に記載の方法。
11. 前記ゾーンはディレクトリシステムで統合されることを特徴とする請求項１に記載の方法。
12. アップデートのための権限のあるゾーンをホストするＤＮＳ(Domain Name System)サーバで第１のクライアントデバイスからアップデートを受信するステップであって、前記アップデートはホスト名を含む、受信するステップと、
    前記ホスト名についてのレコードが既にあるかどうかを決定するために、前記ゾーン内の１又は複数のレコードをチェックするステップと、前記レコードが既にある場合に、
    前記ホスト名に関連付けられたＩＰ(Internet Protocol)アドレスを決定するために、前記ホスト名についての前記レコードをチェックするステップと、
    前記ホスト名に関連付けられた前記ＩＰアドレスが前記第１のクライアントデバイスのソースＩＰアドレスと一致するかどうかを決定するステップと、前記ＩＰアドレスが一致しない場合に、
    前記ホスト名に関連付けられた前記ＩＰアドレスを有する第２のクライアントデバイスにＤＮＳクエリを送信するステップと
    前記第２のクライアントデバイスが前記ＤＮＳクエリに応答するかどうかに基づいて、アップデートを許可するかどうかを決定するステップと
    を実行するためのデバイス実行可能命令を有する１又は複数のデバイス可読メディア。
13. 前記ホスト名についてのレコードがない場合に、前記アップデートを許可するステップをさらに備えることを特徴とする請求項１２に記載の１又は複数のデバイス可読メディア。
14. 前記ホスト名に関連付けられた前記ＩＰアドレスが前記第１のクライアントデバイスの前記ソースＩＰアドレスと一致する場合に、前記アップデートを許可するステップをさらに備えることを特徴とする請求項１２に記載の１又は複数のデバイス可読メディア。
15. 前記第２のクライアントデバイスが前記ＤＮＳクエリに応答するかどうかに基づいて前記アップデートを許可するかどうかを決定するステップは、前記第２のクライアントデバイスが前記ＤＮＳクエリに応答する場合に前記アップデートを拒否するステップと、前記第２のクライアントデバイスが前記ＤＮＳクエリに応答しない場合に前記アップデートを許可するステップとをさらに備えることを特徴とする請求項１２に記載の１又は複数のデバイス可読メディア。
16. ＤＮＳ(Domain Name System)サーバで第１のクライアントデバイスからアップデートを受信するステップであって、前記アップデートはホスト名を含む、受信するステップと、
    前記ホスト名についてのレコードが既にあるかどうかを決定するステップと、前記レコードが既にある場合に、
    前記ホスト名の登録者のソースＩＰアドレスを決定するステップと、
    前記ホスト名の前記登録者の前記ソースＩＰアドレスが前記第１のクライアントデバイスのソースＩＰアドレスと一致するかどうかを決定するステップと、一致しない場合に、
    前記ホスト名の前記登録者にＤＮＳクエリを送信するステップと、
    前記ＤＮＳクエリに応答して前記登録者から確認応答を受信する場合に前記アップデートを拒否するステップと
    を備えたことを特徴とする方法。
17. 前記ホスト名についてのレコードがない場合に前記アップデートを許可するステップをさらに備えたことを特徴とする請求項１６に記載の方法。
18. 前記ホスト名の前記登録者の前記ソースＩＰアドレスが前記第１のクライアントデバイスのソースＩＰアドレスと一致する場合に、前記アップデートを許可するステップをさらに備えたことを特徴とする請求項１６に記載の方法。
19. 前記ＤＮＳクエリに応答して前記登録者から応答を受信しない場合に前記アップデートを許可するステップをさらに備えたことを特徴とする請求項１６に記載の方法。

Images