知財求人 - 知財ポータルサイト「IP Force」
特表2024-502773トラフィックリダイレクト方法、対応する端末、コントローラ、認可サーバ、名前解決サーバ、およびコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-01-23
(54)【発明の名称】トラフィックリダイレクト方法、対応する端末、コントローラ、認可サーバ、名前解決サーバ、およびコンピュータプログラム
(51)【国際特許分類】
H04L 61/4511 20220101AFI20240116BHJP
H04L 12/22 20060101ALI20240116BHJP
G06F 21/55 20130101ALI20240116BHJP
【ＦＩ】
H04L61/4511
H04L12/22
G06F21/55
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023538805
(86)(22)【出願日】2021-12-21
(85)【翻訳文提出日】2023-08-22
(86)【国際出願番号】 FR2021052420
(87)【国際公開番号】W WO2022136796
(87)【国際公開日】2022-06-30
(31)【優先権主張番号】2014109
(32)【優先日】2020-12-23
(33)【優先権主張国・地域又は機関】FR
(81)【指定国・地域】
(71)【出願人】
【識別番号】591034154
【氏名又は名称】オランジュ
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】モハメッド・ブカダール
(72)【発明者】
【氏名】クリスティアン・ジャキネ
【テーマコード（参考）】
5K030
【Ｆターム（参考）】
5K030GA15
5K030HD09
(57)【要約】
トラフィックリダイレクト、対応する端末、コントローラ、認可サーバ、名前解決サーバ、コンピュータプログラムのための方法。本発明は、通信ネットワークに接続された端末(51)に実装された名前解決方法に関し、本方法は、前記端末(51)と第1の名前解決サーバとの間の安全な通信チャネルを介して前記第1の名前解決サーバに名前解決メッセージを送信するステップ(511)と、端末のDNSトラフィックのリダイレクトが認可されている場合、前記リダイレクトの第2の名前解決サーバの少なくとも1つの識別子を取得するステップ(512)と、第2の名前解決サーバへの端末のDNSトラフィックの前記リダイレクトを管理するための、少なくとも、前記第2の名前解決サーバの正当性を検証するステップ、端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップ、DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、のうち、少なくとも1つのアクションを実行するステップ(513)と、を含む。
【特許請求の範囲】
【請求項1】
通信ネットワークに接続された端末(51)に実装された名前解決方法であって、前記端末(51)と第1の名前解決サーバ(52)との間の安全な通信チャネルを介して前記第1の名前解決サーバ(52)に名前解決メッセージを送信するステップ(511)と、
前記端末のDNSトラフィックのリダイレクトが認可されている場合、前記リダイレクトの第2の名前解決サーバ(55)の少なくとも1つの識別子を取得するステップ(512)と、
前記第2の名前解決サーバ(55)への前記端末の前記DNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップ、
前記DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行するステップ(513)と、
を含むことを特徴とする、名前解決方法。
【請求項2】
前記端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップは、前記第2の名前解決サーバから新しい識別子の取得をさらに生成することを特徴とする、請求項1に記載の名前解決方法。
【請求項3】
前記第2の名前解決サーバの前記正当性を検証するステップは、前記第2の名前解決サーバの前記正当性を検証するための少なくとも1つの情報を受信するステップと、
前記端末によって発信され、前記少なくとも1つの検証情報から生成された名前解決要求に対する応答と、前記少なくとも1つの検証情報から得られたテスト応答とを比較することにより、前記応答を発信するエンティティの前記正当性を検証するステップと、
を含むことを特徴とする、請求項1または2に記載の名前解決方法。
【請求項4】
通信ネットワーク内で端末(51)に対して認可されたDNSトラフィックリダイレクトの制御方法であって、前記端末は、前記端末(51)と第1の名前解決サーバ(52)との間の安全な通信チャネルを介して名前解決メッセージを発信し、前記制御方法は、前記ネットワークのコントローラ(54)に実装されており、かつ前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために端末用に識別された第2の名前解決サーバ(55)との間で、前記端末によって前記第2の名前解決サーバの正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換するステップ(541)、
を含むことを特徴とする、制御方法。
【請求項5】
前記端末と前記第2の名前解決サーバとの接続の失敗の解決のために前記第2の名前解決サーバによって提供される前記少なくとも1つの情報は、前記第2の名前解決サーバの少なくとも1つの新しい識別子を含み、前記方法は、前記少なくとも1つの新しい識別子をネットワーク認可サーバに送信するステップをさらに含むことを特徴とする、請求項4に記載の制御方法。
【請求項6】
前記通信ネットワーク用に規定されたデフォルトのルータから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、前記少なくとも1つの新しい識別子を、前記ネットワークの認可サーバに送信するステップと、を含むことを特徴とする、請求項4に記載の制御方法。
【請求項7】
前記情報交換中に、前記第2の名前解決サーバに、前記第2の名前解決サーバの前記正当性、または前記端末が属するネットワークの少なくとも1つの識別子を検証することを認可された前記端末の少なくとも1つの識別子を送信するステップを含むことを特徴とする、請求項4から6のいずれか一項に記載の制御方法。
【請求項8】
通信ネットワークで端末(51)に対して認可されたDNSトラフィックリダイレクトの管理方法であって、前記端末は、前記端末(51)と第1の名前解決サーバ(52)との間の安全な通信チャネルを介して名前解決メッセージを発信し、前記管理方法は、リダイレクトの前記端末に対して識別されたネットワークの第2の名前解決サーバ(55)に実装されており、かつコントローラから前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換するステップ(551)、
を含むことを特徴とする、管理方法。
【請求項9】
前記端末に名前解決要求に対する応答を送信するステップであって、前記応答は、前記端末の少なくとも1つの識別子から得られたテスト応答を含み、前記第2の名前解決サーバの前記正当性を検証するための前記少なくとも1つの情報は、前記コントローラとの交換中に取得される、ステップ、を含むことを特徴とする、請求項8に記載の管理方法。
【請求項10】
前記第2の名前解決サーバの少なくとも1つの新しい識別子を生成するステップと、前記コントローラとの交換中に、ネットワークコントローラに、前記少なくとも1つの新しい識別子を送信するステップと、
を含むことを特徴とする、請求項8または9に記載の管理方法。
【請求項11】
通信ネットワーク内で端末(51)用に認可されたDNSトラフィックリダイレクトの処理方法であって、前記方法は、ネットワークの第1の名前解決サーバ(52)に実装されており、前記端末(51)と前記第1の名前解決サーバ(52)との間の安全な通信チャネルを介して前記端末から名前解決メッセージを受け取るステップ(521)と、
認可サーバ(53)から、前記端末のリダイレクト認可と、リダイレクトのために前記端末用に識別された第2の名前解決サーバ(55)の少なくとも1つの識別子とを取得するステップ(522)と、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信するステップ(523)と、
を含むことを特徴とする、処理方法。
【請求項12】
前記第2の名前解決サーバの正当性を検証するための前記端末からの通知に従って、前記第2の名前解決サーバの前記正当性を検証するための少なくとも1つの情報を取得するステップと、
前記端末に前記少なくとも1つの検証情報を送信するステップと、
を含むことを特徴とする、請求項11に記載の処理方法。
【請求項13】
前記第2の名前解決サーバとの接続の失敗の前記端末からの通知に従って、前記認可サーバから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、
前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を前記端末に送信するステップと、
を含むことを特徴とする、請求項11または12に記載の処理方法。
【請求項14】
前記端末と前記第2の名前解決サーバとの接続が少なくとも1回失敗した後、前記第2の名前解決サーバへの前記DNSトラフィックリダイレクトを無効化するステップ、または前記端末の要求に応じて、前記端末に対してデフォルトで指定された第3の名前解決サーバへのDNSトラフィックリダイレクトを無効化するステップ、
を含むことを特徴とする、請求項11から13のいずれか一項に記載の処理方法。
【請求項15】
通信ネットワーク内の端末(51)のDNSトラフィックのリダイレクトの認可方法であって、前記方法は、前記ネットワークの認可サーバ(53)に実装されており、前記端末は、前記端末(51)と第1の名前解決サーバ(52)との間の安全な通信チャネルを介して名前解決メッセージを発信し、前記方法は、前記端末のDNSトラフィックのリダイレクトが認可されている場合:前記リダイレクトのために前記端末に対して識別される第2の名前解決サーバ(55)の少なくとも1つの識別子を取得するステップ(531)と、
前記第1の名前解決サーバに、前記端末および前記第2の名前解決サーバの少なくとも1つの識別子に対するリダイレクト認可を送信するステップ(532)と、
を含むことを特徴とする、認可方法。
【請求項16】
前記ネットワークのコントローラに、前記端末の少なくとも1つの識別子、
前記端末が属するネットワークの少なくとも1つの識別子、
前記第2の名前解決サーバの前記少なくとも1つの識別子、
前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、
のグループに属する少なくとも1つの要素を送信するステップ、
を含むことを特徴とする、請求項15に記載の認可方法。
【請求項17】
前記ネットワークコントローラから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、前記第1の名前解決サーバに、前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を送信するステップと、
を含むことを特徴とする、請求項15または16に記載の認可方法。
【請求項18】
通信ネットワーク内のDNSトラフィックのリダイレクト用に構成された端末であって、前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して第1の名前解決サーバに名前解決メッセージを送信し、
前記リダイレクト用の第2の名前解決サーバの少なくとも1つの識別子を取得し、
前記端末から前記第2の名前解決サーバへのDNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップ、
DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行する、
ように構成されていることを特徴とする、端末。
【請求項19】
通信ネットワークの端末に対して認可されたDNSトラフィックのリダイレクトを制御するためのネットワークコントローラであって、前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために前記端末用に識別された第2の名前解決サーバとの間で、前記端末によって前記第2の名前解決サーバの正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換する、
ように構成されていることを特徴とする、ネットワークコントローラ。
【請求項20】
通信ネットワークの端末に対して認可されたDNSトラフィックのリダイレクトを管理するための第2の名前解決サーバであって、前記第2の名前解決サーバは、前記端末の前記DNSトラフィックの認可されたリダイレクトのために前記端末用に識別され、かつ
前記コントローラよって前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換する、
ように構成されていることを特徴とする、第2の名前解決サーバ。
【請求項21】
通信ネットワーク内の端末に対して認可されたDNSトラフィックのリダイレクトを処理するための第1の名前解決サーバであって、前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して前記端末から名前解決メッセージを受信し、
認可サーバから、前記端末のリダイレクト認可と、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子とを取得し、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信する、
ように構成されていることを特徴とする、第1の名前解決サーバ。
【請求項22】
通信ネットワーク内の端末のDNSトラフィックのリダイレクトを認可するための認可サーバであって、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子を取得し、
前記第1の名前解決サーバに、前記端末用のリダイレクト認可と、前記第2の名前解決サーバの少なくとも1つの識別子とを送信する、
ように構成されていることを特徴とする、認可サーバ。
【請求項23】
通信ネットワーク内のDNSトラフィックをリダイレクトするためのシステムであって、請求項18に記載の端末と、
請求項19に記載のネットワークコントローラと、
請求項20に記載の第2の名前解決サーバと、
請求項21に記載の第1の名前解決サーバと、
請求項22に記載の認可サーバと、
を含むことを特徴とする、システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の分野は、通信ネットワーク、例えば、IPプロトコルを実装するコンピュータネットワーク内の通信の分野である。特に、本発明は付加価値のあるIPサービスに関する。
【0002】
より詳細には、本発明は、名前解決サービス、例えばDNS(「ドメインネームシステム」)に関し、DNSサービスの完全性および可用性を保証し、名前解決に関与する悪意のある機器の存在を検出するための解決策を提供する。
【背景技術】
【0003】
DNSシステムは、IPサービスの提供における主要なコンポーネントである。
【0004】
実際、DNSサービスを使用すると、リソース(例えば、ドメイン名タイプ(FQDN(「完全修飾ドメイン名」))、URI(「統一リソース識別子」)を1つまたは複数のIPアドレスに関連付けて、このリソースにアクセスできる。例えば、DNSサービスを使用すると、端末はドメイン名に関連付けられたIPv4アドレスやIPv6アドレスを取得できる。
【0005】
端末にDNSサービスを提供するには、さまざまな解決策が考慮される場合がある。
【0006】
【0007】
このようなホームゲートウェイは、従来、ユーザのローカルエリアネットワーク(「Local Area Network」(LAN))とユーザがサービスオファーに加入しているオペレータ(「インターネットサービスプロバイダ」(ISP))のネットワークの間のインターフェースとして機能していることを想起されたい。したがって、これは、ユーザが加入しているさまざまなサービスの特徴的なトラフィックのすべてが通過するオペレータのネットワークにアクセスするための機器であり、端末にローカルに提供される一連のサービス(例:FTPサービス「File Transfer Protocol」、NFSサービス「Network File System」、メディアサーバ)もサポートする。
【0008】
CPEをネットワークに接続するとき、オペレータは従来、接続サービスにアクセスするために必要な情報をCPEに提供する。したがって、オペレータは、このCPEに接続されている端末との間でIPv4および/またはIPv6通信を確立するために、CPEに関連付けることができるIPv4アドレスおよび/またはIPv6プレフィックスを割り当てる。また、オペレータは、名前解決に使用するDNSサーバのリストをCPEに提供する。これを行うには、IPv4用のDHCP(文書RFC2131(「動的ホスト構成プロトコル」、R.Droms他、1997年3月)およびRFC2132(「DHCPオプションとBOOTPベンダー拡張機能」、S.Alexander、1997年3月)に記載されている「動的ホスト構成プロトコル」)、IPv6用のDHCPv6(文書RFC8415(「IPv6用動的ホスト構成プロトコル (DHCPv6)」、T.Mrugalski他、2018年11月)に記載されている)、またはIPv6のND(文書RFC4861(「IPバージョン6の近隣探索(IPv6)」、T.Narten他、2007年9月)に記載されている「近隣探索プロトコル」)のようなプロトコルが、CPEとアクセスネットワークとの間で使用され得る。CPEの構成には、CWMP(「CPEWAN管理プロトコル」)などの他のメカニズムが使用される場合がある。CWMP(「CPEWAN管理プロトコル」)プロトコルなどの他のメカニズムがCPEの構成に使用される場合がある。
【0009】
したがって、図1Aから図1Cに示すように、ローカルエリアネットワークLAN内に存在する端末H1 11(またはアプリケーション)は、ドメイン名(例えばFQDN)、例えば「notreexample.com」によって識別されるリモートサーバS12との通信を確立したいと考えている。端末H1 11に組み込まれたDNSクライアントは、ドメイン名「notreexample.com」に関連付けられたIPアドレスを取得するために、DNS解決要求とも呼ばれる、Aタイプ(端末がIPv4をサポートする場合)および/またはAAAAタイプ(端末がIPv6をサポートする場合)のDNS要求を、オペレータによって提供され、アクセスネットワークでホストされる(例えば)DNSサーバ13の1つに送信する場合がある。
【0010】
IPv4で到達できるサーバはAタイプのDNSレコードを公開する可能性があるのに対し、IPv6で到達できるサーバはAAAAタイプのレコードを公開する可能性があることを想起されたい。IPv4およびIPv6で到達可能なサーバは、AおよびAAAAタイプのレコードを公開できる。このようなサーバにアクセスしたい端末は、DNS要求でレコードのタイプ(AまたはAAAA)を指定する必要がある。IPv4とIPv6をサポートする端末は2つのDNS要求を送信する場合がある。第1の要求はAタイプのレコードを示し、第2の要求はAAAAタイプのレコードを示す。
【0011】
DNS要求は、図1Aに示すように、端末H1 11からDNSサーバ13に直接送信されてもよいし、または、図1Bに示すように、DNSプロキシ(文書RFC8499-「DNSTerminology」、P.Hoffman他、2019年1月で定義されているように、DNSリレーまたは「DNSフォワーダ」とも呼ばれる)を埋め込む場合、CPE14に送信されてもよい。後者の場合、ローカルキャッシュ内に応答が見つからない場合、CPE14はDNS要求をDNSサーバ13に中継することができる。
【0012】
DNSサーバ13は、要求されたレコードタイプ(AまたはAAAA)について、追跡されたドメイン名に対応する少なくとも1つのエントリがそのデータベース内で利用可能である場合、IPアドレスのリスト(例えば、@S)で応答するか、または、DNSサーバ13にそのようなエントリがない場合は、DNSアーキテクチャの階層構造に従って要求を別のDNSサーバに中継することができる。次に、前記階層の上位に位置する別のDNSサーバ(例えば、権威サーバ)から受信した応答は、最初に要請されたDNSサーバ13によって端末H1 11に中継される。
【0013】
DNS応答は、図1Aに示すようにDNSサーバ13から端末H1 11に直接送信することもできるし、図1Bに示すように「DNSフォワーダ」が存在する場合にはCPE14に送信することもできる。後者の場合、CPE14の「DNSフォワーダ」は、DNS応答を端末H1 11に中継する。
【0014】
したがって、図1Cに示すように、端末H1 11は、応答(例えば@S)に含まれるIPアドレス(または複数のアドレス)を抽出し、返されたアドレス(例えば@S)の1つに接続要求を送信することによって、サーバS12との通信を確立することができる。
【0015】
DNSサーバは、オペレータによってアクセスネットワークを介して、通信デバイス内で、通常、このデバイスをネットワークに接続するとき、または事前の構成(「工場出荷時の」構成など)を使用して接続すると宣言されている場合は、ノミナルサーバと呼ばれる。このステップ中に、通信デバイスは、オペレータによって提供された1つまたは複数の(名目上の)DNSサーバからアクセス可能性情報を取得する。アクセス可能性情報には、IPアドレス、ポート番号、認証参照などのリストが含まれる場合がある。オペレータは、接続、VoIPなどのサービスプロバイダである場合がある。したがって、これらの各オペレータは、通常、インフラストラクチャ内で1つまたは複数のDNSサーバをホストすることによって、独自のDNSサービスを提供する場合がある。サービスは、固定インフラストラクチャまたはモバイルインフラストラクチャ(例えば、PLMNタイプの「Public Land Mobile Network」)を介して提供され得る。
【0016】
さらに、最近では、パブリックDNSサービス(「パブリックリゾルバ」)を提供するサードパーティエンティティが増えている。例えば、このようなDNSサーバは、「Google Public DNS(登録商標)」、「Cloudflare(登録商標)」、またはQUAD9(登録商標)などのエンティティによって運営されている。
【0017】
オペレータが提供するDNS構成を置き換えたり追加したりして、パブリックDNSサーバへのアクセスを可能にするクライアントが増えている。
【0018】
したがって、通信デバイスは、有効なネットワークインターフェース(固定、モバイル、WLAN(「ワイヤレスローカルエリアネットワーク」)など)ごとに新しいDNS構成を取得できる。他の情報(例えば、SIP(「セッション開始プロトコル」)サーバのアクセス可能性)も通信デバイスに提供される場合がある。
【0019】
LANネットワーク内のDNSサーバ検出メカニズムの欠点は、安全ではないことである。
【0020】
例えば、図2に示すように、端末H1 21がローカルエリアネットワークLANに接続すると、例えばDHCPまたはNDプロトコルに従って、その要求に応じて悪意のあるデバイスRS23からメッセージを受信する可能性がある。したがって、端末H1 21は、悪意のあるデバイスR23から発信されたルータ広告タイプRA(「ルータ広告」)のメッセージを受信し、悪意のあるデバイスRS23がそのデフォルトルータであるとみなすことができる。
【0021】
ドメイン名によって識別されるリモートサーバS22との通信を確立したい端末H1 21は、DNS要求をCPE24に送信する代わりに、悪意のある機器RS23に送信することができる。悪意のあるデバイスRS23は、悪意のあるDNSサーバをホストし、悪意のあるリモートサーバAS25(例えば、@AS)のアドレスで応答する可能性がある。
【0022】
その後、端末H1 21は、応答に含まれるIPアドレス(または複数のアドレス)(例えば、@AS)を抽出し、悪意のあるサーバAS25との通信を確立する。
【0023】
したがって、LANネットワーク内に安全な検出メカニズムが欠如しているため、図2に示すように、ユーザの機密データ(個人データなど)の傍受や悪意のあるサイトへのリダイレクトを可能にする攻撃の実行が容易になる可能性がある。
【0024】
最初に検討される解決策は、認証証明書の使用に基づくものである。
【0025】
それにもかかわらず、このような解決策は悪意のある機器を検出するには十分ではない。実際、悪意のある機器は、有効な認可局(「Certification Authority」)から取得した有効な証明書を提示する可能性があり、LANの機器に誤解を与える可能性がある。
【0026】
このセキュリティ問題を解決するために、一部のブラウザおよびアプリケーションは、インターネットサービスプロバイダまたはアプリケーションによって管理される認可済みサーバのリスト(「受け入れリスト」または「ホワイトリスト」)を使用して、検出されたDNSサーバが正当(つまり、信頼できる)かどうかを判断する。例えば、Firefox(登録商標)による認可済みサーバ(「Trusted Recursive Resolver」)のリストには、リンクhttps://wiki.mozilla.org/Trusted_Recursive_Resolverからアクセスできる。
【0027】
検出されたDNSサーバが正当な場合(つまり、検出されたサーバがリストに属している場合)、その後、クライアント/端末は、安全でない接続(Do53とも呼ばれる、ポート53上のUDP/TCPプロトコルに従ったDNS)から安全な接続(例えば、文書RFC8484-「DNS Queriesover HTTPS(DoH)」、P.Hoffman他、2018年10月に記載されているHTTPS(DoH)プロトコル、または、文書「専用QUIC接続上のDNSの仕様」、C.Huitema他、2020年10月20日、に記載されているDNSover QUIC(DoQ)に従ったDNS)への移行を続行できる。
【0028】
安全でない接続を安全な接続に自動的に更新するこの手順(「自動アップグレード」)の問題点は、認可されたサーバのリストを維持することにある。実際、そのコンテンツおよび/またはサイズは、特にサーバの追加または削除によって急速に変化する可能性がある。
【0029】
このような許可されたサーバのリストを、インターネットサービスプロバイダ(ISP)またはアプリケーションプロバイダが運営するサーバのみに制限することは、ローカルエリアネットワーク内で、一般に「DNSフォワーダ」とも呼ばれるDNSリレーの存在を必要とするサービスの提供にも影響する。実際、ローカルエリアネットワークに接続された端末に提供される一部のサービスでは、ローカルの「DNSフォワーダ」を有効化する必要がある。したがって、ローカルの「DNSフォワーダ」をこの許可されたサーバのリストに追加する必要がある。ただし、これらの「DNSフォワーダ」にはインターネットからアクセスできないことに留意されたい。
【0030】
この問題を解決するには、M.Boucadair他、2020年8月27日の文書「Supporting Redirection for DNS Queriesover HTTPS(DoH)」に記載されているように、HTTPSメッセージで伝達されるDNS要求をリダイレクトするための、つまり安全な接続に基づいた解決策が特に提案されている。
【0031】
この技術によれば、オペレータ(インターネットサービスプロバイダなど)は、自分のDNSサーバを許可されたサーバのリストに追加できる。安全な接続が確立されるオペレータのDNSサーバは、DoHサーバまたは別のパートナーサーバとも呼ばれ、LAN内のCPEによって通知される。次に、「DNSフォワーダ」を組み込んだCPEのドメイン名と証明書がオペレータによって生成される。
【0032】
図3に示すように、DoHクライアント(例えば、LAN上に接続された端末31に組み込まれている)は、発表されたDoHサーバ32に接続することによって、そのDo53接続の自動更新手順を実装する。これを行うために、DoHクライアントはDoH要求33をDoHサーバ32に送信する。
【0033】
DoHサーバ32は、「DNSフォワーダ」をホストするCPE35とのDoH接続を確立するように求めるクライアントの要求に応じて、リダイレクトメッセージ34を返す。DoHサーバ32は、認証目的に使用される識別子(例えば、「X.509を使用する公開鍵インフラストラクチャ」を表すPKIX認証)およびCPE35の「DNSフォワーダ」に参加するためのアドレスをクライアントに通信する。他の情報も返される場合がある(ポート番号など)。
【0034】
オペレータのDoHサーバ32によって返されるJSON(「JavaScriptObjectNotation」)オブジェクトの例を付録に示す。
【0035】
リダイレクトメッセージ34を受信すると、クライアント31は、取得した情報を使用してCPE35とのDoHセッション36を確立する。CPE35は、オペレータのDoHサーバ32とのDoHセッション37を維持する。特に、このセッションは、この例では、CPE35に組み込まれたローカルの「DNSフォワーダ」によってローカルで処理できない要求に対応するために使用される場合がある。
【0036】
ただし、このDoH接続を維持するだけでは、クライアント/端末によって送信されたDNS要求がハッキングされるリスクを最小限に抑えるには十分ではない。実際、このメカニズムでは、特にLAN内での悪意のあるサーバの存在を検出することはできない。例えば、悪意のあるサーバがCPEのIPアドレスを横取りし、LANの端末から送信されたDoH要求を傍受する可能性がある。悪意のあるサーバは、CPEによって送信されたメッセージをブロックすることもある。
【0037】
したがって、図4Aに示すように、正当なCPE45に到達するために、端末41は、オペレータのDoHサーバ42にDoH要求43を送信し、応答としてリダイレクトメッセージ44を受信し、PKIX認証の目的で使用される識別子およびアドレスを端末41に通信することができる。悪意のあるサーバ46がCPE45のIPアドレス(@CPE)を横取りした場合、端末41は、DoH要求47を送信することにより、悪意のあるサーバ46とのセッションを確立しようとする。それにもかかわらず、悪意のあるサーバ46によって送信された応答48は、PKIX認証が失敗するため、端末41によって拒否され、端末41はサービスにアクセスできない。端末41がリダイレクト指示を無視して事業者のDoHサーバ42に接続しようとした場合、DoHサーバ42は、前述のメッセージ44と同様のリダイレクトメッセージを体系的に送信し、PKIX認証目的に使用される識別子および正当なCPE45に到達するためのアドレスを端末41に通信する。
【0038】
したがって、従来技術によるこのような技術の欠点は、ローカルサービス(すなわち、CPE内の「DNSフォワーダ」の存在のおかげで提供されるサービス)を含む接続サービスが利用できなくなるリスクである。
【0039】
実際、図4Bに示すように、悪意のあるサーバ46がCPE45によって使用される認証識別子の取得に成功した場合、端末41と悪意のあるサーバ46との間、および悪意のあるサーバ46とリモートサーバ49との間に安全な接続が確立される可能性がある。このような安全な接続が存在するにもかかわらず、悪意のあるサーバ46は、端末41によって送信されたすべてのDNS要求を回復し、場合によっては端末のユーザの個人データを回復する可能性がある。
【0040】
したがって、安全な接続を確立するだけでは、この接続が確立されるサーバの正当性を保証するのに十分ではない。
【0041】
したがって、DoH(アプリケーション層プロトコル)やDoT(文書RFC7858-「トランスポート層セキュリティ(TLS)上のDNSの仕様」、Z.Hu他、2016年5月に記載されているトランスポート層プロトコル)などのプロトコルの有効化は、LANネットワーク内で正当なDNSサーバを検出するメカニズムのセキュリティに関する前述の問題を解決しない。
【0042】
したがって、付加価値サービスを提供し、これらのユーザが名前解決要求を送信するDNSサーバの正当性を保証しながら、DNSサービスに基づいてサービスの継続性を保証し、ユーザの通信のセキュリティを維持できる新しい解決策が必要である。
【発明の概要】
【課題を解決するための手段】
【0043】
本発明は、異なるエンティティに実装され、DNSクライアントからのDNSトラフィックをリダイレクトするための異なる方法を提案し、このDNSクライアントに対してリダイレクト手順が有効化され認可されている場合に、トラフィックを第1の名前解決サーバから第2の名前解決サーバに安全にリダイレクトできるようにする。
【0044】
同じ端末内で複数のDNSクライアントが有効化される可能性があることに留意されたい。この場合、以下で説明する解決策は、有効化を希望する各DNSクライアントに対して独立して実装できる。それにもかかわらず、次に、「DNSクライアント」と「端末」という用語は同じ意味で使用される。
【0045】
したがって、本発明は、通信ネットワークに接続された端末に実装される名前解決方法であって、
例えば、アプリケーション層(HTTPSなど)またはトランスポート層(QUIC/UDPなど)のプロトコルに依存することによって、前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して前記第1の名前解決サーバに名前解決メッセージを送信するステップと、
前記端末のDNSトラフィックのリダイレクトが認可されている(例えば、端末に対してデフォルトで認可されるか、または認可サーバなどの別個のエンティティによって認可される)場合、前記リダイレクトの第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第2の名前解決サーバへの前記端末の前記DNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の障害の通知を送信するステップ、
前記DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行するステップと、
を含む、名前解決方法、を提供する。
例えば、アプリケーション層(HTTPSなど)またはトランスポート層(QUIC/UDPなど)のプロトコルに依存することによって、前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して前記第1の名前解決サーバに名前解決メッセージを送信するステップと、
前記端末のDNSトラフィックのリダイレクトが認可されている(例えば、端末に対してデフォルトで認可されるか、または認可サーバなどの別個のエンティティによって認可される)場合、前記リダイレクトの第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第2の名前解決サーバへの前記端末の前記DNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の障害の通知を送信するステップ、
前記DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行するステップと、
を含む、名前解決方法、を提供する。
【0046】
したがって、提案された解決策では、第2の名前解決サーバの1つまたは複数の識別子の取得に続いて、または取得と同時に、第2の名前解決サーバの正当性を検証する手順など、第2の名前解決サーバの認証問題を克服できる手順(例えば、第2の名前解決サーバに対して少なくとも1つの新しい識別子を生成する手順)、リダイレクトを無効にする手順など、さまざまなアクションを実装できる。
【0047】
したがって、提案された解決策は、DNSサービスおよび/または通信のセキュリティに依存したサービスの継続性を維持するための解決策を提供する。
【0048】
特に、そのような管理アクションは、端末によって発信される名前解決メッセージのヘッダまたは本文で指定される場合がある。このようにして、名前解決メッセージを受信すると、第1のサーバは実装する手順を決定できる。
【0049】
例えば、第2の名前解決サーバの正当性の検証などのアクションを開始するために、DoH取得(fwd-check)またはDoH POST(fwd-check)タイプの名前解決メッセージが発信される場合がある。端末と第2の名前解決サーバとの接続の失敗の通知の送信などのアクションを開始するために、DoH取得(リダイレクト認可失敗)またはDoH POST(リダイレクト認可失敗)タイプの名前解決メッセージが発信される場合がある。DoH取得(リダイレクト無効)またはPOST(リダイレクト無効)タイプの名前解決メッセージは、前記第2の名前解決サーバへのDNSトラフィックの前記リダイレクトの無効化を要求するなどのアクションを開始するために送信される場合がある。特に、端末と前記第2の名前解決サーバとの接続の失敗の通知は、接続の失敗を通知すること、または新しい識別子を生成するための明示的な通知を含むことができる。
【0050】
特に、第2のサーバは、DNSトラフィックリダイレクトサービスの認可された(「受け入れられた」)サーバのリストに追加される場合がある。次に、端末は、この第2のサーバとの安全でない接続から安全な接続への移行を続行し、安全な通信チャネルを使用してDNSトラフィックをこの第2のサーバにリダイレクトする。第2のサーバの正当性の検証が失敗した場合、この第2のサーバを認可されたサーバのリストから抑制する(または追加しない)ことが可能である。この第2のサーバへのリダイレクトは、端末によって無効化される場合がある。
【0051】
例えば、第2の名前解決サーバの前記少なくとも1つの識別子は、第2のサーバを識別するドメイン名、第2のサーバに参加するためのアドレスなどを含むグループに属する。
【0052】
前に示したように、端末のDNSトラフィックのリダイレクトを管理するアクションには、例えば、端末と前記第2の名前解決サーバとの接続の失敗の通知を送信することが含まれる。例えば、このようなアクションにより、さらに第2の名前解決サーバの新しい識別子が取得される。
【0053】
このようにして、端末が第2の名前解決サーバの認証に失敗した場合、第2のサーバの新しい識別子を取得できるアクションをトリガーすることができる。
【0054】
DNSトラフィックのリダイレクトを管理するためのもう1つのアクションは、第2の名前解決サーバの正当性を検証することである。例えば、そのようなアクションには、
前記第1の名前解決サーバのから発信された、前記第2の名前解決サーバの前記正当性を検証するための少なくとも1つの情報を受信するステップと、
第2のサーバの少なくとも1つの識別子を使用して前記端末によって発信され、前記少なくとも1つの検証情報から生成された名前解決要求に対する応答と、前記少なくとも1つの検証情報から得られたテスト応答とを比較することにより、前記応答を発信するエンティティの前記正当性を検証するステップと、
が含まれる。
前記第1の名前解決サーバのから発信された、前記第2の名前解決サーバの前記正当性を検証するための少なくとも1つの情報を受信するステップと、
第2のサーバの少なくとも1つの識別子を使用して前記端末によって発信され、前記少なくとも1つの検証情報から生成された名前解決要求に対する応答と、前記少なくとも1つの検証情報から得られたテスト応答とを比較することにより、前記応答を発信するエンティティの前記正当性を検証するステップと、
が含まれる。
【0055】
端末のDNSトラフィックのリダイレクトを管理するためのさらに別のアクションは、前記第2の名前解決サーバへのDNSトラフィックのリダイレクトを無効化する要求である。特に、そのようなアクションは、例えば、第2サーバの少なくとも1つの新しい識別子が生成されたにもかかわらず、第2サーバの正当性の検証が失敗した場合、または端末の第2サーバへの接続が1回以上失敗した後など、別のアクションの後に実行される場合がある。
【0056】
本発明はまた、通信ネットワーク内の端末に対して認可されたDNSトラフィックのリダイレクトの制御方法にも関し、前記端末は、前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して名前解決メッセージを発信した。
【0057】
このような制御方法は、オーケストレータとも呼ばれるネットワークコントローラに実装され、
前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために前記端末用に識別された第2の名前解決サーバとの間で、前記端末によって前記第2の名前解決サーバの前記正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の障害の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換するステップ、
を含む。
前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために前記端末用に識別された第2の名前解決サーバとの間で、前記端末によって前記第2の名前解決サーバの前記正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の障害の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換するステップ、
を含む。
【0058】
特に、そのような制御方法は、DNSトラフィックのリダイレクトを管理するためのアクション、特に、端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するなどのアクション、または第2の名前解決サーバの正当性を検証するなどのアクションの実行において端末を支援するために実装され得る。
【0059】
第1の名前解決サーバとネットワークコントローラは、同じエンティティを形成することも、別個のエンティティに属することもできる。この第2のケースでは、第1の名前解決サーバとネットワークコントローラは通信するためにメッセージを交換してもよい。
【0060】
特に、第2のサーバが通信ネットワークに対して定義されたデフォルトルータ(CPEなど)である場合、そのようなコントローラは第2の名前解決サーバの識別子を少なくとも1つ持つことができる。代替的に、コントローラは、ネットワークの認可サーバからの第2の名前解決サーバの少なくとも1つの識別子の取得を実装する。
【0061】
特定の実施形態によれば、端末と第2の名前解決サーバとの接続の失敗を解決するために第2の名前解決サーバによって提供される前記情報の少なくとも1つは、前記第2の名前解決サーバの少なくとも1つの新しい識別子を含む。
【0062】
代替的に、コントローラによって実装される方法は、通信ネットワークに対して定義されたデフォルトルータから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップを含む。
【0063】
どちらの場合も、コントローラは、前記少なくとも1つの新しい識別子をネットワークの認可サーバに送信することができる。
【0064】
特に、そのようなアクションは、端末が前記第2の名前解決サーバとの接続の失敗の指示を送信するなど、端末のリダイレクトを管理するためのアクションを実行するときに実装され得る。
【0065】
特定の実施形態によれば、コントローラによって実行される方法は、情報交換中に、第2の名前解決サーバの正当性を検証する権限を有する前記端末の少なくとも1つの識別子、または、前記端末が属するネットワークの少なくとも1つの識別子を前記第2の名前解決サーバに送信するステップを含む。
【0066】
特に、このようなアクションは、端末が第2サーバの正当性を検証するなどのアクションを実行するときに実装される場合がある。
【0067】
このようにして、コントローラは、第2の名前解決サーバの正当性を検証する権限を有する端末を第2の名前解決サーバに通知することができる。
【0068】
例えば、端末の前記少なくとも1つの識別子は、IPv4/IPv6アドレス、IPv4/IPv6プレフィックス、端末の証明書のDNS-ID識別子、または証明書の「サブジェクト代替名」フィールドに入力されたその他の識別子(文書「インターネットX.509公開キー基盤証明書および証明書失効リスト(CRL)プロファイル」に記載)D.Cooper他、2008年5月)などを含むグループに属する。
【0069】
本発明はまた、通信ネットワーク内の端末に対して許可されたDNSトラフィックリダイレクトの管理方法にも関し、前記端末は、前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して名前解決メッセージを発信した。
【0070】
このような管理方法は、前記リダイレクト用の端末に対して識別される前記ネットワークの第2の名前解決サーバに実装され、
前記コントローラから前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の障害の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換するステップを含む。
前記コントローラから前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の障害の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換するステップを含む。
【0071】
特に、このような管理方法は、DNSトラフィックのリダイレクトを管理するためのアクションの実行において端末を支援するために実装される場合がある。
【0072】
特に、管理方法は、名前解決要求に対する応答を前記端末に送信するステップであって、前記応答は、端末の少なくとも1つの識別子から取得されたテスト応答を搬送し、前記第2の名前解決サーバの正当性を検証するための前記少なくとも1つの情報は、コントローラとの交換中に取得される、ステップ、を含む。
【0073】
特に、名前解決要求は、前記少なくとも1つの検証情報から生成されるテスト要求であってもよい。
【0074】
特に、このようなアクションは、端末が第2サーバの正当性を検証するなどのアクションを実行するときに実装される場合がある。
【0075】
別の実施形態によると、管理方法は、
前記第2の名前解決サーバの少なくとも1つの新しい識別子を生成するステップと、
前記コントローラとの交換中に、前記ネットワークコントローラに、前記少なくとも1つの新しい識別子を送信するステップと、
を含む。
前記第2の名前解決サーバの少なくとも1つの新しい識別子を生成するステップと、
前記コントローラとの交換中に、前記ネットワークコントローラに、前記少なくとも1つの新しい識別子を送信するステップと、
を含む。
【0076】
特に、このようなアクションは、端末が端末のリダイレクトを管理するためのアクションを実行して、端末と前記第2の名前解決サーバとの接続の障害の通知を送信するなどのアクションを実行する場合に実装される場合がある。
【0077】
本発明はまた、通信ネットワーク内で端末用に認可されたDNSトラフィックのリダイレクトを処理する方法に関し、前記方法は、前記ネットワークの第1の名前解決サーバに実装されており、
前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して前記端末から名前解決メッセージを受信するステップと、
認可サーバから、前記端末のリダイレクト認可と、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子とを取得するステップと、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信するステップと、
を含む。
前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して前記端末から名前解決メッセージを受信するステップと、
認可サーバから、前記端末のリダイレクト認可と、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子とを取得するステップと、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信するステップと、
を含む。
【0078】
第1の名前解決サーバは、一方で安全な通信チャネルを介して端末と通信し、一方ではネットワークコントローラと通信できる認可サーバと通信し、それ自体が第2の名前解決サーバと通信できる。第1の名前解決サーバと認可サーバは、同じエンティティを形成するか、異なるエンティティに属する場合がある。この第2のケースでは、第1の名前解決サーバと認可サーバがメッセージを交換して通信することができる。
【0079】
例えば、第1の名前解決サーバと前記認可サーバとが異なるエンティティに属している場合、端末のリダイレクト認可と、前記端末に対して識別された第2の名前解決サーバ名の少なくとも1つの識別子とを取得するステップは、
前記端末の少なくとも1つの識別子を持つリダイレクト認可確認要求を認可サーバに送信するステップと、
前記認可サーバから端末のリダイレクト認可と、前記リダイレクトの端末用に識別された前記第2の名前解決サーバの少なくとも1つの識別子とを受信するステップと、
を実行する。
前記端末の少なくとも1つの識別子を持つリダイレクト認可確認要求を認可サーバに送信するステップと、
前記認可サーバから端末のリダイレクト認可と、前記リダイレクトの端末用に識別された前記第2の名前解決サーバの少なくとも1つの識別子とを受信するステップと、
を実行する。
【0080】
第1の実施形態によると、第1の名前解決サーバは、
前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報(認可サーバから発信するか、第1の名前解決サーバによって生成された)を取得するステップと、
前記端末に前記少なくとも1つの検証情報を送信するステップと、
を実行する。
前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報(認可サーバから発信するか、第1の名前解決サーバによって生成された)を取得するステップと、
前記端末に前記少なくとも1つの検証情報を送信するステップと、
を実行する。
【0081】
特に、端末が第2のサーバの正当性の検証などのアクションを実行するときにそのようなステップが実装される場合があり、第1のサーバは少なくとも1つの検証情報を取得できるようにする。
【0082】
第1の変形例によると、少なくとも1つの検証情報を取得するステップは、第1の名前解決サーバによる少なくとも1つの検証テストの生成と、前記認可サーバへの前記少なくとも1つの検証テストの送信とを実行する。
【0083】
したがって、第1のサーバは少なくとも1つの検証テストを生成し(例えば、ドメイン名と関連するDNSエントリを生成する)、一方で認可サーバに(例えば、リダイレクト認可確認要求または「会計要求」メッセージ)、他方では端末に(例えば、「DoH3xx」リダイレクトメッセージ)テストを送信する。
【0084】
第2の変形例によると、少なくとも1つの検証情報を取得することで、前記認可サーバから発信される少なくとも1つの検証テストの受信を実行する。
【0085】
この場合、第1のサーバはテストを端末にのみ送信する(例えば、「DoH3xx」リダイレクトメッセージ)。テスト自体を生成したため、テストを認可サーバに送信する必要はない。
【0086】
第2の実施形態によると、第1の名前解決サーバは、
前記認可サーバから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、
前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を前記端末に送信するステップと、
を実行する。
前記認可サーバから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、
前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を前記端末に送信するステップと、
を実行する。
【0087】
特に、端末が、第1のサーバが前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得できるように、端末と前記第2の名前解決サーバとの接続の障害の通知を送信するなどのアクションを実行するときにそのようなステップが実装される場合がある。
【0088】
例えば、前記第1の名前解決サーバと前記認可サーバとが個別のエンティティに属している場合、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップは、
前記第2の名前解決サーバの少なくとも1つの新しい識別子を生成するための要求を上記の前記認可サーバに送信するステップと、
認可サーバから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を受信するステップと、を実行する。
前記第2の名前解決サーバの少なくとも1つの新しい識別子を生成するための要求を上記の前記認可サーバに送信するステップと、
認可サーバから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を受信するステップと、を実行する。
【0089】
設定する手順が、第2の名前解決サーバの少なくとも1つの新しい識別子を生成することで構成されている場合、第1のサーバは、少なくとも1つの新しい識別子を生成するという要求を送信することにより認可サーバに連絡して、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得できる。例えば、そのような要求は、リダイレクト認可確認要求または「アカウント要求」メッセージで送信される。
【0090】
したがって、第1のサーバは、第2のサーバの少なくとも1つの新しい識別子を受信し、端末に送信する場合がある(例えば、「DoH3xx」リダイレクトメッセージ)。
【0091】
別の実施形態によると、第1の名前解決サーバは、端末と上記の第2の名前の解決の接続の少なくとも1つの失敗に続いて、前記第2の名前解決サーバへのDNSトラフィックリダイレクトの無効化、または、前記端末の要求に応じてデフォルトで指定された第3の名前解決サーバへのDNSトラフィックリダイレクトの無効化を進めることができる。
【0092】
特に、DNSトラフィックが前記第2の名前解決サーバへのリダイレクトの無効化を要求するなどのアクションを端末が実行する場合、そのようなステップが実行されてもよい。
【0093】
リダイレクトの無効化をトリガーすることも、端末の要求に応じて実装することができる。特に、リダイレクトの無効化は、Nを1以上、例えば3に等しい整数として、N回の認証失敗後に(例えば、端末または第1のサーバによって)決定されてもよい。
【0094】
特に、第1の名前解決サーバは、DNSトラフィックリダイレクトのリダイレクトをデフォルトで指定した名前解決サーバ(第3の名前解決サーバ)に無効にする場合があり、したがって、認可サーバによって指定されない場合がある。
【0095】
第1の変形例によると、第1のサーバはリダイレクトの無効化を進める前に、認可サーバから認可を要求する。例えば、第1の名前解決サーバは、
前記第2の名前解決サーバへのリダイレクトの無効化の要求を認可サーバに送信するステップと、
前記認可サーバから発信される無効化認可を受信するステップと、
を実行する。
前記第2の名前解決サーバへのリダイレクトの無効化の要求を認可サーバに送信するステップと、
前記認可サーバから発信される無効化認可を受信するステップと、
を実行する。
【0096】
第2の変形例によると、第1のサーバは第2のサーバへのリダイレクトを無効にすることを決定し、前記認可サーバに通知する。例えば、第1の名前解決サーバは、
前記第2の名前解決サーバのリダイレクトが無効になっている情報を前記認可サーバに送信するステップ、
を実行する。
前記第2の名前解決サーバのリダイレクトが無効になっている情報を前記認可サーバに送信するステップ、
を実行する。
【0097】
本発明はまた、通信ネットワーク内の端末のDNSトラフィックのリダイレクトを認可する方法にも関係しており、前記方法は、前記ネットワークの認可サーバに実装されており、前記端末は、前記端末と第1の名前解決サーバの間の安全な通信チャネルを介して名前の解決メッセージを発信した。
【0098】
このような認可方法は、端末のDNSトラフィックのリダイレクトが認可されている場合に、
前記リダイレクトのために前記端末に対して識別される第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第1の名前解決サーバに、前記端末および前記第2の名前解決サーバの少なくとも1つの識別子に対するリダイレクト認可を送信するステップと、
を含む。
前記リダイレクトのために前記端末に対して識別される第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第1の名前解決サーバに、前記端末および前記第2の名前解決サーバの少なくとも1つの識別子に対するリダイレクト認可を送信するステップと、
を含む。
【0099】
特に、このような認可サーバを使用すると、特に第2のサーバの正当性を検証するため、または認証の問題を解決するために、さまざまな手順/アクションの信頼性を改善できる。
【0100】
特に、そのようなステップは、第1の名前解決サーバから発信されるリダイレクト認可確認要求の受信に続いて実行される。
【0101】
特定の実施形態によれば、このような認可方法は、前記ネットワークのコントローラに、
前記端末の少なくとも1つの識別子、
前記端末が属するネットワークの少なくとも1つの識別子、
前記第2の名前解決サーバの前記少なくとも1つの識別子、
前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、
を含むグループに属する少なくとも1つの要素を送信するステップを含む。
前記端末の少なくとも1つの識別子、
前記端末が属するネットワークの少なくとも1つの識別子、
前記第2の名前解決サーバの前記少なくとも1つの識別子、
前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、
を含むグループに属する少なくとも1つの要素を送信するステップを含む。
【0102】
特に、認可方法は、コントローラの正当性を検証するために、前記情報を送信する前に、前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報の取得を実装することができる。
【0103】
特に、このステップは、端末が第2の名前解決サーバの正当性を検証するなどのアクションを実行するときに実装できる。これにより、認可サーバは、前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報を取得できる。
【0104】
例えば、少なくとも1つの検証情報を取得するステップは、前記第1の名前解決サーバからの少なくとも1つの検証テスト(第1の名前解決サーバによるテスト要求の生成)を受信するステップを実行する。代替的に、少なくとも1つの検証情報を取得するステップは、認可サーバによる少なくとも1つの検証テストの生成と、前記第1の名前解決サーバに少なくとも1つの検証テスト(認可サーバによるテスト要求の生成)を送信とを実行する。
【0105】
別の実施形態によれば、認可方法は、
前記ネットワークコントローラから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、
前記第1の名前解決サーバに、前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を送信するステップと、
を含む。
前記ネットワークコントローラから、前記第2の名前解決サーバの少なくとも1つの新しい識別子を取得するステップと、
前記第1の名前解決サーバに、前記第2の名前解決サーバの前記少なくとも1つの新しい識別子を送信するステップと、
を含む。
【0106】
特に、認可サーバが第2の名前解決サーバの少なくとも1つの新しい識別子を取得できるように、端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するなどのアクションを端末が実行した場合、そのようなステップが実行されてもよい。
【0107】
他の実施形態では、本発明は、対応する端末、ネットワークコントローラ、名前解決サーバ、第2の名前解決サーバ、および対応する認可サーバにも関連している。
【0108】
これらのエンティティの一部は、同じエンティティを形成してもよい(例えば、第1の名前解決サーバおよび/または認可サーバおよび/またはコントローラが共同で設置されてもよい)。この場合、さまざまなモジュール(例えば、第1の名前解決サーバに関連付けられたモジュール、認可サーバに関連付けられたモジュール、ネットワークコントローラに関連付けられたモジュール)は、例えばメッセージを交換することにより、同じエンティティ内で通信する場合がある。
【0109】
さらに、本発明は、端末、ネットワークコントローラ、第1の名前解決サーバ、第2の名前解決サーバ、対応する認可サーバを含む通信ネットワークでDNSトラフィックをリダイレクトするためのシステムに関連している。
【0110】
別の実施形態では、本発明は、これまたはこれらのプログラムがプロセッサによって実行される場合、本発明の少なくとも1つの実施形態に従って少なくとも1つの方法の実装に関する指示を含む、1つまたは複数のコンピュータプログラムに関連している。
【0111】
したがって、本発明による方法は、特に有線形式および/またはソフトウェア形式でさまざまな態様で実装されてもよい。
【0112】
特に、いくつかのステップは、一般的なモジュール、アプリケーション、DNSリゾルバ(「リゾルバ」または「スタブリソルバー」)などによって実装される場合がある。これらのさまざまなモジュールは、CPE、端末(「ユーザ機器」)、例えばUSBポート(「(USB)ドングル」)などを装備しているキーなどに埋め込まれている場合がある。
【0113】
本発明の他の特徴と利点は、単純な例示的で非限定的な例として与えられた特定の実施形態の以下の説明を読むと、および添付の図から、より明確にわかるであろう。
【図面の簡単な説明】
【0114】
【図1A】従来技術に関連して説明した、CPEに埋め込まれたリレー(「DNSフォワーダ」)のないDNSサービスの展開の例を示す図である。
【図1B】従来技術に関連して説明した、CPEに埋め込まれたDNSリレーを使用したDNSサービスの展開の例を示す図である。
【図1C】従来技術に関連して説明した、リモートサーバとの接続の確立の例を示す図である。
【図2】従来技術に関連して説明した、悪意のある機器によるDNS要求の傍受の例を示す図である。
【図3】従来技術によるDNS接続を自動的に更新する手順を示す図である。
【図4A】従来技術に関連して説明し、従来技術に従ってDo53接続を暗号化されたDNS接続に自動的に更新する手順中に遭遇する問題の例を示す図である。
【図4B】従来技術に関連して説明し、従来技術に従ってDo53接続を暗号化されたDNS接続に自動的に更新する手順中に遭遇する問題の例を示す図である。
【図5A】本発明の少なくとも1つの実施形態による、DNSトラフィックのリダイレクトの管理のために実装される主なステップを示す図である。
【図5B】本発明の少なくとも1つの実施形態による、DNSトラフィックのリダイレクトの管理のために実装される主なステップを示す図である。
【図5C】本発明の少なくとも1つの実施形態による、DNSトラフィックのリダイレクトの管理のために実装される主なステップを示す図である。
【図5D】本発明の少なくとも1つの実施形態による、DNSトラフィックのリダイレクトの管理のために実装される主なステップを示す図である。
【図5E】本発明の少なくとも1つの実施形態による、DNSトラフィックのリダイレクトの管理のために実装される主なステップを示す図である。
【図6】端末、名前解決サーバ、および認可サーバの間で交換されるメッセージの例を示す図である。
【図7A】第1の実施形態による、端末、名前解決サーバ、認可サーバ間で交換されるメッセージの例を示す図である。
【図7B】第1の実施形態による、端末、名前解決サーバ、認可サーバ間で交換されるメッセージの例を示す図である。
【図8】本発明の少なくとも1つの実施形態によるトラフィックリダイレクトに関与するさまざまなエンティティを示す図である。
【図9A】第2の実施形態による、端末、第1の名前解決サーバ、および認可サーバの間で交換されるメッセージの例を示す図である。
【図9B】第2の実施形態による、端末、第1の名前解決サーバ、および認可サーバの間で交換されるメッセージの例を示す図である。
【図10A】本発明の少なくとも1つの実施形態による、トラフィックリダイレクト手順の無効化のために端末、名前解決サーバ、および認可サーバの間で交換されるメッセージの例を示す図である。
【図10B】本発明の少なくとも1つの実施形態による、トラフィックリダイレクト手順の無効化のために端末、第1の名前解決サーバ、および認可サーバの間で交換されるメッセージの例を示す図である。
【図11】特定の実施形態による異なるエンティティの簡略化された構造を示す図である。
【発明を実施するための形態】
【0115】
一般原則
本発明は、第1の名前解決サーバから、リダイレクト用に端末用に識別された第2の名前解決サーバへ、端末のDNSトラフィックのリダイレクトを管理する安全な解決策を提案する。
本発明は、第1の名前解決サーバから、リダイレクト用に端末用に識別された第2の名前解決サーバへ、端末のDNSトラフィックのリダイレクトを管理する安全な解決策を提案する。
【0116】
これを行うべく、端末が安全なチャネルを使用して名前解決要求を第1の名前解決サーバに送信できると考えられ、第1の名前解決サーバは、リダイレクト用に端末用に識別された第2の名前解決サーバにDNSトラフィックをリダイレクトするための手順を設定することを希望していると考えられる。
【0117】
本発明の一般原則は、端末による、リダイレクト用に端末用に識別された第2のサーバへの端末のDNSトラフィックのリダイレクトを管理するための少なくとも1つのアクションの実行に基づく。例えば、そのようなアクションは、第2の名前解決サーバの正当性を検証し、端末と第2の名前解決サーバとの接続の失敗の通知を送信し、第2の名前解決サーバへのDNSトラフィックリダイレクトの無効化を要求することなどで構成される。
【0118】
したがって、提案された解決策により、図4Aおよび4Bを参照して説明したID簒奪または認証の問題を検出、回避、および/または修正できる。これにより、端末がDNSサービス(具体的には暗号化されたDNSサービス(「暗号化されたDNS」))に依存するサービスにアクセスできなくなる可能性がある。
【0119】
図5Aから図5Fを参照すると、本発明に従って実装される主なステップが、端末51、第1の名前解決サーバ52、認可サーバ53、ネットワーク54、および第2の名前解決サーバ55を含むシステムで示されている。
【0120】
例えば、ローカルエリアネットワークはルータ、例えばCPEによってオペレータのネットワークに接続されていると考えられ、第1の名前解決サーバ52はオペレータのネットワークに属し、端末51はローカルエリアネットワークに属する。
【0121】
もちろん、他の状況も考慮される可能性がある。例えば、第1の名前解決サーバは、オペレータのネットワーク内の正当なサーバであり、DNSトラフィックをオペレータのネットワーク内の少なくとも1つの第2の名前解決サーバまたは端末に近い別のネットワークにリダイレクトする。
【0122】
したがって、端末と第2の名前解決サーバは必ずしも同じネットワークに接続されている必要はなく、リダイレクトは必ずしもローカルエリアネットワークのサーバに実装されているとは限らない。同様に、第1の名前解決サーバは、アクセスネットワークとは別のネットワークに接続される場合がある。
【0123】
したがって、次に、「通信ネットワーク」とは、端末51、第1の名前解決サーバ52、および第2の名前解決サーバ55が接続される1つまたは複数のネットワークを含むセットであると理解されるべきである。DNSトラフィックのリダイレクトの管理に介入する可能性のある他のエンティティも、このネットワークまたはこれらのネットワーク、特に認可サーバ53に接続することができ、特に、リダイレクトが端末、場合によっては、ネットワークコントローラ54に対して認可されているかどうかを検証することを可能にする。これらの各エンティティは、通信ネットワークとは別のネットワークに接続されてもよい。それにもかかわらず、異なるエンティティは少なくともペアで相互に通信し得る。
【0124】
図5Aに示すように、ステップ511中に、端末51は、端末51と第1の名前解決サーバ52との間の安全な通信チャネルを介して、少なくとも1つの名前解決メッセージを第1の名前解決サーバ52に送信する。
【0125】
端末のDNSトラフィックのリダイレクトが許可されている場合、端末51は、リダイレクトのために、第1の名前解決サーバ52、または第1の名前解決サーバ52と直接もしくは間接的に通信するエンティティから発信される、正当な第2の名前解決サーバ55(例えば、認可サーバ53またはネットワークコントローラ54)の少なくとも1つの識別子を取得する(512)。
【0126】
次いで、端末51は、少なくとも
- 第2の名前解決サーバの正当性を検証する、
- 端末と第2の名前解決サーバとの接続の失敗の通知を送信する、
- 第2の名前解決サーバへのDNSトラフィックのリダイレクトの無効化を要求する、
の中から、端末のDNSトラフィックの第2の名前解決サーバ55への前記リダイレクトを管理するための少なくとも1つのアクションを実行する(513)ことができる。
- 第2の名前解決サーバの正当性を検証する、
- 端末と第2の名前解決サーバとの接続の失敗の通知を送信する、
- 第2の名前解決サーバへのDNSトラフィックのリダイレクトの無効化を要求する、
の中から、端末のDNSトラフィックの第2の名前解決サーバ55への前記リダイレクトを管理するための少なくとも1つのアクションを実行する(513)ことができる。
【0127】
特に、第2の名前解決サーバの正当性を検証するために、端末51は、後述するように、リダイレクトメッセージに含まれる前記少なくとも1つの識別子から識別されるエンティティに名前解決(つまり、そのIDが別のエンティティによって横取りされていない場合の第2のサーバの名前解決)要求を発信することができる。
【0128】
図5Bに示すように、端末のDNSトラフィックのリダイレクトが認可されている場合、ネットワークコントローラ54は、特に、端末51のDNSトラフィックリダイレクト管理動作の実行を支援するために、端末のDNSトラフィックの認可されたリダイレクトのために、端末に対して識別された第2の名前解決サーバ55と情報を交換(541)することができる。
【0129】
例えば、制御部54は、端末51が第2の名前解決サーバ55の正当性を検証するための少なくとも1つの情報を第2の名前解決サーバ55に提供してもよい。さらに、コントローラ54は、第2の名前解決サーバから、端末と第2の名前解決サーバとの接続の失敗を解決するための少なくとも1つの情報、例えば第2の名前解決サーバの新しい識別子を取得してもよい。
【0130】
同様に、端末のDNSトラフィックのリダイレクトが認可されている場合、図5Cに示す第2の名前解決サーバ55は、端末51によるDNSトラフィックリダイレクト管理アクションの実行を支援するために、ネットワークコントローラ54と情報を交換する(551)ことができる。
【0131】
例えば、第2の名前解決サーバ55は、端末51が第2の名前解決サーバ55の正当性を検証するための少なくとも1つの情報を制御部54から取得してもよい。第2の名前解決サーバ55は、端末と第2の名前解決サーバとの接続の失敗を解決するための少なくとも1つの情報をネットワークコントローラ54に提供することもできる。
【0132】
図5Dは、第1の名前解決サーバ52に実装される主なステップを示す。
【0133】
図5Dに示すように、端末51から名前解決メッセージを受信521すると、第1の名前解決サーバ52は、特に、例えば認可サーバ53に問い合わせることによって、端末のDNSトラフィックのリダイレクトが認可されているかどうかを検証することができる。認可サーバ53は、ネットワークコントローラ54と通信することもできる。
【0134】
例えば、第1の名前解決サーバ52は、端末51の識別子または端末51が接続されているネットワークの識別子を少なくとも含むリダイレクト型サービス認可検証要求を認可サーバ53に送信してもよい。
【0135】
ここではサービスがリダイレクト型の場合について説明する。他の実施形態では、認可サーバは、名前解決メッセージで識別されたDNSプロファイルを使用することが端末に認可されているかどうかを検証することができる。実際、複数のDoHプロファイル(「URIテンプレート」で識別される)が同じ名前解決サーバでサポートされていてもよい。これらのプロファイルの各々がさまざまなDNSサービスを提供するように構成されていてもよい(フィルタリング、アンチスパム有効化によって、またはフィルタリング、アンチスパム有効化なしでなど)。
【0136】
したがって、第1の名前解決サーバ52は、端末に対するリダイレクト許可と、リダイレクトのために端末51に対して識別された第2の正当な名前解決サーバの少なくとも1つの識別子を取得し(522)、第2の正当な名前解決サーバの前記少なくとも1つの識別子を含むリダイレクトメッセージを端末51に送信する(523)ことができる。
【0137】
図5Eに示すように、認可サーバ53は、特に、例えば第1の解決サーバ52からリダイレクト型のサービス認可検証要求を受信したときに、リダイレクトのために端末51に対して識別される正当な第2の名前解決サーバ55から少なくとも1つの識別子を取得(531)することができる。
【0138】
特に、端末の識別子およびローカル命令(つまり、認可サーバのオペレータからの命令(デフォルトのリダイレクトまたは特定の識別子など))に基づく検証の後、認可サーバ53は、該当する場合、端末51の識別子から識別される端末51に関連付けられた第2の名前解決サーバ55の少なくとも1つの識別子を取得する(531)。
【0139】
その後、認可サーバ53は、端末51に対するリダイレクト認可および第2の名前解決サーバ55の少なくとも1つの識別子を第1の名前解決サーバ52に送信することができる(532)。
【0140】
上で示したように、これらの異なるエンティティは、特に、第2の名前解決サーバ55への端末のDNSトラフィックのリダイレクトを管理するための少なくとも1つのアクションの実行において端末51を支援することができる。
【0141】
以下、第1の実施形態について説明する。この実施形態によれば、DNSトラフィックリダイレクト管理アクションは、第2の名前解決サーバの正当性を検証することからなる。
【0142】
この第1の実施形態によれば、本発明は、第2の名前解決サーバ55であることを示すエンティティが悪意のあるものであるかどうかを検出できる解決策を提案する。特に、悪意のあるエンティティの存在が確認された場合、トラフィックのリダイレクトを中断する可能性がある。そのために、テスト手順が実装される場合がある。
【0143】
例えば、この第1の実施形態によれば、第2の名前解決サーバの正当性を検証するようなアクションの実行は、端末51による第1の名前解決サーバ52への、第2の名前解決サーバの正当性の検証を要求する通知の送信を含む。例えば、そのような通知は、ステップ511中に端末51から第1の名前解決サーバ52に送信される名前解決メッセージの本文またはヘッダに挿入されてもよいし、別のメッセージに挿入されてもよい。
【0144】
第2の名前解決サーバの正当性の検証を要求する通知を受信すると、第1の名前解決サーバ52は、第2の名前解決サーバの正当性を検証するための少なくとも1つの情報を生成するか、認可サーバ53にそのような情報の取得を要求する。
【0145】
したがって、第1の名前解決サーバ52は、例えばリダイレクトメッセージにおいて、第2の名前解決サーバの正当性を検証するための情報を端末51に送信することができる。
【0146】
また、第1の名前解決サーバ52が第2の名前解決サーバの正当性を検証するための情報を生成している場合には、これらの情報は、認可サーバ53に送信され、次に認可サーバ53からネットワークコントローラ54に送信され、さらにネットワークコントローラ54から正当な第2の名前解決サーバ55に送信され得る。
【0147】
第1の名前解決サーバ52が認可サーバ53から第2の名前解決サーバの正当性を検証するための情報を受信した場合、これらの情報は、認可サーバ53からネットワークコントローラ54に直接送信され、次にネットワークコントローラ54から正当な第2の名前解決サーバ55に送信される。
【0148】
代替的に、第1の名前解決サーバは、正当な第2の名前解決サーバ55と直接通信することもできる。
【0149】
したがって、端末51と正当な第2の名前解決サーバ55は、第2の名前解決サーバの正当性を検証するための同じ情報を有することになる。例えば、そのような情報には、少なくとも1つのDNS要求と対応する応答によって形成される1つまたは複数の検証テストが含まれる。
【0150】
したがって、端末51は、リダイレクトメッセージに含まれる検証テストから構築された、リダイレクトメッセージから識別されたエンティティにテスト要求を発信することができる。
【0151】
次いで、端末51は、このエンティティから受信した応答を、リダイレクトメッセージに含まれる検証テストから端末51によって取得されたテスト応答と比較することによって、リダイレクトメッセージから識別されたエンティティの正当性を検証することができる。
【0152】
特に、端末51によって応答が受信されない場合、または応答が提示されたが、検証情報において第1の名前解決サーバ52によって通信された応答に対応しない場合、端末51は、リダイレクトメッセージから識別され、自身を第2の名前解決サーバ55であると称するエンティティが悪意のあるものであると結論付けることができる。
【0153】
さらに、ネットワークコントローラ54は、事前に認可サーバ53から端末51の識別子を取得し、それを正当な第2の名前解決サーバ55に送信していてもよい。
【0154】
したがって、名前解決要求を受信すると、正当な第2の名前解決サーバ55は、名前解決要求を発行したエンティティの少なくとも1つの識別子が、名前解決メッセージを発信した端末の識別子と同一であるか、または相関しているかどうかを検証することができる。
【0155】
本明細書において、相関する識別子とは、依存関係によって関連付けられた識別子(例えば、識別子とこの識別子のエンコードされたバージョン)を理解すべきである。例えば、要求を発信したエンティティの識別子が、端末に割り当てられたプレフィックス(例えば、IPv6/64プレフィックス)から形成されたアドレスである場合、第2の名前解決サーバは相関があると判断する。
【0156】
したがって、正当な第2の名前解決サーバ55は、検証に使用される名前解決要求がネットワークコントローラ54によって識別された端末51から発信されたものであるかどうかを特に検証し、そして、名前解決要求がネットワークコントローラ54によって識別された端末51から発信された場合にのみ、(検証テストからの応答を構築することによって)名前解決要求を処理しないことを決定することができる。
【0157】
以下、第2の実施形態について説明する。この実施形態によれば、DNSトラフィックリダイレクト管理アクションは、端末と第2の名前解決サーバとの接続の失敗の指示を送信することからなる。
【0158】
この第2の実施形態によれば、本発明は、認証失敗後に第2の名前解決サーバ55との接続を確立できる解決策を提案する。これを行うために、第2の名前解決サーバに参加するための新しいアドレスが生成される場合がある。
【0159】
例えば、この第2の実施形態によれば、「端末と第2の名前解決サーバとの接続の失敗の指示を送信する」などのアクションの実行は、端末51から第1の名前解決サーバ52に、第2の名前解決サーバ55からの少なくとも1つの新しい識別子の生成を要求する通知の送信を含む。例えば、そのような通知は、ステップ511中に端末51から第1の名前解決サーバ52に送信される名前解決メッセージの本文またはヘッダに挿入されてもよいし、別のメッセージに挿入されてもよい。例えば、端末51が第2の名前解決サーバ55の認証に失敗した場合(認証失敗)、そのような通知が第1の名前解決サーバ52に送信されてもよい。
【0160】
この場合、第2の名前解決サーバ55から少なくとも1つの新しい識別子の生成を要求する通知を受信すると、第1の名前解決サーバ52は、第2の名前解決サーバの少なくとも1つの新しい識別子の生成を求める要求を認可サーバ53に送信することができる。認可サーバ53は、要求をネットワークコントローラ54に送信することができ、ネットワークコントローラ54は、それを正当な第2の名前解決サーバ55に送信することができる。代替的に、第1の名前解決サーバは、正当な第2の名前解決サーバ55と直接通信することもできる。
【0161】
この要求を受信すると、正当な第2の名前解決サーバ55は、少なくとも1つの新しい識別子を生成し、その新しい識別子をネットワークコントローラ44に送信することができる。ネットワークコントローラ54は、新しい識別子を第2の名前解決サーバ55から認可サーバ53に転送し、認可サーバ53は、それらを第1の名前解決サーバ52に転送することができる。代替的に、正当な第2の名前解決サーバ55は、第1の名前解決サーバと直接通信することもできる。
【0162】
新しい識別子はIPアドレスである可能性があるが、代わりに他の識別子(ドメイン名、ポート番号、証明書など)を考慮することもできる。
【0163】
第1の名前解決サーバ52は、例えばリダイレクトメッセージ内で、第2の名前解決サーバ55の新しい識別子を端末51に送信することができる。
【0164】
上述した2つの実施形態は、同時にまたは連続的に実施することができる。
【0165】
さらに、第1のドメイン名解決サーバ、認可サーバ、および/またはネットワークコントローラは、同じエンティティまたは別個のエンティティである可能性があることに留意されたい。したがって、第1のドメイン名解決サーバ、認可サーバ、および/またはネットワークコントローラに関連付けられた機能は、同じノードまたは別個のノードに埋め込むことができる。
【0166】
例えば、端末51と第1の名前解決サーバ52または第2の名前解決サーバ55との間の交換にはDoHプロトコルが使用される。したがって、端末51はDoHクライアントである。
【0167】
特に、名前解決メッセージは、DoH取得タイプのメッセージであってもよく、リダイレクトメッセージは、DoH「3xx」タイプ(以下、DoH REDIRECTと呼ぶ)であってもよい。
【0168】
もちろん、他のプロトコルを使用することもできる。例えば、DNS交換はDoQなどのプロトコルに依存する場合がある。
【0169】
特に、開示されたトラフィックリダイレクト方法は、名前解決サービスで使用されるトランスポートプロトコルとは独立して適用される。特に、IPネットワークを考慮すると、DNS通信で使用されるトランスポートプロトコルは、(特に、ネットワークへのアクセス条件に応じて)交換可能にIPv4またはIPv6になる。
【0170】
したがって、提案された解決策は、検討されている実施形態に応じて、次の利点、すなわち、
- クライアントに提供されるサービス(特にDNSベースのサービス)の可用性を保証し、クライアントが認識するエクスペリエンスの品質の低下を回避する、
- 信頼性が高く堅牢な名前解決サービスのセットを提供し、そのようなサービスを提供するために必要な既存のインフラストラクチャとプロトコルの変更を最小限に抑える、
- コンピュータネットワーク(国内または社内の企業ネットワーク)内で、そのような攻撃の中継器として機能する悪意のある機器による攻撃およびデータ傍受を検出する、
- オペレータが、特に名前解決に基づいて、CPEがホストする「DNSフォワーダ」などの第2の名前解決サーバの有効化を含む付加価値サービスをクライアントに提供し続けることができるようにする、
- かかる名前解決サービスに加入しているオペレータに対するユーザの信頼を向上させる、
- 「信頼できる」認可されたサーバの制限されたリストを有する、
のうちの少なくとも1つを提供する。
- クライアントに提供されるサービス(特にDNSベースのサービス)の可用性を保証し、クライアントが認識するエクスペリエンスの品質の低下を回避する、
- 信頼性が高く堅牢な名前解決サービスのセットを提供し、そのようなサービスを提供するために必要な既存のインフラストラクチャとプロトコルの変更を最小限に抑える、
- コンピュータネットワーク(国内または社内の企業ネットワーク)内で、そのような攻撃の中継器として機能する悪意のある機器による攻撃およびデータ傍受を検出する、
- オペレータが、特に名前解決に基づいて、CPEがホストする「DNSフォワーダ」などの第2の名前解決サーバの有効化を含む付加価値サービスをクライアントに提供し続けることができるようにする、
- かかる名前解決サービスに加入しているオペレータに対するユーザの信頼を向上させる、
- 「信頼できる」認可されたサーバの制限されたリストを有する、
のうちの少なくとも1つを提供する。
【0171】
特定の実施形態の説明
端末のDNSトラフィックのリダイレクトを管理するための本発明のさまざまな実装例を以下に説明する。例えば、端末と名前解決サーバが安全なチャネルを介して通信できるように、DNSメッセージの暗号化にDoHプロトコルが使用されていると考えられる。
端末のDNSトラフィックのリダイレクトを管理するための本発明のさまざまな実装例を以下に説明する。例えば、端末と名前解決サーバが安全なチャネルを介して通信できるように、DNSメッセージの暗号化にDoHプロトコルが使用されていると考えられる。
【0172】
次に、「正当なDNSサーバ」とは、オペレータによって宣言または設定され、例えばアクセスネットワーク内でホストされている名前解決サーバと理解されるべきであるが、他のサーバ(例えば、サードパーティによって運営されるDNSサーバ)も考慮される。
【0173】
次に、「悪意のある」機器またはエンティティによって、また、DNSトラフィックの傍受を許可する情報を横取りまたは公表する通信ネットワークのマシン(例えば、正当なDNSサーバのIDを横取りするマシン、またはDNSトラフィックが通過するデフォルトルータのIDを横取りするマシン)も理解される必要がある。
【0174】
悪意のあるデバイスの性質については想定されていないことに留意されたい。これは、例えば、ユーザが設置したデバイス、訪問者(ゲストなど)の機器、WLANネットワークのカバレッジエリア内にある機器、オペレータのネットワーク(CPE)などにアクセスするための機器などで構成される。
【0175】
例えば、通信ネットワークはホームコンピュータネットワークまたは企業ネットワークであり、ローカルエリアネットワークまたはLANとも呼ばれる。
【0176】
例えば、ローカルエリアネットワークに接続された端末に提供される一部のサービスでは、ローカルエリアネットワーク内の名前解決サーバ(「フォワーダDNS」)の起動が必要となるため、アクセスネットワークのオペレータは、DNSトラフィックリダイレクト手順を設定したいと考えられる。これは、例えば接続されたオブジェクトやプリンタなどの端末の場合である。
【0177】
例えば、この名前解決サーバは、第2の名前解決サーバとも呼ばれ、ローカルエリアネットワークとアクセスネットワーク間の少なくとも1つのネットワークインターフェースに関連付けられたCPEによってホストされ、ローカルエリアネットワーク上の端末のデフォルトルータとして定義されると考えられる。他のルータをローカルエリアネットワークに導入することもできる。例えば、CPEとは異なるホームルータを設置して、LANのトラフィックをプライベートトラフィックとプロフェッショナルトラフィックの間で分割することができる。それにもかかわらず、ローカルエリアネットワークとアクセスネットワーク間のトラフィックはCPEを通過し、CPEはデフォルトルータとみなされる。あるいは、第2の名前解決サーバは、ローカルエリアネットワークに接続された別のエンティティである場合もある。
【0178】
図6に示すように、DNSトラフィックリダイレクト手順を設定するために、端末61は名前解決メッセージを第1のDoHサーバ62に発信する。例えば、このようなDoH要求はDoH取得またはDoH POSTタイプである。
【0179】
DoH要求を受信すると、第1のDoHサーバ62は、認可サーバ63とインターフェースして、新しい接続を設定する必要があるときに適用される命令を取得することができる。
【0180】
そうするために、第1のDoHサーバ62は、例えば「Access-Request」タイプのリダイレクト認可検証要求を認可サーバ63に送信する。
【0181】
認可サーバ63は、例えば、そのIPv4アドレス、および/またはDoH要求を発信するためにDoHクライアントによって使用されるIPv6プレフィックス、および/または端末61の証明書のDNS識別子(DNS-ID)など、端末の少なくとも1つの識別子からトラフィックのリダイレクトに使用されるローカルエリアネットワーク(例えば、CPEに埋め込まれた)の第2のDoHサーバを識別することができる。
【0182】
例えば、第2のDoHサーバを識別するために有効なクライアントのデータベースが使用される。特に、オペレータはサービスのリストと関連情報を最新の状態に保つことがある。
【0183】
したがって、この実装例によれば、認可サーバ63は、DNSトラフィックのリダイレクトに適格なDoH端末/クライアントのリストを維持していると仮定される。
【0184】
例えば、このような認可サーバ63はRADIUSサーバ(文書RFC2865、「リモート認証ダイヤルインユーザサービス(RADIUS)」、C.Rigney他、2000年6月に記載されている「リモート認証ダイヤルインユーザサービス」)であり、DoHクライアントに関連付けられた第2のDoHサーバを識別するために、新しいRADIUS属性が定義されている。例えば、このような属性には、第2のDoHサーバ用に構成されたドメイン名(ADNまたは「認証ドメイン名」)、第2のDoHサーバに到達するために使用される少なくとも1つのアドレス(内部アドレスなど)(「ロケータ」)、おそらくDoHサービスの代替ポート番号(「ポート」)などが含まれる。
【0185】
したがって、認可サーバ63は、リダイレクト認可検証要求に応答して、これらの異なる情報(ドメイン名、アドレス、代替ポート番号など)を、例えば「Access-Accept」タイプメッセージで第1のDoHサーバ62に通信することができる。特に、DoHクライアントが別のサーバ(悪意のあるサーバである可能性がある)にこのドメイン名の解決を要求するのを避けるために、ドメイン名に加えてアドレス/ポート番号が応答で伝えられる場合がある。
【0186】
特に、第1のDoHサーバ62は、この情報を「DoH REDIRECT」メッセージで端末61に中継することができる。
【0187】
したがって、端末61は、第2のDoHサーバ(例えば、CPEに組み込まれた「DNSフォワーダ」)へのDNS要求のリダイレクトと、第2のDoHサーバとのDoHセッションの確立を進めることができる。
【0188】
特に、端末61は、特に認証の問題を検出した場合、または第2のDoHサーバの正当性に疑問がある場合に、端末のDNSトラフィックの第2の名前解決サーバへのリダイレクトを管理するための少なくとも1つのアクションを実行することができる。
【0189】
前述の第1の実施形態によれば、端末は、特に、前記第2の名前解決サーバの正当性の検証などのアクションを実行することができる。
【0190】
したがって、トラフィックのリダイレクトの初期化時、または第2のDoHサーバへのDNSトラフィックのリダイレクトの設定後、端末は第2のDoHサーバの正当性の検証を続行できる。実際、端末は、自分自身を第2のDoHサーバであると見せかけるエンティティが悪意があると疑い、悪意があることが判明した場合に、端末が発信するDNS要求がそのようなエンティティにリダイレクトされるのを回避する可能性がある。
【0191】
この場合、図7Aに示すように、端末71は、第2のDoHサーバの正当性の検証を要求する通知を第1のDoHサーバ72に送信してもよい。
【0192】
例えば、端末71は、第2のDoHサーバの正当性を検証するための手順を設定したいことを第1のDoHサーバ72に示すため、DoH取得解決メッセージのヘッダ(またはDoH POSTメッセージの本文)に新しいオブジェクト(「fwd-check」)を挿入する。
【0193】
「fwd-check」オブジェクトを含むこのDoH取得(fw-check)要求を受信すると、第1のDoHサーバ72は、例えば、前述した「Access-Request」タイプのリダイレクト認可検証要求を送信することによって、認可サーバ73に、このクライアントに対してリダイレクトが有効化されているかどうかを検証するよう要求する。認可サーバ73は、前述したように、「Access-Accept」タイプの応答を送信することによって応答することができる。
【0194】
また、第1のDoHサーバ72は、端末72と連携して検証手順を設定することを認可サーバ73に通知する。例えば、第1のDoHサーバ72は、例えば「Accounting-Request」タイプのメッセージで、第2のDoHサーバの正当性を検証するための少なくとも1つの情報を認可サーバ73に送信することができる。したがって、第1のDoHサーバ72は、少なくとも1つのテスト(「CHECK」)の記述情報、および場合によっては端末71によるテストの実行の期限(「T」)を認可サーバ73に通信することができる。
【0195】
例えば、各テストはオペレータだけが知っている固有のDNSエントリであり、したがって第1のDoHサーバ72だけが知っている。テストは、タイプ、DNS要求(「チェッククエリ」)、および関連する応答(「チェックリプライ」)を使用して定義できる。
【0196】
次に、認可サーバ73は、端末71の少なくとも1つの識別子と、第2のDoHサーバの正当性を検証するための情報(少なくとも1つのテスト(「CHECK」)の説明情報、およびおそらく端末71によるテスト実行の期限(「T」))とをネットワークコントローラに送信する。例えば、このようなネットワークコントローラは、CWMPプロトコルの自動構成サーバ(「Auto-Configuration Server (ACS)」)である。
【0197】
例えば、第2のDoHサーバの正当性を検証するための情報は、YANGセマンティクスに従って初期化される。
【0198】
認可サーバ73とネットワークコントローラによって使用されるYANGモジュールのツリー構造(「tree structure」)の例を付録に示す。
【0199】
第2のDoHサーバがCPEによってホストされていない場合、認可サーバ73は、第2のDoHサーバの少なくとも1つの識別子も送信する。第2のDoHサーバがCPEによってホストされている場合、ネットワークコントローラは自由に使える情報から第2のDoHサーバの識別子を直接取得できることに留意されたい。
【0200】
オーケストレータとも呼ばれるネットワークコントローラは、正当な第2のDoHサーバに第2のDoHサーバの正当性を検証するための情報(少なくとも1つのテスト(「CHECK」)の説明情報、およびおそらくテスト実施の期限(「T」))を送信する。
【0201】
ネットワークコントローラはまた、検証手順に関係する端末71の少なくとも1つの識別子を正当な第2のDoHサーバに送信する。
【0202】
図8に示されるように、認可サーバ73とネットワークコントローラ74との間の交換は、例えばNETCONFまたはRESTCONFプロトコルに従って安全な通信チャネルで実装され得る。ネットワークコントローラ74と第2のDoHサーバ75との間の交換は、例えばNETCONFまたはRESTCONFプロトコルに従って安全な通信チャネルで実装されてもよい(文書RFC8071(「NETCONF Call Home and RESTCONF Call Home」、K.Wasten、2017年2月)またはTR-069(CWMPは「CPE WAN Management Protocol」の略)に記載されている)。
【0203】
同様に、第1のDoHサーバ72は、例えばDoH REDIRECTリダイレクトメッセージ(CHECK、T)において、第2のDoHサーバの正当性を検証するための情報を端末71に通信することができる。
【0204】
第1のDoHサーバ72が検証情報を端末71に通信するために使用するJSONオブジェクトの例を付録に示す。
【0205】
従来技術で与えられた例と比較すると、したがって、このようなJSONオブジェクトは、第2のDoHサーバの正当性を検証するために実装されるテスト、特にテストタイプ(「check-rrtype」)、テスト要求(「チェッククエリ」)、およびテスト要求(「チェック返信」)に対する応答を記述する。「check-rrtype」はDNSリソースタイプ(「リソースレコードタイプ」)を示す。
【0206】
上記の例によれば、このリダイレクトメッセージを受信し、5秒後(「タイマ」で定義された期限)、端末71は、第1のDoHサーバ72から受信した第2のDoHサーバの識別子を使用して、ドメイン名「test47fsgugsdf4zjou.defhiyef.isp」(「チェッククエリ」)に対する「txt」タイプのテスト要求を送信する。
【0207】
このテスト要求を受信したエンティティは、要求の処理を続行する。
【0208】
この要求を受信したエンティティが応答を構築すると、それを端末71に送信し、この応答は第1のDoHサーバ72によって直接通信された応答(「チェック応答」)に対応し、端末71は、このエンティティが実際に正当な第2のDoHサーバであると結論付ける。
【0209】
この要求を受信するエンティティが悪意のある場合(例えば、第2のDoHサーバのIDを乗っ取っているなど)、エンティティはいくつかの戦略を採用する可能性がある。
- 応答をエミュレートし、それを端末71に送信する。この応答が、第1のDoHサーバ72によって直接通信されたもの(「チェック応答」)に対応する確率は、ほぼゼロである。すると、端末71は、受信した応答の不一致を検出し、エンティティが名前解決要求を受信したとみなす。
- 要求を通常のサーバ(つまり、ローカルエリアネットワークによって構成されたサーバ)に中継する。正当な第2のDoHサーバのみが応答を持っているため、否定応答が送信される。
- 要求を正当な第2のDoHサーバに中継する。第2のDoHサーバは、ネットワークコントローラから受信した端末の識別子に基づいて(例えば、端末の少なくとも1つの識別子に基づいてフィルタを適用することによって)、名前解決要求が実際に端末から発信されたものであるかどうかを検証するため、否定応答が第2のDoHサーバによって送信される。
- 要求を別の悪意のあるサーバに中継する。否定的な応答が送信される。
- 応答をエミュレートし、それを端末71に送信する。この応答が、第1のDoHサーバ72によって直接通信されたもの(「チェック応答」)に対応する確率は、ほぼゼロである。すると、端末71は、受信した応答の不一致を検出し、エンティティが名前解決要求を受信したとみなす。
- 要求を通常のサーバ(つまり、ローカルエリアネットワークによって構成されたサーバ)に中継する。正当な第2のDoHサーバのみが応答を持っているため、否定応答が送信される。
- 要求を正当な第2のDoHサーバに中継する。第2のDoHサーバは、ネットワークコントローラから受信した端末の識別子に基づいて(例えば、端末の少なくとも1つの識別子に基づいてフィルタを適用することによって)、名前解決要求が実際に端末から発信されたものであるかどうかを検証するため、否定応答が第2のDoHサーバによって送信される。
- 要求を別の悪意のあるサーバに中継する。否定的な応答が送信される。
【0210】
テスト要求に対する応答(「チェッククエリ」)が端末71によって受信されない場合、または応答が提示されたが、その応答が正当な第1のDoHサーバによって直接通信されたものに対応しない場合(「チェック応答」)、次に、端末71は、第1のDoHサーバ72から受信した第2のDoHサーバの識別子を使用して到達できるエンティティは悪意があると結論付け、その後、トラフィックのローカルリダイレクトを無効化することを可能にする手順を設定することができる。
【0211】
図7Bに示す変形例によれば、デフォルトで、例えばトラフィックのリダイレクトの初期化時または第2のDoHサーバの起動時に、第2のDoHサーバの正当性を検証することも可能である。
【0212】
この場合、図7Bに示すように、端末71によって発信された名前解決メッセージを受信すると、第1のDoHサーバ72は、例えば前述した「アクセス要求」タイプのリダイレクト認可検証要求を送信することによって、このクライアントに対してリダイレクトが有効化されているかどうかを検証するよう認可サーバ73に要求する。前に説明したように、認可サーバ73は、例えば第2のDoHサーバの正当性を検証するための少なくとも1つの情報、例えば少なくとも1つのテスト(「CHECK」)の記述情報を含む「Access-Accept」タイプの応答を送信することによって応答することができる。
【0213】
第1のDoHサーバ72は、例えばリダイレクトメッセージ「DoH REDIRECT (CHECK)」において、リダイレクト情報(ADN、LOCATORS、PORTなど)および第2のDoHサーバの正当性を検証するための情報を端末71に通信することができる。
【0214】
端末71が検証手順の実行中(または後述する第2のサーバの認証中)に異常を検出した場合、端末71は、トラフィックのローカルリダイレクトを無効化できる手順を設定することができる。
【0215】
前述の第2の実施形態によれば、端末は、第2の名前解決サーバとの端末の接続の失敗の指示を送信するなどのアクションを実行することもできる。
【0216】
例えば、トラフィックのリダイレクトの初期化時に、端末は第2のDoHサーバの認証手順が失敗したことを検出する可能性がある。この場合、端末と第2のDoHサーバとの間の接続を確立できない。したがって、端末でローカルに利用できるサービスはない。
【0217】
この第2の実施形態は、第1の実施形態に続いて、例えば端末による名前解決要求の発行に続いて実装されてもよい。特に、認証失敗は、第2のDoHサーバのID(IPアドレスなど)を横取りする悪意のあるサーバの存在が原因である可能性がある。
【0218】
【0219】
例えば、端末91は、第2のDoHサーバの認証が失敗したため、第2のDoHサーバのIDを検証するための手順を設定したいことを第1のDoHサーバ92に示すために、DoH取得解決メッセージのヘッダ(またはDoH POSTメッセージの本文)に新しいオブジェクト(「リダイレクト認可失敗」)を挿入する。
【0220】
「リダイレクト認可失敗」オブジェクトを含むこのDoH取得(リダイレクト認証認可失敗)要求を受信した後、第1のDoHサーバ92は、第2の名前解決サーバの少なくとも1つの新しい識別子を生成する要求を認可サーバ93に送信し、第2の名前解決サーバに参加するための新しいアドレスを追加する手順を設定したいことを通知する。例えば、そのような要求は、新しい「AddressAdd」属性を含む「Accounting-Request」メッセージである。
【0221】
認可サーバ93は、第2の名前解決サーバの少なくとも1つの新しい識別子を生成する要求をネットワークコントローラに送信し、第2のDoHサーバがネットワーク(CPEなど)に対して定義されたデフォルトルータでホストされている場合、ネットワークコントローラはそれを正当な第2のDoHサーバに送信し、それ以外の場合はデフォルトルータに送信される。この要求を受信すると、デフォルトルータ(正当な第2のDoHサーバである可能性がある)は、少なくとも1つの新しいアドレス(特にDNSサービスにローカルで使用される)を生成し得る。
【0222】
特に、ネットワークコントローラは、このアドレスが識別された端末にのみ通知されるべきであることをデフォルトルータ(正当な第2のDoHサーバである可能性がある)に通知する。
【0223】
例えば、DNSサービスによって使用され、LAN上ではアナウンスされない第2のDoHサーバの新しい識別子の提供のための、認可サーバ93とネットワークコントローラとの間の交換は、YANGセマンティクスに従って初期化され得る。
【0224】
この目的で使用されるYANGモジュールの構造の例は付録に開示されている。
【0225】
このモジュールで説明されているように、1つまたは複数の新しい識別子(「新しいアドレス」)がデフォルトルータによって生成される場合がある。アクションの種類は「type」属性で示される。
【0226】
その後、新しい識別子がネットワークコントローラに送信され、ネットワークコントローラがそれらを認可サーバ93に送信する。例えば、図8に示すように、認可サーバ93とネットワークコントローラとの間の交換は、例えばNETCONFまたはRESTCONFプロトコルに従って、安全な通信チャネルで実装され得る。また、コントローラネットワークと第2のDoHサーバまたはデフォルトルータ間の交換は、例えばNETCONF、RESTCONF、またはTR-069プロトコルに従って安全な通信チャネルで実装され得る。
【0227】
新しいドメイン名AND'は、第2のDoHサーバに参加するために使用される新しい識別子(LOC')に関連付けられた第2のDoHサーバ用の認可サーバ93によって構成され得る。認証証明書が作成される可能性がある。他の情報(「URIテンプレート」など)も変更される場合がある。
【0228】
図9Aに示す第1の変形例によれば、第1のDoHサーバ92は、DoH取得(リダイレクト認可失敗)要求の受信に続いて、第2の名前解決サーバの少なくとも1つの新しい識別子の生成を求める「Accounting-Request」要求を認可サーバ93に送信する。
【0229】
また、第1のDoHサーバ92は、前述したように、「Access-Request」タイプのリダイレクト認可検証要求を認可サーバ93に送信する。
【0230】
認可サーバ93は、前述の「Access-Accept」タイプの応答で新しい情報(新しいドメイン名ADN'、第2のDoHサーバの新しい識別子LOC'など)を第1のDoHサーバ92に送信してもよい。
【0231】
図9Bに示す第2の変形例によれば、第1のDoHサーバ92は、DoH取得(リダイレクト認証認可失敗)要求を受信すると、前述した「Access-Request」タイプのリダイレクト認可検証要求を認可サーバ93に送信する。
【0232】
【0233】
次に、第1のDoHサーバ92は、第2の名前解決サーバの少なくとも1つの新しい識別子の生成を求める「アカウント要求」要求を認可サーバ93に送信することができる。
【0234】
認可サーバ93は、例えば認可変更要求(CoA、「認可変更」)において、新しい情報(ADN'、LOC'など)を第1のDoHサーバ92に送信することによって応答することができる。
【0235】
これらの交換が完了すると(第1または第2の変形、または第1のDoHサーバ92が新しい情報(ADN'、LOC'など)を取得できるようにする他の変形に従って)、新しいリダイレクト情報(AND'、LOC'など)は、例えばリダイレクトメッセージDoH REDIRECTで端末91に伝達される。
【0236】
新しいリダイレクト情報を端末91に通信するために第1のDoHサーバ92によって使用されるJSONオブジェクトの例を付録に示す。
【0237】
したがって、従来技術で与えられた例と比較すると、そのようなJSONオブジェクトは、第2のDoHサーバと通信するために使用される新しいアドレスを記述する。
【0238】
前述の例によれば、このリダイレクトメッセージを受信すると、端末91は、新しいドメイン名ADN'を使用して、第1のDoHサーバ92から受信した第2のDoHサーバの新しい識別子、すなわち新しいアドレス「192.0.2.5」または「2001:db8::5」を使用して名前解決要求を発信することができる。
【0239】
接続を確立するときに端末91で接続の問題が発生しなかった場合、それ以上のアクションは必要ない。
【0240】
そうでない場合、端末91は、オペレータのDNSサーバ(第1のDoHサーバ92)との接続を再確立し、(DNSトラフィックを第2のDoHサーバにリダイレクトするための)移行が失敗したことを第1のDoHサーバ92に示すことができる。
【0241】
特に、端末91は、トラフィックのローカルリダイレクトを無効化できる手順を設定することができる。
【0242】
したがって、実施形態に関係なく、端末は、例えば悪意のあるサーバの存在を検出した場合、および/または第2のDoHサーバとの認証/接続の問題を検出した場合、トラフィックのローカルリダイレクトを無効化できる手順を設定することができる。
【0243】
【0244】
例えば、端末101は、DoH取得解決メッセージに新しいオブジェクト(「rd-disable」)を挿入して、第1のDoHサーバ102にトラフィックのリダイレクトを無効化する手順を設定したいことを示す。このようなDoH取得要求はローカルでは処理されず、ネットワークによって提供される第1のDoHサーバによって処理されることに留意されたい。したがって、これらの交換は悪意のあるローカルサーバによって傍受されることはない。
【0245】
このDoH取得(rd-disable)要求を受信すると、第1のDoHサーバ102は認可サーバ103に連絡して、リダイレクトの無効化を進める前に認可を求めるか、または端末101のリダイレクトの無効化について通知する。
【0246】
図10Aに示す第1の変形例によれば、第1のDoHサーバ102は、無効化を進める前に、例えば「Access-Request」メッセージで認可サーバ103に認可を求める。
【0247】
認可サーバ103は、新しいSTATUS属性を含む「Access-Accept」タイプのメッセージを送信することによって応答することができる。
【0248】
図10Bに示される第2の変形によれば、第1のDoHサーバ102は、例えば「Accounting-Request」メッセージにおいて、端末101に対するトラフィックのリダイレクトの無効化について認可サーバ103に通知する。
【0249】
上述のさまざまな実施形態/変形例では、認可サーバ53、63、73、93、103はRADIUSサーバであってもよい。
【0250】
例えば、新しいRADIUS属性の形式は次のとおりである。
【0251】
【表1】
【0252】
正当な第2の名前解決サーバがローカルエリアネットワーク用に定義されたデフォルトルータ(CPEなど)である実装例を上で説明した。
【0253】
もちろん、これはほんの一例であるが、第2の名前解決サーバは、ローカルエリアネットワークの端末、キーなどに埋め込むことができ、デフォルトルータのIDと正当なDNSサーバ(特に第1の名前解決サーバ)のリストを使用してユーザが設定したローカルエリアネットワークにアクセスするための接続共有を可能にする可能性がある。
【0254】
さらに、上記の手順は、ローカルエリアネットワークのエンティティのユーザまたは管理者によって有効化/無効化される可能性があることに留意されたい。特に、有効化または無効化の要求メカニズムは、CPEの設定中、CPEの管理インターフェースへの接続中、オペレータによって送信された通知などを通じて実行される場合がある。
【0255】
さまざまなエンティティの簡略化された構造
最後に、図11を参照すると、上述の少なくとも1つの実施形態による、エンティティ、例えば、端末、第1の名前解決サーバ、第2の名前解決サーバ、認可サーバ、またはネットワークコントローラの簡略化された構造が示されている。
最後に、図11を参照すると、上述の少なくとも1つの実施形態による、エンティティ、例えば、端末、第1の名前解決サーバ、第2の名前解決サーバ、認可サーバ、またはネットワークコントローラの簡略化された構造が示されている。
【0256】
図11に示すように、このようなエンティティは、バッファメモリを含む少なくとも1つのメモリ111と、例えばプログラマブルコンピュータまたは専用コンピュータ、例えばプロセッサPを備え、コンピュータプログラム113によって制御される少なくとも1つの処理ユニット112とを備え、本発明の少なくとも1つの実施形態による少なくとも1つの方法のステップを実行する。
【0257】
初期化の際、コンピュータプログラム113のコード命令は、例えば、処理ユニット112のプロセッサによって実行される前にRAMメモリにロードされる。
【0258】
エンティティが端末である場合、処理ユニット112のプロセッサは、コンピュータプログラム113の命令に従って、前述の名前解決方法のステップを実行して、
前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して前記第1の名前解決サーバに名前解決メッセージを送信するステップと、
前記リダイレクトの第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第2の名前解決サーバへの前記端末の前記DNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップ、
前記DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行するステップと、
を実行する。
前記端末と第1の名前解決サーバとの間の安全な通信チャネルを介して前記第1の名前解決サーバに名前解決メッセージを送信するステップと、
前記リダイレクトの第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第2の名前解決サーバへの前記端末の前記DNSトラフィックの前記リダイレクトを管理するための、少なくとも、
前記第2の名前解決サーバの正当性を検証するステップ、
前記端末と前記第2の名前解決サーバとの接続の失敗の通知を送信するステップ、
前記DNSトラフィックの前記第2の名前解決サーバへの前記リダイレクトの無効化を要求するステップ、
のうち、少なくとも1つのアクションを実行するステップと、
を実行する。
【0259】
エンティティが第1の名前解決サーバである場合、処理ユニット112のプロセッサは、コンピュータプログラム113の命令に従って、端末に対して認可されたDNSトラフィックのリダイレクトを処理するための前述の方法のステップを実装し、
前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して前記端末から名前解決メッセージを受信するステップと、
認可サーバから、前記端末のリダイレクト認可と、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子とを取得するステップと、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信するステップと、
を実行する。
前記端末と前記第1の名前解決サーバとの間の安全な通信チャネルを介して前記端末から名前解決メッセージを受信するステップと、
認可サーバから、前記端末のリダイレクト認可と、前記リダイレクトのために前記端末用に識別された第2の名前解決サーバの少なくとも1つの識別子とを取得するステップと、
前記第2の名前解決サーバの少なくとも1つの識別子を持つリダイレクトメッセージを前記端末に送信するステップと、
を実行する。
【0260】
エンティティが第2の名前解決サーバである場合、処理ユニット112のプロセッサは、コンピュータプログラム113の命令に従って、端末に対して認可されたDNSトラフィックのリダイレクトを管理するための前述の方法のステップを実行し、
前記コントローラから前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換するステップ、
を実行する。
前記コントローラから前記第2の名前解決サーバに提供され、前記端末によって前記第2の名前解決サーバの正当性を検証するための少なくとも1つの情報、および/または、前記第2の名前解決サーバから前記コントローラに提供され、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のための少なくとも1つの情報、を含む情報を前記ネットワークのコントローラと交換するステップ、
を実行する。
【0261】
エンティティが認可サーバである場合、処理ユニット112のプロセッサは、コンピュータプログラム113の命令に従って、端末のDNSトラフィックのリダイレクトを認可するための前述の方法のステップを実行し、
前記リダイレクトのために前記端末に対して識別された第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第1の名前解決サーバに、前記端末に対するリダイレクト認可と、前記第2の名前解決サーバの少なくとも1つの識別子とを送信するステップと、
を実行する。
前記リダイレクトのために前記端末に対して識別された第2の名前解決サーバの少なくとも1つの識別子を取得するステップと、
前記第1の名前解決サーバに、前記端末に対するリダイレクト認可と、前記第2の名前解決サーバの少なくとも1つの識別子とを送信するステップと、
を実行する。
【0262】
エンティティがネットワークコントローラである場合、処理ユニット112のプロセッサは、コンピュータプログラム113の命令に従って、端末に対して認可されたDNSトラフィックのリダイレクトを制御するための前述の方法のステップを実行して、
前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために前記端末用に識別された第2の名前解決サーバとの間で、前記端末によって前記第2の名前解決サーバの前記正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換するステップ
を実行する。
前記端末の前記DNSトラフィックの前記認可されたリダイレクトのために前記端末用に識別された第2の名前解決サーバとの間で、前記端末によって前記第2の名前解決サーバの前記正当性を検証するために前記コントローラによって前記第2の名前解決サーバに提供される少なくとも1つの情報、および/または、前記端末と前記第2の名前解決サーバとの接続の失敗の解決のために前記第2の名前解決サーバによって前記コントローラに提供される少なくとも1つの情報、を含む情報を交換するステップ
を実行する。
【0263】
付録
オペレータのDOHサーバ32によって返されるJSONオブジェクトの例は次のとおりである。
オペレータのDOHサーバ32によって返されるJSONオブジェクトの例は次のとおりである。
【0264】
【表2】
【0265】
認可サーバ73およびネットワークコントローラが使用するYangモジュールのツリー構造の例は次のとおりである。
【0266】
【表3】
【0267】
検証情報を端末71に通知するために第1のDOHサーバ72で使用されるJSONオブジェクトの27の例は、次のとおりである。
【0268】
【表4】
【0269】
DNSサービスで使用される第2のDOHサーバの新しい識別子の供給のために、認可サーバ93とネットワークコントローラとの間の交換に使用される、LANで発表されていないYangモジュールの構造の例は次のとおりである。
【0270】
【表5】
【0271】
第1のDOHサーバ92が新しいリダイレクト情報を端末91に通知するために使用されるJSONオブジェクトの例は次のとおりである。
【0272】
【表6】
【符号の説明】
【0273】
11、21、31、41、51、61、71、91、101 端末
13 DNSサーバ
14、35、45 CPE
23 悪意のあるデバイスR
31 クライアント
32、42 DoHサーバ
33 DoH要求
34、44 リダイレクトメッセージ
36、37 DoHセッション
46 悪意のあるサーバ
52 第1の名前解決サーバ
53、63、93、103 認可サーバ
54、74 ネットワーク(コントローラ)
55 第2の名前解決サーバ
62、72、73、92、102 第1のDoHサーバ
75 第2のDoHサーバ
111 メモリ
112 処理ユニット
113 コンピュータプログラム
13 DNSサーバ
14、35、45 CPE
23 悪意のあるデバイスR
31 クライアント
32、42 DoHサーバ
33 DoH要求
34、44 リダイレクトメッセージ
36、37 DoHセッション
46 悪意のあるサーバ
52 第1の名前解決サーバ
53、63、93、103 認可サーバ
54、74 ネットワーク(コントローラ)
55 第2の名前解決サーバ
62、72、73、92、102 第1のDoHサーバ
75 第2のDoHサーバ
111 メモリ
112 処理ユニット
113 コンピュータプログラム
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図5C】
【図5D】
【図5E】
【図6】
【図7A】
【図7B】
【図8】
【図9A】
【図9B】
【図10A】
【図10B】
【図11】
【国際調査報告】