メインコンテンツまでスキップ

6.1. Discovery (発見)

6.1. Discovery (発見)​

DNS Push Notification サブスクリプションを確立する最初のステップは, 目的のゾーンに対して DNS Push Notifications をサポートする適切な DNS サーバーを発見することです。

クライアントは, 通常設定されている DNS 再帰リゾルバーへの DSO セッションを開き, Push Notification サブスクリプションを要求することから始めます。この接続は TCP ポート 853 に対して行われます。これは DNS over TLS [RFC7858] のデフォルトポートです。Push Notification サブスクリプションの要求が成功し, 再帰リゾルバーがその名前, タイプ, クラスに対してアクティブなサブスクリプションをまだ持っていない場合, 再帰リゾルバーはクライアントに代わって対応する Push Notification サブスクリプションを作成します。受信した結果はクライアントに中継されます。これは, クライアントが設定された DNS 再帰リゾルバーに通常の DNS クエリを送信する方法と非常に似ています。再帰リゾルバーのキャッシュに適切な回答がまだない場合, 要求を満たすために上流のクエリを発行します。

多くの文脈において, 再帰リゾルバーは, クライアントが追跡する必要があるすべての名前に対して Push Notifications を処理できます。VPN トンネルと Private DNS [RFC8499] の使用は, クライアントソフトウェアにいくつかの追加の複雑さを生み出す可能性があります; DNS Push Notifications のために VPN トンネルと Private DNS を処理する技術は, 通常の DNS クエリのためにこれを処理するためにすでに使用されているものと同じです。

再帰リゾルバーが DNS over TLS をサポートしていない場合, または DNS over TLS をサポートしているが TCP ポート 853 でリッスンしていない場合, または TCP ポート 853 で DNS over TLS をサポートしているがそのポートで DSO をサポートしていない場合, DSO セッション確立は失敗します [RFC8490]。

再帰リゾルバーが TCP ポート 853 で DSO をサポートしているが Push Notification サブスクリプションをサポートしていない場合, クライアントがサブスクリプションを作成しようとすると, サーバーは DSO エラーコード DSOTYPENI (11) を返します。

場合によっては, 再帰リゾルバーが DSO と Push Notification サブスクリプションをサポートしているが, 特定の名前に対して Push Notifications をサブスクライブできない可能性があります。この場合, 再帰リゾルバーはクライアントに SERVFAIL を返す必要があります。これには, ゾーンの DNS Push Notification サーバーへの接続を確立できない場合, または接続を確立したが非成功応答コードを受信した場合が含まれます。場合によっては, クライアントがゾーンの所有者と事前に確立された信頼関係を持っている場合 (VPN ソフトウェアの通常のメカニズムを介して処理されない), クライアントはゾーンの DNS Push Notification サーバーに直接連絡することによってこれらの失敗を処理できます。

上記のいずれかのケースで, クライアントが設定された再帰リゾルバーを介して DNS Push Notification サブスクリプションの確立に失敗した場合, クライアントは直接通信のための適切なサーバーを発見することを続ける必要があります。クライアントは, サーバーが接続をリッスンしている TCP ポートも決定しなければなりません。これは TCP ポート 53 (従来の DNS に伝統的に使用される) または TCP ポート 853 (DNS over TLS に伝統的に使用される) である必要はなく, 多くの場合そうではありません。

ここで説明する発見アルゴリズムは反復アルゴリズムであり, クライアントがサブスクライブしたいレコードの完全な名前から始まります。次に, 最も近い囲む権威サーバーが発見されるまで, 毎回 1 つのラベルをトリミングして連続した SOA クエリが発行されます。多くの場合, クライアントが最も近い囲む権威サーバーの SOA レコードに直接 "ショートカット" できるようにする最適化もあります。

  1. クライアントは, ローカルリゾルバーに DNS クエリを送信することによって発見を開始します。レコードタイプは SOA [RFC1035] で, サブスクライブしたいレコード名に対してです。例として, クライアントが "_ipp._tcp.headoffice.example.com" という名前の PTR レコードをサブスクライブしたい場合を考えます (Example Company の本社で宣伝されている Internet Printing Protocol (IPP) プリンター [RFC8010] [RFC8011] を発見するため)。クライアントは, ローカル再帰リゾルバーに "_ipp._tcp.headoffice.example.com" の SOA クエリを送信することから始めます。目標は, 名前 "_ipp._tcp.headoffice.example.com" に対して権威的なサーバーを決定することです。名前 "_ipp._tcp.headoffice.example.com" を含む最も近い囲む DNS ゾーンは, "example.com", "headoffice.example.com", "_tcp.headoffice.example.com", あるいは "_ipp._tcp.headoffice.example.com" である可能性があります。クライアントは, 最も近い囲むゾーンカットがどこで発生するかを事前に知りません。そのため, この情報を発見するためにここで説明する反復手順を使用します。

  2. 要求された SOA レコードが存在する場合, NOERROR 応答コードとともに Answer Section で返され, クライアントは必要な情報の発見に成功しました。(この言語は DNS 再帰リゾルバーに新しい要件を課すものではありません。このテキストは単に DNS プロトコル [RFC1034] [RFC1035] の既存の動作を説明しているだけです。)

  3. 要求された SOA レコードが存在しない場合, クライアントは NOERROR/NODATA 応答または NXDOMAIN/Name Error 応答を受け取ります。どちらの場合も, ローカルリゾルバーは通常, 要求された名前の最も近い囲むゾーンの SOA レコードを Authority Section に含めます。Authority Section で SOA レコードを受信した場合, クライアントは必要な情報の発見に成功しました。(この言語は DNS 再帰リゾルバーに新しい要件を課すものではありません。このテキストは単に否定応答に関する DNS プロトコルの既存の動作を説明しているだけです [RFC2308]。)

  4. クライアントが SOA レコードを含まない応答を受信した場合, 反復アプローチで続行します。クライアントは現在のクエリ名から先頭のラベルを削除し, 結果の名前に少なくとも 2 つのラベルがある場合, クライアントはその新しい名前の SOA クエリを送信し, 上記のステップ 2 で処理を続けます。SOA が受信されるか, クエリ名が単一のラベル, つまりトップレベルドメイン (TLD) で構成されるまで反復検索を繰り返します。単一ラベル名 (TLD) の場合, これはネットワーク構成エラーであり, 発生すべきではなく, クライアントは諦めます。クライアントは, ネットワーク接続の変更後など, クライアントが選択した後の時点で操作を再試行できます。

  5. SOA がわかったら (Answer Section または Authority Section のいずれかで見られることによって), クライアントはタイプ SRV [RFC2782] の DNS クエリを送信します。レコード名は "_dns-push-tls._tcp.<zone>" で, <zone> は発見された SOA レコードの所有者名です。

  6. 問題のゾーンが DNS Push Notifications を提供するように設定されている場合, この SRV レコードは存在しなければなりません。(この SRV レコードが存在しない場合, ゾーンはこのドキュメントで指定されているように DNS Push Notifications に対して正しく構成されていません。) SRV "target" には, ゾーンの DNS Push Notifications を提供するサーバーの名前が含まれます。サーバーに連絡するポート番号は SRV レコード "port" フィールドにあります。ターゲットホストのアドレスは Additional Section に含まれる場合がありますが, セクション 7.2 および DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records [RFC7673] の仕様で説明されているように, 使用前にアドレスレコードを認証する必要があります (該当する場合)。

  7. 複数の SRV レコードが返される場合があります。この場合, 返された SRV レコードの "priority" と "weight" 値を使用して, サブスクリプション要求のためにサーバーに連絡する順序を決定します。SRV 仕様 [RFC2782] で説明されているように, 最も低い "priority" を持つサーバーが最初に連絡されます。複数のサーバーが同じ "priority" を持っている場合, "weight" はクライアントがそのサーバーに連絡すべき加重確率を示します。より高いウェイトはより高い選択確率を持ちます。サーバーがサブスクリプション要求を受け入れることを望まない場合, またはクライアントが決定した合理的な時間内にアクセスできない場合, 後続のサーバーに連絡する必要があります。

クライアントが新しい DNS Push Notification サブスクリプションを作成するたびに, その時点でそのサブスクリプションの優先 DNS サーバーを決定するために発見プロセスを繰り返す必要があります。クライアントがその DNS サーバーとの DSO セッションをすでに持っている場合, クライアントは新しいサブスクリプションのためにその既存の DSO セッションを再利用する必要があります; そうでなければ, 新しい DSO セッションが確立されます。クライアントは, 発見プロセスの実行中に受信するレコードの DNS TTL 値を尊重し, この有効期間でローカルキャッシュに格納しなければなりません (実行するすべての DNS クエリに対して通常行うように)。これは, 権威レコードの DNS TTL 値が合理的な値に設定されている限り, ローカルに格納されたキャッシュデータのみを使用して, クライアントが実質的に瞬時に発見プロセスの繰り返し適用を完了できることを意味します。

に最終更新