RFC 8765 - DNS Push Notifications 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8765.html
タイトル : RFC 8765 - DNSプッシュ通知
翻訳編集 : 自動生成

[要約] RFC 8765は、DNSプッシュ通知の仕様を定義しており、DNSサーバーが変更を通知するためのメカニズムを提供します。目的は、DNSクライアントがリアルタイムでDNSレコードの変更を把握し、効率的なキャッシュ更新を実現することです。

Internet Engineering Task Force (IETF)                       T. Pusateri
Request for Comments: 8765                                  Unaffiliated
Category: Standards Track                                    S. Cheshire
ISSN: 2070-1721                                               Apple Inc.
                                                               June 2020

DNS Push Notifications

DNSプッシュ通知

Abstract

概要

The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.

ドメインネームシステム（DNS）は、比較的静的なデータのクエリに対して、一致するレコードを効率的に返すように設計されています。これらのレコードが頻繁に変更される場合でも、ポーリングレートが高すぎない限り、DNSはポーリング時に更新された結果を返すのに効率的です。ただし、これらの変更が発生したときにクライアントに非同期的に通知されるメカニズムはありません。このドキュメントでは、DNSプッシュ通知と呼ばれる、DNSレコードへのこのような変更が通知されるメカニズムをクライアントに定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8765.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8765で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
     1.2.  Fatal Errors
   2.  Motivation
   3.  Overview
   4.  State Considerations
   5.  Transport
   6.  Protocol Operation
     6.1.  Discovery
     6.2.  DNS Push Notification SUBSCRIBE
       6.2.1.  SUBSCRIBE Request
       6.2.2.  SUBSCRIBE Response
     6.3.  DNS Push Notification Updates
       6.3.1.  PUSH Message
     6.4.  DNS Push Notification UNSUBSCRIBE
       6.4.1.  UNSUBSCRIBE Message
     6.5.  DNS Push Notification RECONFIRM
       6.5.1.  RECONFIRM Message
     6.6.  DNS Stateful Operations TLV Context Summary
     6.7.  Client-Initiated Termination
     6.8.  Client Fallback to Polling
   7.  Security Considerations
     7.1.  Security Services
     7.2.  TLS Name Authentication
     7.3.  TLS Early Data
     7.4.  TLS Session Resumption
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

Domain Name System (DNS) records may be updated using DNS Update [RFC2136]. Other mechanisms such as a Discovery Proxy [RFC8766] can also generate changes to a DNS zone. This document specifies a protocol for DNS clients to subscribe to receive asynchronous notifications of changes to RRsets of interest. It is immediately relevant in the case of DNS-based Service Discovery [RFC6763] but is not limited to that use case; it provides a general DNS mechanism for DNS record change notifications. Familiarity with the DNS protocol and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895].

ドメインネームシステム（DNS）レコードは、DNSアップデート[RFC2136]を使用して更新できます。 Discovery Proxy [RFC8766]などの他のメカニズムもDNSゾーンに変更を生成できます。このドキュメントでは、関心のあるRRsetへの変更の非同期通知を受信するためにサブスクライブするDNSクライアントのプロトコルを指定します。これは、DNSベースのサービスディスカバリ[RFC6763]の場合にすぐに関連しますが、そのユースケースに限定されません。 DNSレコード変更通知用の一般的なDNSメカニズムを提供します。 DNSプロトコルとDNSパケット形式に精通していることを前提としています[RFC1034] [RFC1035] [RFC6895]。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

1.2. Fatal Errors

1.2. 致命的なエラー

Certain invalid situations are described in this specification, such as a server sending a Push Notification subscription request to a client, or a client sending a Push Notification response to a server. These should never occur with a correctly implemented client and server, and if they do occur, then they indicate a serious implementation error. In these extreme cases, there is no reasonable expectation of a graceful recovery, and the recipient detecting the error should respond by unilaterally aborting the session without regard for data loss. Such cases are addressed by having an engineer investigate the cause of the failure and fixing the problem in the software.

サーバーがクライアントにプッシュ通知サブスクリプション要求を送信したり、クライアントがサーバーにプッシュ通知応答を送信したりするなど、特定の無効な状況がこの仕様で説明されています。これらは、正しく実装されたクライアントとサーバーでは決して発生しないはずであり、発生した場合は、重大な実装エラーを示しています。これらの極端なケースでは、正常な回復の妥当な期待はなく、エラーを検出した受信者は、データの損失を考慮せずに一方的にセッションを中止することで対応する必要があります。このような場合は、エンジニアに障害の原因を調査させ、ソフトウェアの問題を修正することで対応します。

Where this specification says "forcibly abort", it means sending a TCP RST to terminate the TCP connection and the TLS session running over that TCP connection. In the BSD Sockets API, this is achieved by setting the SO_LINGER option to zero before closing the socket.

この仕様で「強制的に中止する」とは、TCP RSTを送信して、TCP接続とそのTCP接続で実行されているTLSセッションを終了することを意味します。 BSDソケットAPIでは、これは、ソケットを閉じる前にSO_LINGERオプションをゼロに設定することによって実現されます。

2. Motivation

2. 動機

As the domain name system continues to adapt to new uses and changes in deployment, polling has the potential to burden DNS servers at many levels throughout the network. Other network protocols have successfully deployed a publish/subscribe model following the Observer design pattern [OBS]. Extensible Messaging and Presence Protocol (XMPP) Publish-Subscribe [XEP0060] and Atom [RFC4287] are examples. While DNS servers are generally highly tuned and capable of a high rate of query/response traffic, adding a publish/subscribe model for tracking changes to DNS records can deliver more timely notifications of changes with reduced CPU usage and lower network traffic.

ドメインネームシステムが新しい用途や展開の変更に適応し続けているため、ポーリングはネットワーク全体のさまざまなレベルでDNSサーバーに負荷をかける可能性があります。他のネットワークプロトコルは、Observer設計パターン[OBS]に従ってパブリッシュ/サブスクライブモデルを正常に展開しています。 Extensible Messaging and Presence Protocol（XMPP）Publish-Subscribe [XEP0060]およびAtom [RFC4287]がその例です。 DNSサーバーは一般に高度に調整されており、クエリ/応答トラフィックを高速で処理できますが、DNSレコードへの変更を追跡するためのパブリッシュ/サブスクライブモデルを追加すると、CPU使用量が削減され、ネットワークトラフィックが減少するため、変更のタイムリーな通知を提供できます。

The guiding design principle of DNS Push Notifications is that clients that choose to use DNS Push Notifications, instead of repeated polling with DNS queries, will receive the same results as they could via sufficiently rapid polling, except more efficiently. This means that the rules for which records match a given DNS Push Notification subscription are the same as the already established rules used to determine which records match a given DNS query [RFC1034]. For example, name comparisons are done in a case-insensitive manner, and a record of type CNAME in a zone matches any DNS TYPE in a query or subscription.

DNSプッシュ通知の基本的な設計原則は、DNSクエリを使用してポーリングを繰り返す代わりに、DNSプッシュ通知を使用することを選択したクライアントが、より効率的な場合を除いて、十分に高速なポーリングを介した場合と同じ結果を受け取ることです。これは、レコードが特定のDNSプッシュ通知サブスクリプションに一致するルールは、特定のDNSクエリに一致するレコードを決定するために使用される既に確立されているルールと同じであることを意味します[RFC1034]。たとえば、名前の比較は大文字と小文字を区別しない方法で行われ、ゾーン内のタイプCNAMEのレコードは、クエリまたはサブスクリプション内のDNS TYPEと一致します。

Multicast DNS [RFC6762] implementations always listen on a well-known link-local IP multicast group address, and changes are sent to that multicast group address for all group members to receive. Therefore, Multicast DNS already has asynchronous change notification capability. When DNS-based Service Discovery [RFC6763] is used across a wide area network using Unicast DNS (possibly facilitated via a Discovery Proxy [RFC8766]), it would be beneficial to have an equivalent capability for Unicast DNS in order to allow clients to learn about DNS record changes in a timely manner without polling.

マルチキャストDNS [RFC6762]の実装は、既知のリンクローカルIPマルチキャストグループアドレスで常にリッスンし、すべてのグループメンバーが受信できるように、そのマルチキャストグループアドレスに変更が送信されます。したがって、マルチキャストDNSにはすでに非同期の変更通知機能があります。 DNSベースのサービスディスカバリ[RFC6763]がユニキャストDNS（ディスカバリープロキシ[RFC8766]を介して促進される可能性があります）を使用して広域ネットワーク全体で使用される場合、クライアントが学習できるようにするためにユニキャストDNSと同等の機能があると有益です。ポーリングなしでタイムリーにDNSレコードの変更について。

The DNS Long-Lived Queries (LLQ) mechanism [RFC8764] is an existing deployed solution to provide asynchronous change notifications; it was used by Apple's Back to My Mac [RFC6281] service introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was designed in an era when the data center operations staff asserted that it was impossible for a server to handle large numbers of TCP connections, even if those connections carried very little traffic and spent most of their time idle. Consequently, LLQ was defined as a UDP-based protocol, effectively replicating much of TCP's connection state management logic in user space and creating its own imitation of existing TCP features like flow control, reliability, and the three-way handshake.

DNS Long-Lived Queries（LLQ）メカニズム[RFC8764]は、非同期の変更通知を提供する既存の展開済みソリューションです。 2007年にMac OS X 10.5 Leopardで導入されたAppleのBack to My Mac [RFC6281]サービスで使用されました。Backto My Macは、サーバーが大量のサーバーを処理することは不可能であるとデータセンターの運用スタッフが主張した時代に設計されましたこれらの接続がほとんどトラフィックを伝送せず、ほとんどの時間をアイドル状態で費やしたとしても、TCP接続の数その結果、LLQはUDPベースのプロトコルとして定義され、TCPの接続状態管理ロジックの多くをユーザー空間で効果的に複製し、フロー制御、信頼性、3ウェイハンドシェイクなどの既存のTCP機能の独自の模倣を作成しました。

This document builds on experience gained with the LLQ protocol, with an improved design. Instead of using UDP, this specification uses DNS Stateful Operations (DSO) [RFC8490] running over TLS over TCP, and therefore doesn't need to reinvent existing TCP functionality. Using TCP also gives long-lived low-traffic connections better longevity through NAT gateways without depending on the gateway to support NAT Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control Protocol (PCP) [RFC6887], or resorting to excessive keepalive traffic.

このドキュメントは、改良された設計により、LLQプロトコルで得られた経験に基づいています。 UDPを使用する代わりに、この仕様はTCP上のTLSで実行されるDNSステートフルオペレーション（DSO）[RFC8490]を使用するため、既存のTCP機能を再発明する必要はありません。 TCPを使用すると、NATポートマッピングプロトコル（NAT-PMP）[RFC6886]またはポート制御プロトコル（PCP）[RFC6887]をサポートするゲートウェイに依存したり、過度に頼ったりすることなく、NATゲートウェイを介した長寿命の低トラフィック接続の寿命が長くなります。キープアライブトラフィック。

3. Overview

3. 概観

A DNS Push Notification client subscribes for Push Notifications for a particular RRset by connecting to the appropriate Push Notification server for that RRset and sending DSO message(s) indicating the RRset(s) of interest. When the client loses interest in receiving further updates to these records, it unsubscribes.

DNSプッシュ通知クライアントは、そのRRsetの適切なプッシュ通知サーバーに接続し、関心のあるRRsetを示すDSOメッセージを送信することにより、特定のRRsetのプッシュ通知をサブスクライブします。クライアントがこれらのレコードへのさらなる更新を受信することに興味を失うと、サブスクライブを解除します。

The DNS Push Notification server for a DNS zone is any server capable of generating the correct change notifications for a name. It may be a primary, secondary, or stealth name server [RFC8499].

DNSゾーンのDNSプッシュ通知サーバーは、名前の正しい変更通知を生成できるサーバーです。プライマリ、セカンダリ、またはステルスネームサーバーの場合があります[RFC8499]。

The "_dns-push-tls._tcp.<zone>" SRV record for a zone MAY reference the same target host and port as that zone's "_dns-update-tls._tcp.<zone>" SRV record. When the same target host and port is offered for both DNS Updates and DNS Push Notifications, a client MAY use a single DSO session to that server for both DNS Updates and DNS Push Notification subscriptions. DNS Updates and DNS Push Notifications may be handled on different ports on the same target host, in which case they are not considered to be the "same server" for the purposes of this specification, and communications with these two ports are handled independently. Supporting DNS Updates and DNS Push Notifications on the same server is OPTIONAL. A DNS Push Notification server is not required to support DNS Update.

ゾーンの「_dns-push-tls._tcp。<zone>」SRVレコードは、そのゾーンの「_dns-update-tls._tcp。<zone>」SRVレコードと同じターゲットホストおよびポートを参照する場合があります。 DNS更新とDNSプッシュ通知の両方に同じターゲットホストとポートが提供されている場合、クライアントは、DNS更新とDNSプッシュ通知サブスクリプションの両方に対して、そのサーバーへの単一のDSOセッションを使用できます（MAY）。 DNS更新とDNSプッシュ通知は、同じターゲットホストの異なるポートで処理される場合があります。その場合、この仕様では、これらは「同じサーバー」とは見なされず、これら2つのポートとの通信は独立して処理されます。同じサーバーでのDNS更新とDNSプッシュ通知のサポートはオプションです。 DNS更新をサポートするためにDNSプッシュ通知サーバーは必要ありません。

Standard DNS Queries MAY be sent over a DNS Push Notification (i.e., DSO) session. For any zone for which the server is authoritative, it MUST respond authoritatively for queries for names falling within that zone (e.g., the "_dns-push-tls._tcp.<zone>" SRV record) both for normal DNS queries and for DNS Push Notification subscriptions. For names for which the server is acting as a recursive resolver (e.g., when the server is the local recursive resolver) for any query for which it supports DNS Push Notification subscriptions, it MUST also support standard queries.

標準のDNSクエリは、DNSプッシュ通知（つまり、DSO）セッションで送信できます（MAY）。サーバーが信頼できるすべてのゾーンについて、通常のDNSクエリとDNSの両方で、そのゾーンに含まれる名前のクエリ（たとえば、「_ dns-push-tls._tcp。<zone>」SRVレコード）に対して信頼できるように応答する必要があります。プッシュ通知サブスクリプション。サーバーがDNSプッシュ通知サブスクリプションをサポートするクエリに対して、サーバーが再帰リゾルバーとして機能している（たとえば、サーバーがローカルの再帰リゾルバーである）場合は、標準クエリもサポートする必要があります。

DNS Push Notifications impose less load on the responding server than rapid polling would, but Push Notifications do still have a cost. Therefore, DNS Push Notification clients MUST NOT recklessly create an excessive number of Push Notification subscriptions. Specifically:

DNSプッシュ通知は、迅速なポーリングよりも応答サーバーにかかる負荷が少なくなりますが、プッシュ通知にはコストがかかります。したがって、DNSプッシュ通知クライアントは、無謀に過剰な数のプッシュ通知サブスクリプションを作成してはなりません。具体的には：

(a) A subscription should only be active when there is a valid reason to need live data (for example, an on-screen display is currently showing the results to the user), and the subscription SHOULD be canceled as soon as the need for that data ends (for example, when the user dismisses that display). In the case of a device like a smartphone that, after some period of inactivity, goes to sleep or otherwise darkens its screen, it should cancel its subscriptions when darkening the screen (since the user cannot see any changes on the display anyway) and reinstate its subscriptions when reawakening from display sleep.

（a）サブスクリプションは、ライブデータを必要とする正当な理由がある場合にのみアクティブにする必要があります（たとえば、現在画面に表示されている結果がユーザーに表示されている場合など）。サブスクリプションは、必要に応じてキャンセルする必要があります（SHOULD）そのデータは終了します（たとえば、ユーザーがその表示を閉じたとき）。スマートフォンのように、一定期間使用しないとスリープ状態になるか、画面が暗くなるようなデバイスの場合、画面を暗くするとサブスクリプションをキャンセルし（ユーザーは何も変更をディスプレイに表示できないため）、再開します。ディスプレイのスリープから復帰したときのサブスクリプション。

(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS Push Notification subscription active 24 hours a day, 7 days a week, just to keep a list in memory up to date so that if the user does choose to bring up an on-screen display of that data, it can be displayed really fast. DNS Push Notifications are designed to be fast enough that there is no need to pre-load a "warm" list in memory just in case it might be needed later.

（b）DNSプッシュ通知クライアントは、DNSプッシュ通知サブスクリプションを24時間年中無休でアクティブに維持しないでください。ユーザーがオンにすることを選択した場合に備えて、メモリ内のリストを最新の状態に保つためです。 -そのデータの画面表示、それは本当に速く表示することができます。 DNSプッシュ通知は、後で必要になる場合に備えて、「ウォーム」リストをメモリに事前にロードする必要がないように、十分に高速になるように設計されています。

Generally, as described in the DNS Stateful Operations specification [RFC8490], a client must not keep a DSO session to a server open indefinitely if it has no subscriptions (or other operations) active on that session. A client should begin closing a DSO session immediately after it becomes idle, and then, if needed in the future, open a new session when required. Alternatively, a client may speculatively keep an idle DSO session open for some time, subject to the constraint that it must not keep a session open that has been idle for more than the session's idle timeout (15 seconds by default) [RFC8490].

一般に、DNSステートフルオペレーション仕様[RFC8490]で説明されているように、クライアントは、そのセッションでアクティブなサブスクリプション（または他のオペレーション）がない場合、サーバーへのDSOセッションを無期限に開いたままにしてはなりません。クライアントは、アイドルになった直後にDSOセッションを閉じ始め、その後、必要に応じて、必要に応じて新しいセッションを開く必要があります。または、クライアントは、セッションのアイドルタイムアウト（デフォルトでは15秒）[RFC8490]を超えてアイドル状態になっているセッションを開いたままにしてはならないという制約に従って、アイドルDSOセッションをしばらく開いたままにしておくこともできます。

Note that a DSO session that has an active DNS Push Notification subscription is not considered idle, even if there is no traffic flowing for an extended period of time. In this case, the DSO inactivity timeout does not apply, because the session is not inactive, but the keepalive interval does still apply, to ensure the generation of sufficient messages to maintain state in middleboxes (such at NAT gateways or firewalls) and for the client and server to periodically verify that they still have connectivity to each other. This is described in Section 6.2 of the DSO specification [RFC8490].

アクティブなDNSプッシュ通知サブスクリプションを持つDSOセッションは、長時間にわたってトラフィックが流れていなくても、アイドルとは見なされないことに注意してください。この場合、DSO非アクティブタイムアウトは適用されません。これは、セッションが非アクティブではないためですが、キープアライブインターバルは引き続き適用され、ミドルボックス（NATゲートウェイやファイアウォールなど）の状態を維持するのに十分なメッセージを生成します。クライアントとサーバーが定期的に相互に接続していることを確認します。これは、DSO仕様[RFC8490]のセクション6.2で説明されています。

4. State Considerations

4. 州の考慮事項

Each DNS Push Notification server is capable of handling some finite number of Push Notification subscriptions. This number will vary from server to server and is based on physical machine characteristics, network capacity, and operating system resource allocation. After a client establishes a session to a DNS server, each subscription is individually accepted or rejected. Servers may employ various techniques to limit subscriptions to a manageable level. Correspondingly, the client is free to establish simultaneous sessions to alternate DNS servers that support DNS Push Notifications for the zone and distribute subscriptions at the client's discretion. In this way, both clients and servers can react to resource constraints.

各DNSプッシュ通知サーバーは、いくつかの有限数のプッシュ通知サブスクリプションを処理できます。この数はサーバーによって異なり、物理マシンの特性、ネットワーク容量、およびオペレーティングシステムのリソース割り当てに基づいています。クライアントがDNSサーバーへのセッションを確立した後、各サブスクリプションは個別に受け入れまたは拒否されます。サーバーは、サブスクリプションを管理可能なレベルに制限するために、さまざまな手法を使用できます。同様に、クライアントは、ゾーンのDNSプッシュ通知をサポートする代替DNSサーバーへの同時セッションを自由に確立し、クライアントの裁量でサブスクリプションを配布できます。このようにして、クライアントとサーバーの両方がリソースの制約に対応できます。

5. Transport

5. 輸送

Other DNS operations like DNS Update [RFC2136] MAY use either DNS over User Datagram Protocol (UDP) [RFC0768] or DNS over Transmission Control Protocol (TCP) [RFC0793] as the transport protocol, provided they follow the historical precedent that DNS queries must first be sent using DNS over UDP and only switch to DNS over TCP if needed [RFC1123]. This requirement to prefer UDP has subsequently been relaxed [RFC7766].

DNS更新[RFC2136]のような他のDNS操作は、DNSクエリが必要とする歴史的な前例に従う限り、DNS over User Datagram Protocol（UDP）[RFC0768]またはDNS over Transmission Control Protocol（TCP）[RFC0793]をトランスポートプロトコルとして使用する場合があります。最初にDNS over UDPを使用して送信され、必要な場合にのみDNS over TCPに切り替えます[RFC1123]。 UDPを優先するこの要件はその後緩和されました[RFC7766]。

In keeping with the more recent precedent, DNS Push Notification is defined only for TCP. DNS Push Notification clients MUST use DNS Stateful Operations [RFC8490] running over TLS over TCP [RFC7858].

最近の前例に従って、DNSプッシュ通知はTCPに対してのみ定義されています。 DNSプッシュ通知クライアントは、TLS over TCP [RFC7858]で実行されるDNSステートフル操作[RFC8490]を使用する必要があります。

Connection setup over TCP ensures return reachability and alleviates concerns of state overload at the server, a potential problem with connectionless protocols, which can be more vulnerable to being exploited by attackers using spoofed source addresses. All subscribers are guaranteed to be reachable by the server by virtue of the TCP three-way handshake. Flooding attacks are possible with any protocol, and a benefit of TCP is that there are already established industry best practices to guard against SYN flooding and similar attacks [SYN] [RFC4953].

TCPを介した接続設定により、戻り到達可能性が保証され、サーバーでの状態過負荷の懸念が緩和されます。これは、接続のないプロトコルの潜在的な問題であり、なりすましの送信元アドレスを使用する攻撃者に悪用される可能性が高くなります。すべてのサブスクライバーは、TCP 3ウェイハンドシェイクによってサーバーから到達可能であることが保証されています。フラッディング攻撃はどのプロトコルでも可能であり、TCPの利点は、SYNフラッディングおよび同様の攻撃[SYN] [RFC4953]から保護するための業界のベストプラクティスがすでに確立されていることです。

Use of TCP also allows DNS Push Notifications to take advantage of current and future developments in TCP such as Multipath TCP (MPTCP) [RFC8684], TCP Fast Open (TFO) [RFC7413], the TCP RACK fast loss detection algorithm [TCPRACK], and so on.

TCPを使用すると、DNSプッシュ通知で、マルチパスTCP（MPTCP）[RFC8684]、TCP高速オープン（TFO）[RFC7413]、TCP RACK高速損失検出アルゴリズム[TCPRACK]など、TCPの現在および将来の開発を利用できます。等々。

Transport Layer Security (TLS) [RFC8446] is well understood and is used by many application-layer protocols running over TCP. TLS is designed to prevent eavesdropping, tampering, and message forgery. TLS is REQUIRED for every connection between a client subscriber and server in this protocol specification. Additional security measures such as client authentication during TLS negotiation may also be employed to increase the trust relationship between client and server.

トランスポート層セキュリティ（TLS）[RFC8446]はよく理解されており、TCPで実行される多くのアプリケーション層プロトコルで使用されています。 TLSは、盗聴、改ざん、およびメッセージの偽造を防ぐように設計されています。このプロトコル仕様では、クライアントサブスクライバーとサーバー間のすべての接続にTLSが必要です。 TLSネゴシエーション中のクライアント認証などの追加のセキュリティ対策を採用して、クライアントとサーバー間の信頼関係を強化することもできます。

6. Protocol Operation

6. プロトコル操作

The DNS Push Notification protocol is a session-oriented protocol and makes use of DNS Stateful Operations (DSO) [RFC8490].

DNSプッシュ通知プロトコルはセッション指向のプロトコルであり、DNSステートフルオペレーション（DSO）[RFC8490]を利用しています。

For details of the DSO message format, refer to the DNS Stateful Operations specification [RFC8490]. Those details are not repeated here.

DSOメッセージフォーマットの詳細については、DNSステートフルオペレーション仕様[RFC8490]を参照してください。これらの詳細はここでは繰り返されません。

DNS Push Notification clients and servers MUST support DSO. A single server can support DNS Queries, DNS Updates, and DNS Push Notifications (using DSO) on the same TCP port.

DNSプッシュ通知のクライアントとサーバーはDSOをサポートする必要があります。単一のサーバーは、同じTCPポートでDNSクエリ、DNS更新、およびDNSプッシュ通知（DSOを使用）をサポートできます。

A DNS Push Notification exchange begins with the client discovering the appropriate server, using the procedure described in Section 6.1, and then making a TLS/TCP connection to it.

DNSプッシュ通知の交換は、クライアントがセクション6.1で説明されている手順を使用して適切なサーバーを検出し、次にTLS / TCP接続を確立することから始まります。

After making the TLS/TCP connection to the server, a typical DNS Push Notification client will then immediately issue a DSO Keepalive operation to establish the DSO session and request a session timeout and/or keepalive interval longer than the 15-second default values, but this is not required. A DNS Push Notification client MAY issue other requests on the session first, and only issue a DSO Keepalive operation later if it determines that to be necessary. Sending either a DSO Keepalive operation or a Push Notification subscription request over the TLS/TCP connection to the server signals the client's support of DSO and serves to establish a DSO session.

サーバーへのTLS / TCP接続を確立した後、通常のDNSプッシュ通知クライアントはすぐにDSOキープアライブ操作を発行してDSOセッションを確立し、15秒のデフォルト値より長いセッションタイムアウトやキープアライブ間隔を要求しますが、これは必須ではありません。 DNSプッシュ通知クライアントは、最初にセッションで他のリクエストを発行し、必要であると判断した場合にのみDSOキープアライブ操作を発行します。 DSOキープアライブ操作またはプッシュ通知サブスクリプション要求のいずれかをTLS / TCP接続経由でサーバーに送信すると、クライアントによるDSOのサポートが通知され、DSOセッションの確立に役立ちます。

In accordance with the current set of active subscriptions, the server sends relevant asynchronous Push Notifications to the client. Note that a client MUST be prepared to receive (and silently ignore) Push Notifications for subscriptions it has previously removed, since there is no way to prevent the situation where a Push Notification is in flight from server to client while the client's UNSUBSCRIBE message canceling that subscription is simultaneously in flight from client to server.

アクティブなサブスクリプションの現在のセットに従って、サーバーは関連する非同期プッシュ通知をクライアントに送信します。クライアントは、以前に削除したサブスクリプションのプッシュ通知を受信する（そして黙って無視する）準備をしなければならないことに注意してください。クライアントのUNSUBSCRIBEメッセージがそれをキャンセルしている間に、プッシュ通知がサーバーからクライアントに送信されている状況を防ぐ方法はないからです。サブスクリプションは、クライアントからサーバーへ同時に進行中です。

6.1. Discovery

6.1. 発見

The first step in establishing a DNS Push Notification subscription is to discover an appropriate DNS server that supports DNS Push Notifications for the desired zone.

DNSプッシュ通知サブスクリプションを確立する最初のステップは、目的のゾーンのDNSプッシュ通知をサポートする適切なDNSサーバーを発見することです。

The client begins by opening a DSO session to its normal configured DNS recursive resolver and requesting a Push Notification subscription. This connection is made to TCP port 853, the default port for DNS over TLS [RFC7858]. If the request for a Push Notification subscription is successful, and the recursive resolver doesn't already have an active subscription for that name, type, and class, then the recursive resolver will make a corresponding Push Notification subscription on the client's behalf. Results received are relayed to the client. This is closely analogous to how a client sends a normal DNS query to its configured DNS recursive resolver, which, if it doesn't already have appropriate answer(s) in its cache, issues an upstream query to satisfy the request.

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

In many contexts, the recursive resolver will be able to handle Push Notifications for all names that the client may need to follow. Use of VPN tunnels and Private DNS [RFC8499] can create some additional complexity in the client software here; the techniques to handle VPN tunnels and Private DNS for DNS Push Notifications are the same as those already used to handle this for normal DNS queries.

多くのコンテキストでは、再帰リゾルバは、クライアントが従う必要があるすべての名前のプッシュ通知を処理できます。 VPNトンネルとプライベートDNS [RFC8499]を使用すると、ここでクライアントソフトウェアがさらに複雑になる可能性があります。 DNSプッシュ通知でVPNトンネルとプライベートDNSを処理する手法は、通常のDNSクエリでこれを処理するためにすでに使用されている手法と同じです。

If the recursive resolver does not support DNS over TLS, or supports DNS over TLS but is not listening on TCP port 853, or supports DNS over TLS on TCP port 853 but does not support DSO on that port, then the DSO session establishment will fail [RFC8490].

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

If the recursive resolver does support DSO on TCP port 853 but does not support Push Notification subscriptions, then when the client attempts to create a subscription, the server will return the DSO error code DSOTYPENI (11).

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

In some cases, the recursive resolver may support DSO and Push Notification subscriptions but may not be able to subscribe for Push Notifications for a particular name. In this case, the recursive resolver should return SERVFAIL to the client. This includes being unable to establish a connection to the zone's DNS Push Notification server or establishing a connection but receiving a non-success response code. In some cases, where the client has a pre-established trust relationship with the owner of the zone (that is not handled via the usual mechanisms for VPN software), the client may handle these failures by contacting the zone's DNS Push Notification server directly.

場合によっては、再帰リゾルバーはDSOとプッシュ通知のサブスクリプションをサポートしますが、特定の名前のプッシュ通知をサブスクライブできない場合があります。この場合、再帰リゾルバはSERVFAILをクライアントに返す必要があります。これには、ゾーンのDNSプッシュ通知サーバーへの接続を確立できなかったり、接続を確立したが失敗した応答コードを受け取ったりすることが含まれます。場合によっては、クライアントがゾーンの所有者と事前に確立した信頼関係（VPNソフトウェアの通常のメカニズムでは処理されない）を持っている場合、クライアントはゾーンのDNSプッシュ通知サーバーに直接接続してこれらの障害を処理することがあります。

In any of the cases described above where the client fails to establish a DNS Push Notification subscription via its configured recursive resolver, the client should proceed to discover the appropriate server for direct communication. The client MUST also determine on which TCP port the server is listening for connections, which need not be, and often is not, TCP port 53 (traditionally used for conventional DNS) or TCP port 853 (traditionally used for DNS over TLS).

クライアントが、構成された再帰リゾルバを介してDNSプッシュ通知サブスクリプションの確立に失敗した上記のいずれの場合でも、クライアントは、直接通信に適したサーバーの検出に進む必要があります。クライアントはまた、サーバーが接続をリッスンしているTCPポートを決定する必要があります。これは、TCPポート53（従来のDNSに従来使用されていた）またはTCPポート853（従来のDNS over TLSに使用されていた）である必要はありません。

The discovery algorithm described here is an iterative algorithm, which starts with the full name of the record to which the client wishes to subscribe. Successive SOA queries are then issued, trimming one label each time, until the closest enclosing authoritative server is discovered. There is also an optimization to enable the client to take a "short cut" directly to the SOA record of the closest enclosing authoritative server in many cases.

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

1. The client begins the discovery by sending a DNS query to its local resolver, with record type SOA [RFC1035] for the record name to which it wishes to subscribe. As an example, suppose the client wishes to subscribe to PTR records with the name "_ipp._tcp.headoffice.example.com" (to discover Internet Printing Protocol (IPP) printers [RFC8010] [RFC8011] being advertised in the head office of Example Company). The client begins by sending an SOA query for "_ipp._tcp.headoffice.example.com" to the local recursive resolver. The goal is to determine the server that is authoritative for the name "_ipp._tcp.headoffice.example.com". The closest enclosing DNS zone containing the name "_ipp._tcp.headoffice.example.com" could be "example.com", or "headoffice.example.com", or "_tcp.headoffice.example.com", or even "_ipp._tcp.headoffice.example.com". The client does not know in advance where the closest enclosing zone cut occurs, which is why it uses the iterative procedure described here to discover this information.

1. クライアントは、サブスクライブするレコード名のレコードタイプSOA [RFC1035]を使用して、ローカルリゾルバーにDNSクエリを送信することで、検出を開始します。例として、クライアントが "_ipp._tcp.headoffice.example.com"という名前のPTRレコードにサブスクライブすることを望んでいるとします（インターネット印刷プロトコル（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. If the requested SOA record exists, it will be returned in the Answer Section with a NOERROR response code, and the client has succeeded in discovering the information it needs.

2. 要求されたSOAレコードが存在する場合は、NOERROR応答コードとともにAnswerセクションに返され、クライアントは必要な情報の発見に成功しました。

(This language is not placing any new requirements on DNS recursive resolvers. This text merely describes the existing operation of the DNS protocol [RFC1034] [RFC1035].)

（この言語は、DNS再帰リゾルバに新しい要件を課していません。このテキストは、DNSプロトコル[RFC1034] [RFC1035]の既存の操作を説明するだけです。）

3. If the requested SOA record does not exist, the client will get back a NOERROR/NODATA response or an NXDOMAIN/Name Error response. In either case, the local resolver would normally include the SOA record for the closest enclosing zone of the requested name in the Authority Section. If the SOA record is received in the Authority Section, then the client has succeeded in discovering the information it needs.

3. 要求されたSOAレコードが存在しない場合、クライアントはNOERROR / NODATA応答またはNXDOMAIN / Name Error応答を返します。どちらの場合でも、ローカルリゾルバーは通常、要求された名前の最も近い囲みゾーンのSOAレコードを権限セクションに含めます。権限セクションでSOAレコードが受信された場合、クライアントは必要な情報の発見に成功しています。

(This language is not placing any new requirements on DNS recursive resolvers. This text merely describes the existing operation of the DNS protocol regarding negative responses [RFC2308].)

（この言語は、DNS再帰リゾルバーに新しい要件を課していません。このテキストは、否定応答に関するDNSプロトコルの既存の操作を説明しているだけです[RFC2308]。）

4. If the client receives a response containing no SOA record, then it proceeds with the iterative approach. The client strips the leading label from the current query name, and if the resulting name has at least two labels in it, then the client sends an SOA query for that new name and processing continues at step 2 above, repeating the iterative search until either an SOA is received or the query name consists of a single label, i.e., a Top-Level Domain (TLD). In the case of a single-label name (TLD), this is a network configuration error, which should not happen, and the client gives up. The client may retry the operation at a later time of the client's choosing, such as after a change in network attachment.

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

5. Once the SOA is known (by virtue of being seen either in the Answer Section or in the Authority Section), the client sends a DNS query with type SRV [RFC2782] for the record name "_dns-push-tls._tcp.<zone>", where <zone> is the owner name of the discovered SOA record.

5. SOAが判明すると（回答セクションまたは権限セクションに表示されるため）、クライアントはレコード名 "_dns-push-tls._tcp。<zoneについてタイプSRV [RFC2782]のDNSクエリを送信します> "、ここで<zone>は、検出されたSOAレコードの所有者名です。

6. If the zone in question is set up to offer DNS Push Notifications, then this SRV record MUST exist. (If this SRV record does not exist, then the zone is not correctly configured for DNS Push Notifications as specified in this document.) The SRV "target" contains the name of the server providing DNS Push Notifications for the zone. The port number on which to contact the server is in the SRV record "port" field. The address(es) of the target host MAY be included in the Additional Section, however, the address records SHOULD be authenticated before use as described in Section 7.2 and in the specification for using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records [RFC7673], if applicable.

6. 問題のゾーンがDNSプッシュ通知を提供するように設定されている場合、このSRVレコードが存在する必要があります。（このSRVレコードが存在しない場合、このドキュメントで指定されているように、ゾーンはDNSプッシュ通知用に正しく構成されていません。）SRV "ターゲット"には、ゾーンのDNSプッシュ通知を提供するサーバーの名前が含まれます。サーバーに接続するポート番号は、SRVレコードの「ポート」フィールドにあります。ターゲットホストのアドレスは追加セクションに含めることができますが、アドレスレコードは、セクション7.2および名前付きエンティティのDNSベース認証（DANE）TLSAレコードを使用するための仕様で説明されているように、使用前に認証する必要があります（SHOULD）。 SRVレコード[RFC7673]（該当する場合）。

7. More than one SRV record may be returned. In this case, the "priority" and "weight" values in the returned SRV records are used to determine the order in which to contact the servers for subscription requests. As described in the SRV specification [RFC2782], the server with the lowest "priority" is first contacted. If more than one server has the same "priority", the "weight" indicates the weighted probability that the client should contact that server. Higher weights have higher probabilities of being selected. If a server is not willing to accept a subscription request, or is not reachable within a reasonable time, as determined by the client, then a subsequent server is to be contacted.

7. 複数のSRVレコードが返される場合があります。この場合、返されたSRVレコードの「優先度」と「重み」の値を使用して、サブスクリプション要求についてサーバーに接続する順序を決定します。 SRV仕様[RFC2782]で説明されているように、最も低い「優先度」を持つサーバーが最初に接続されます。複数のサーバーが同じ「優先度」を持っている場合、「重み」は、クライアントがそのサーバーに接続する必要がある重み付けされた確率を示します。重みが大きいほど、選択される確率が高くなります。サーバーがサブスクリプション要求を受け入れる意思がない場合、またはクライアントが決定した妥当な時間内に到達できない場合は、後続のサーバーに連絡します。

Each time a client makes a new DNS Push Notification subscription, it SHOULD repeat the discovery process in order to determine the preferred DNS server for that subscription at that time. If a client already has a DSO session with that DNS server, the client SHOULD reuse that existing DSO session for the new subscription; otherwise, a new DSO session is established. The client MUST respect the DNS TTL values on records it receives while performing the discovery process and store them in its local cache with this lifetime (as it will generally do anyway for all DNS queries it performs). This means that, as long as the DNS TTL values on the authoritative records are set to reasonable values, repeated application of the discovery process can be completed practically instantaneously by the client, using only locally stored cached data.

クライアントが新しいDNSプッシュ通知サブスクリプションを作成するたびに、そのサブスクリプションの優先DNSサーバーを決定するために、その時点で検出プロセスを繰り返す必要があります。クライアントが既にそのDNSサーバーとのDSOセッションを持っている場合、クライアントは新しいサブスクリプションのためにその既存のDSOセッションを再利用する必要があります（SHOULD）。それ以外の場合は、新しいDSOセッションが確立されます。クライアントは、ディスカバリプロセスの実行中に受信したレコードのDNS TTL値を尊重し、このライフタイムでローカルキャッシュにそれらを保存する必要があります（通常、実行するすべてのDNSクエリに対してそうです）。つまり、信頼できるレコードのDNS TTL値が適切な値に設定されている限り、ローカルに保存されたキャッシュデータのみを使用して、発見プロセスの繰り返し適用をクライアントが事実上即座に完了できます。

6.2. DNSプッシュ通知サブスクライブ

After connecting, and requesting a longer idle timeout and/or keepalive interval if necessary, a DNS Push Notification client then indicates its desire to receive DNS Push Notifications for a given domain name by sending a SUBSCRIBE request to the server. A SUBSCRIBE request is encoded in a DSO message [RFC8490]. This specification defines a DSO Primary TLV for DNS Push Notification SUBSCRIBE Requests (DSO Type Code 0x0040).

接続し、必要に応じてより長いアイドルタイムアウトまたはキープアライブ間隔を要求した後、DNSプッシュ通知クライアントは、サーバーにSUBSCRIBE要求を送信することにより、特定のドメイン名のDNSプッシュ通知を受信したいという希望を示します。 SUBSCRIBEリクエストはDSOメッセージ[RFC8490]にエンコードされています。この仕様では、DNSプッシュ通知のSUBSCRIBEリクエスト（DSOタイプコード0x0040）のDSOプライマリTLVを定義しています。

DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted in TLS early data, provided that the precautions described in Section 7.3 are followed.

7.3で説明されている予防措置が講じられている場合、プライマリTLVとしてSUBSCRIBE TLVを含むDSOメッセージは、TLS初期データで許可されます。

The entity that initiates a SUBSCRIBE request is by definition the client. A server MUST NOT send a SUBSCRIBE request over an existing session from a client. If a server does send a SUBSCRIBE request over a DSO session initiated by a client, this is a fatal error and the client MUST forcibly abort the connection immediately.

SUBSCRIBEリクエストを開始するエンティティは、定義上クライアントです。サーバーは、クライアントからの既存のセッションでSUBSCRIBEリクエストを送信してはなりません（MUST NOT）。サーバーがクライアントによって開始されたDSOセッションを介してSUBSCRIBE要求を送信する場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。

Each SUBSCRIBE request generates exactly one SUBSCRIBE response from the server. The entity that initiates a SUBSCRIBE response is by definition the server. A client MUST NOT send a SUBSCRIBE response. If a client does send a SUBSCRIBE response, this is a fatal error and the server MUST forcibly abort the connection immediately.

各SUBSCRIBE要求は、サーバーから正確に1つのSUBSCRIBE応答を生成します。 SUBSCRIBE応答を開始するエンティティは、定義上、サーバーです。クライアントはSUBSCRIBE応答を送信してはいけません。クライアントがSUBSCRIBE応答を送信する場合、これは致命的なエラーであり、サーバーは接続を直ちに強制的に中止する必要があります。

6.2.1. SUBSCRIBEリクエスト

A SUBSCRIBE request begins with the standard DSO 12-byte header [RFC8490], followed by the SUBSCRIBE Primary TLV. A SUBSCRIBE request is illustrated in Figure 1.

SUBSCRIBE要求は、標準のDSO 12バイトヘッダー[RFC8490]で始まり、その後にSUBSCRIBEプライマリTLVが続きます。 SUBSCRIBEリクエストを図1に示します。

The MESSAGE ID field MUST be set to a unique value that the client is not using for any other active operation on this DSO session. For the purposes here, a MESSAGE ID is in use on this session if either the client has used it in a request for which it has not yet received a response, or if the client has used it for a subscription that it has not yet canceled using UNSUBSCRIBE. In the SUBSCRIBE response, the server MUST echo back the MESSAGE ID value unchanged.

MESSAGE IDフィールドは、クライアントがこのDSOセッションの他のアクティブな操作に使用していない一意の値に設定する必要があります。ここでの目的のために、クライアントが応答をまだ受け取っていない要求でそれを使用した場合、またはクライアントがまだキャンセルしていないサブスクリプションにそれを使用した場合、このセッションでメッセージIDが使用されます。 UNSUBSCRIBEを使用します。 SUBSCRIBE応答では、サーバーはMESSAGE ID値を変更せずにエコーバックする必要があります。

The other header fields MUST be set as described in the DSO specification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields must be zero, and the corresponding four sections must be empty (i.e., absent).

その他のヘッダーフィールドは、DSO仕様[RFC8490]の説明に従って設定する必要があります。 DNS OPCODEフィールドには、DNSステートフル操作（6）のOPCODE値が含まれています。 4つのカウントフィールドはゼロでなければならず、対応する4つのセクションは空である（つまり、存在しない）必要があります。

The DSO-TYPE is SUBSCRIBE (0x0040).

DSO-TYPEはSUBSCRIBE（0x0040）です。

The DSO-LENGTH is the length of the DSO-DATA that follows, which specifies the name, type, and class of the record(s) being sought.

DSO-LENGTHは、後続のDSO-DATAの長さであり、検索されるレコードの名前、タイプ、およびクラスを指定します。

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |                  MESSAGE ID                   |   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |QR| OPCODE(6) |         Z          |   RCODE   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             QDCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > HEADER
      |             ANCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             NSCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             ARCOUNT (MUST BE ZERO)            |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /
      |         DSO-TYPE = SUBSCRIBE (0x0040)         |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |   DSO-LENGTH (number of octets in DSO-DATA)   |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      \                     NAME                      \   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                     TYPE                      |     > DSO-DATA
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                     CLASS                     |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /

Figure 1: SUBSCRIBE Request

図1：SUBSCRIBEリクエスト

The DSO-DATA for a SUBSCRIBE request MUST contain exactly one NAME, TYPE, and CLASS. Since SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE DSO request messages can be concatenated in a single TCP stream and packed efficiently into TCP segments.

SUBSCRIBEリクエストのDSO-DATAには、NAME、TYPE、およびCLASSを1つだけ含める必要があります。 SUBSCRIBE要求はTCP経由で送信されるため、複数のSUBSCRIBE DSO要求メッセージを単一のTCPストリームに連結し、効率的にTCPセグメントにパックできます。

If accepted, the subscription will stay in effect until the client cancels the subscription using UNSUBSCRIBE or until the DSO session between the client and the server is closed.

承認された場合、サブスクリプションは、クライアントがUNSUBSCRIBEを使用してサブスクリプションをキャンセルするか、クライアントとサーバー間のDSOセッションが閉じられるまで有効です。

SUBSCRIBE requests on a given session MUST be unique. A client MUST NOT send a SUBSCRIBE message that duplicates the name, type and class of an existing active subscription on that DSO session. For the purpose of this matching, the established DNS case insensitivity for US-ASCII letters [RFC0020] applies (e.g., "example.com" and "Example.com" are the same). If a server receives such a duplicate SUBSCRIBE message, this is a fatal error and the server MUST forcibly abort the connection immediately.

特定のセッションでのSUBSCRIBEリクエストは一意である必要があります。クライアントは、そのDSOセッションで既存のアクティブなサブスクリプションの名前、タイプ、およびクラスを複製するSUBSCRIBEメッセージを送信してはなりません（MUST NOT）。この照合の目的で、US-ASCII文字[RFC0020]に対して確立されたDNSの大文字小文字の区別が適用されます（たとえば、「example.com」と「Example.com」は同じです）。サーバーがそのような重複したSUBSCRIBEメッセージを受信した場合、これは致命的なエラーであり、サーバーは接続をただちに強制的に中止する必要があります。

DNS wildcarding is not supported. That is, an asterisk character ("*") in a SUBSCRIBE message matches only a literal asterisk character ("*") in a name and nothing else. Similarly, a CNAME in a SUBSCRIBE message matches only a CNAME record with that name in the zone and no other records with that name.

DNSワイルドカードはサポートされていません。つまり、SUBSCRIBEメッセージのアスタリスク文字（ "*"）は、名前のリテラルアスタリスク文字（ "*"）のみに一致し、それ以外には一致しません。同様に、SUBSCRIBEメッセージ内のCNAMEは、ゾーン内のその名前を持つCNAMEレコードのみに一致し、その名前を持つ他のレコードには一致しません。

A client may SUBSCRIBE to records that are unknown to the server at the time of the request (providing that the name falls within one of the zone(s) the server is responsible for), and this is not an error. The server MUST NOT return NXDOMAIN in this case. The server MUST accept these requests and send Push Notifications if and when matching records are found in the future.

クライアントは、リクエスト時にサーバーに認識されていないレコードにサブスクライブすることができ（名前がサーバーが担当するゾーンの1つに該当する場合）、これはエラーではありません。この場合、サーバーはNXDOMAINを返してはなりません。一致するレコードが将来見つかった場合、サーバーはこれらの要求を受け入れ、プッシュ通知を送信する必要があります。

If neither TYPE nor CLASS are ANY (255), then this is a specific subscription to changes for the given name, type, and class. If one or both of TYPE or CLASS are ANY (255), then this subscription matches all types and/or all classes as appropriate.

TYPEもCLASSもANY（255）でない場合、これは指定された名前、タイプ、およびクラスの変更に対する特定のサブスクリプションです。 TYPEまたはCLASSの一方または両方がANY（255）の場合、このサブスクリプションは、すべてのタイプまたはすべてのクラス、あるいはその両方と適切に一致します。

NOTE: A little-known quirk of DNS is that in DNS QUERY requests, QTYPE and QCLASS 255 mean "ANY", not "ALL". They indicate that the server should respond with ANY matching records of its choosing, not necessarily ALL matching records. This can lead to some surprising and unexpected results, where a query returns some valid answers, but not all of them, and makes QTYPE = 255 (ANY) queries less useful than people sometimes imagine.

注：DNSのあまり知られていない癖は、DNS QUERY要求で、QTYPEおよびQCLASS 255が「ALL」ではなく「ANY」を意味することです。それらは、サーバーが必ずしもすべての一致するレコードではなく、選択した任意の一致するレコードで応答する必要があることを示します。これにより、いくつかの驚くべき予期しない結果が生じる可能性があります。クエリはいくつかの有効な回答を返しますが、すべての回答を返すわけではなく、QTYPE = 255（ANY）クエリは、人々が想像するよりも役に立たなくなります。

When used in conjunction with SUBSCRIBE, TYPE 255 and CLASS 255 should be interpreted to mean "ALL", not "ANY". After accepting a subscription where one or both of TYPE or CLASS are 255, the server MUST send Push Notification Updates for ALL record changes that match the subscription, not just some of them.

SUBSCRIBEと組み合わせて使用する場合、TYPE 255およびCLASS 255は、「ANY」ではなく「ALL」を意味するものとして解釈されます。 TYPEまたはCLASSのいずれかまたは両方が255であるサブスクリプションを受け入れた後、サーバーは、それらの一部だけではなく、サブスクリプションに一致するすべてのレコード変更のプッシュ通知更新を送信する必要があります。

6.2.2. SUBSCRIBEレスポンス

A SUBSCRIBE response begins with the standard DSO 12-byte header [RFC8490]. The QR bit in the header is set indicating it is a response. The header MAY be followed by one or more optional Additional TLVs such as a Retry Delay Additional TLV. A SUBSCRIBE response is illustrated in Figure 2.

SUBSCRIBE応答は、標準のDSO 12バイトヘッダー[RFC8490]で始まります。ヘッダーのQRビットが設定され、応答であることを示します。ヘッダーの後には、再試行遅延追加TLVなどの1つ以上のオプションの追加TLVが続く場合があります。 SUBSCRIBE応答を図2に示します。

The MESSAGE ID field MUST echo the value given in the MESSAGE ID field of the SUBSCRIBE request. This is how the client knows which request is being responded to.

MESSAGE IDフィールドは、SUBSCRIBEリクエストのMESSAGE IDフィールドで指定された値をエコーする必要があります。これは、クライアントがどの要求に応答しているかを知る方法です。

A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a client receives a SUBSCRIBE response message containing a SUBSCRIBE TLV, then the response message is processed but the SUBSCRIBE TLV MUST be silently ignored.

SUBSCRIBE応答メッセージには、SUBSCRIBE TLVを含めることはできません。クライアントがSUBSCRIBE TLVを含むSUBSCRIBE応答メッセージを受信した場合、応答メッセージは処理されますが、SUBSCRIBE TLVは黙って無視されなければなりません（MUST）。

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |                  MESSAGE ID                   |   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |QR| OPCODE(6) |         Z          |   RCODE   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             QDCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > HEADER
      |             ANCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             NSCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             ARCOUNT (MUST BE ZERO)            |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /

Figure 2: SUBSCRIBE Response

図2：SUBSCRIBEレスポンス

In the SUBSCRIBE response, the RCODE indicates whether or not the subscription was accepted. Supported RCODEs are as follows:

SUBSCRIBE応答のRCODEは、サブスクリプションが受け入れられたかどうかを示します。サポートされるRCODEは次のとおりです。

         +-----------+-------+-----------------------------------+
         | Mnemonic  | Value | Description                       |
         +===========+=======+===================================+
         | NOERROR   |   0   | SUBSCRIBE successful.             |
         +-----------+-------+-----------------------------------+
         | FORMERR   |   1   | Server failed to process request  |
         |           |       | due to a malformed request.       |
         +-----------+-------+-----------------------------------+
         | SERVFAIL  |   2   | Server failed to process request  |
         |           |       | due to a problem with the server. |
         +-----------+-------+-----------------------------------+
         | NOTIMP    |   4   | Server does not implement DSO.    |
         +-----------+-------+-----------------------------------+
         | REFUSED   |   5   | Server refuses to process request |
         |           |       | for policy or security reasons.   |
         +-----------+-------+-----------------------------------+
         | NOTAUTH   |   9   | Server is not authoritative for   |
         |           |       | the requested name.               |
         +-----------+-------+-----------------------------------+
         | DSOTYPENI |   11  | SUBSCRIBE operation not           |
         |           |       | supported.                        |
         +-----------+-------+-----------------------------------+

Table 1: SUBSCRIBE Response Codes

表1：SUBSCRIBE応答コード

This document specifies only these RCODE values for SUBSCRIBE Responses. Servers sending SUBSCRIBE Responses SHOULD use one of these values. Note that NXDOMAIN is not a valid RCODE in response to a SUBSCRIBE Request. However, future circumstances may create situations where other RCODE values are appropriate in SUBSCRIBE Responses, so clients MUST be prepared to accept and handle SUBSCRIBE Responses with any other nonzero RCODE error values.

このドキュメントでは、SUBSCRIBE応答に対してこれらのRCODE値のみを指定しています。 SUBSCRIBE応答を送信するサーバーは、これらの値のいずれかを使用する必要があります（SHOULD）。 NXDOMAINは、SUBSCRIBEリクエストへの応答では有効なRCODEではないことに注意してください。ただし、将来の状況により、SUBSCRIBE応答で他のRCODE値が適切である状況が発生する可能性があるため、クライアントは、他のゼロ以外のRCODEエラー値を含むSUBSCRIBE応答を受け入れて処理する準備をする必要があります。

If the server sends a nonzero RCODE in the SUBSCRIBE response, that means:

サーバーがSUBSCRIBE応答でゼロ以外のRCODEを送信する場合、それは次のことを意味します。

a. the client is (at least partially) misconfigured, or b. the server resources are exhausted, or c. there is some other unknown failure on the server.

a. クライアントが（少なくとも部分的に）正しく構成されていない、またはb。サーバーリソースが使い果たされている、またはc。サーバーに他の不明な障害があります。

In any case, the client shouldn't retry the subscription to this server right away. If multiple SRV records were returned as described in Section 6.1, Paragraph 9, Item 7, a subsequent server MAY be tried immediately.

いずれにしても、クライアントはこのサーバーへのサブスクリプションをすぐに再試行しないでください。セクション6.1、パラグラフ9、アイテム7で説明されているように複数のSRVレコードが返された場合、後続のサーバーがすぐに試行される場合があります。

If the client has other successful subscriptions to this server, these subscriptions remain even though additional subscriptions may be refused. Neither the client nor the server is required to close the connection, although either end may choose to do so.

クライアントがこのサーバーへの他の正常なサブスクリプションを持っている場合、追加のサブスクリプションが拒否される場合でも、これらのサブスクリプションは残ります。クライアントとサーバーのどちらも接続を閉じる必要はありませんが、どちらの側でも閉じることができます。

If the server sends a nonzero RCODE, then it SHOULD append a Retry Delay Additional TLV [RFC8490] to the response specifying a delay before the client attempts this operation again. Recommended values for the delay for different RCODE values are given below. These recommended values apply both to the default values a server should place in the Retry Delay Additional TLV and the default values a client should assume if the server provides no Retry Delay Additional TLV.

サーバーがゼロ以外のRCODEを送信する場合、クライアントはこの操作を再試行する前に、遅延を指定して再試行遅延追加TLV [RFC8490]を応答に追加する必要があります（SHOULD）。さまざまなRCODE値の遅延の推奨値を以下に示します。これらの推奨値は、サーバーがRetry Delay Additional TLVに配置するデフォルト値と、サーバーがRetry Delay Additional TLVを提供しない場合にクライアントが想定するデフォルト値の両方に適用されます。

For RCODE = 1 (FORMERR), the delay may be any value selected by the implementer. A value of five minutes is RECOMMENDED to reduce the risk of high load from defective clients.

RCODE = 1（FORMERR）の場合、遅延は実装者が選択した任意の値になります。欠陥のあるクライアントからの高負荷のリスクを減らすために、5分の値をお勧めします。

For RCODE = 2 (SERVFAIL), the delay should be chosen according to the level of server overload and the anticipated duration of that overload. By default, a value of one minute is RECOMMENDED. If a more serious server failure occurs, the delay may be longer in accordance with the specific problem encountered.

RCODE = 2（SERVFAIL）の場合、サーバーの過負荷のレベルとその過負荷の予想される期間に応じて遅延を選択する必要があります。デフォルトでは、1分の値が推奨されます。より深刻なサーバー障害が発生した場合、発生した特定の問題に応じて、遅延が長くなることがあります。

For RCODE = 4 (NOTIMP), which occurs on a server that doesn't implement DNS Stateful Operations [RFC8490], it is unlikely that the server will begin supporting DSO in the next few minutes, so the retry delay SHOULD be one hour. Note that in such a case, a server that doesn't implement DSO is unlikely to place a Retry Delay Additional TLV in its response, so this recommended value in particular applies to what a client should assume by default.

DNSステートフル操作[RFC8490]を実装していないサーバーで発生するRCODE = 4（NOTIMP）の場合、サーバーが数分以内にDSOのサポートを開始する可能性は低いため、再試行遅延は1時間にする必要があります（SHOULD）。このような場合、DSOを実装していないサーバーがその応答にRetry Delay Additional TLVを配置する可能性は低いため、この推奨値は特に、クライアントがデフォルトで想定するものに適用されます。

For RCODE = 5 (REFUSED), which occurs on a server that implements DNS Push Notifications but is currently configured to disallow DNS Push Notifications, the retry delay may be any value selected by the implementer and/or configured by the operator.

DNSプッシュ通知を実装しているがDNSプッシュ通知を許可しないように現在構成されているサーバーで発生するRCODE = 5（REFUSED）の場合、再試行遅延は、実装者が選択した値、またはオペレーターが設定した値のいずれかになります。

If the server being queried is listed in a "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is a misconfiguration, since this server is being advertised as supporting DNS Push Notifications for this zone, but the server itself is not currently configured to perform that task. Since it is possible that the misconfiguration may be repaired at any time, the retry delay should not be set too high. By default, a value of 5 minutes is RECOMMENDED.

クエリ対象のサーバーがゾーンの "_dns-push-tls._tcp。<zone>" SRVレコードにリストされている場合、このサーバーはこのゾーンのDNSプッシュ通知をサポートするものとしてアドバタイズされているため、これは構成の誤りですが、サーバー自体は現在、そのタスクを実行するように構成されていません。誤った構成はいつでも修復される可能性があるため、再試行の遅延をあまり長く設定しないでください。デフォルトでは、5分の値が推奨されています。

For RCODE = 9 (NOTAUTH), which occurs on a server that implements DNS Push Notifications but is not configured to be authoritative for the requested name, the retry delay may be any value selected by the implementer and/or configured by the operator.

DNSプッシュ通知を実装するサーバーで発生するRCODE = 9（NOTAUTH）の場合、要求された名前に対して権限を持つように構成されていない場合、再試行遅延は、実装者が選択した値、またはオペレーターが構成した値のいずれかになります。

For RCODE = 11 (DSOTYPENI), which occurs on a server that implements DSO but doesn't implement DNS Push Notifications, it is unlikely that the server will begin supporting DNS Push Notifications in the next few minutes, so the retry delay SHOULD be one hour.

DSOを実装しているがDNSプッシュ通知を実装していないサーバーで発生するRCODE = 11（DSOTYPENI）の場合、サーバーが数分以内にDNSプッシュ通知のサポートを開始する可能性は低いため、再試行遅延は1にする必要があります（SHOULD）時間。

For other RCODE values, the retry delay should be set by the server as appropriate for that error condition. By default, a value of 5 minutes is RECOMMENDED.

他のRCODE値の場合、再試行遅延は、そのエラー条件に応じてサーバーによって設定される必要があります。デフォルトでは、5分の値が推奨されています。

For RCODE = 9 (NOTAUTH), the time delay applies to requests for other names falling within the same zone. Requests for names falling within other zones are not subject to the delay. For all other RCODEs, the time delay applies to all subsequent requests to this server.

RCODE = 9（NOTAUTH）の場合、時間遅延は、同じゾーン内にある他の名前の要求に適用されます。他のゾーンに含まれる名前のリクエストは遅延の影響を受けません。他のすべてのRCODEの場合、時間遅延はこのサーバーへの後続のすべての要求に適用されます。

After sending an error response, the server MAY allow the session to remain open, or MAY follow it with a DSO Retry Delay operation (using the Retry Delay Primary TLV) instructing the client to close the session as described in the DSO specification [RFC8490]. Clients MUST correctly handle both cases. Note that the DSO Retry Delay operation (using the Retry Delay Primary TLV) is different to the Retry Delay Additional TLV mentioned above.

エラー応答を送信した後、サーバーはセッションを開いたままにするか、DSO仕様に記載されているようにクライアントにセッションを閉じるように指示するDSO再試行遅延操作（再試行遅延プライマリTLVを使用）を続けることができます[RFC8490] 。クライアントは両方のケースを正しく処理する必要があります。 DSO再試行遅延操作（再試行遅延プライマリTLVを使用）は、上記の再試行遅延追加TLVとは異なることに注意してください。

6.3. DNS Push Notification Updates

6.3. DNSプッシュ通知の更新

Once a subscription has been successfully established, the server generates PUSH messages to send to the client as appropriate. In the case that the answer set was already non-empty at the moment the subscription was established, an initial PUSH message will be sent immediately following the SUBSCRIBE Response. Subsequent changes to the answer set are then communicated to the client in subsequent PUSH messages.

サブスクリプションが正常に確立されると、サーバーは必要に応じてクライアントに送信するPUSHメッセージを生成します。サブスクリプションが確立された時点で回答セットがすでに空でなかった場合、最初のPUSHメッセージがSUBSCRIBE応答の直後に送信されます。応答セットに対するその後の変更は、後続のPUSHメッセージでクライアントに通知されます。

A client MUST NOT send a PUSH message. If a client does send a PUSH message, or a PUSH message is sent with the QR bit set indicating that it is a response, this is a fatal error and the receiver MUST forcibly abort the connection immediately.

クライアントはPUSHメッセージを送信してはいけません。クライアントがPUSHメッセージを送信する場合、またはQRビットが設定されたPUSHメッセージが送信され、それが応答であることを示す場合、これは致命的なエラーであり、受信者は接続を直ちに強制的に中止する必要があります。

6.3.1. PUSH Message

6.3.1. PUSHメッセージ

A PUSH unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the PUSH Primary TLV. A PUSH message is illustrated in Figure 3.

PUSH単方向メッセージは、標準のDSO 12バイトヘッダー[RFC8490]で始まり、その後にPUSH Primary TLVが続きます。 PUSHメッセージを図3に示します。

In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no client response to a PUSH message.

DSO単方向メッセージの定義に従って、MESSAGE IDフィールドはゼロでなければなりません。 PUSHメッセージに対するクライアントの応答はありません。

The DSO-TYPE is PUSH (0x0041).

DSO-TYPEはPUSH（0x0041）です。

The DSO-LENGTH is the length of the DSO-DATA that follows, which specifies the changes being communicated.

DSO-LENGTHは、後続のDSO-DATAの長さであり、通信される変更を指定します。

The DSO-DATA contains one or more change notifications. A PUSH Message MUST contain at least one change notification. If a PUSH Message is received that contains no change notifications, this is a fatal error and the client MUST forcibly abort the connection immediately.

DSO-DATAには、1つ以上の変更通知が含まれています。 PUSHメッセージには、少なくとも1つの変更通知が含まれている必要があります。変更通知を含まないPUSHメッセージを受信した場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。

The change notification records are formatted similarly to how DNS Resource Records are conventionally expressed in DNS messages, as illustrated in Figure 3, and are interpreted as described below.

変更通知レコードは、図3に示すように、DNSリソースレコードが従来のDNSメッセージで表現される方法と同様にフォーマットされ、以下のように解釈されます。

The TTL field holds an unsigned 32-bit integer [RFC2181]. If the TTL is in the range 0 to 2,147,483,647 seconds (0 to 2^(31) - 1, or 0x7FFFFFFF), then a new DNS Resource Record with the given name, type, class, and RDATA is added. Type and class MUST NOT be 255 (ANY). If either type or class are 255 (ANY), this is a fatal error and the client MUST forcibly abort the connection immediately. A TTL of 0 means that this record should be retained for as long as the subscription is active and should be discarded immediately the moment the subscription is canceled.

TTLフィールドは、符号なし32ビット整数[RFC2181]を保持します。 TTLの範囲が0〜2,147,483,647秒（0〜2 ^（31）-1、または0x7FFFFFFF）の場合、指定された名前、タイプ、クラス、およびRDATAを持つ新しいDNSリソースレコードが追加されます。タイプとクラスは255（すべて）であってはなりません。タイプまたはクラスが255（すべて）の場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。 TTLが0の場合、このレコードはサブスクリプションがアクティブである限り保持され、サブスクリプションがキャンセルされた瞬間に破棄されることを意味します。

If the TTL has the value 0xFFFFFFFF, then the DNS Resource Record with the given name, type, class, and RDATA is removed. Type and class MUST NOT be 255 (ANY). If either type or class are 255 (ANY), this is a fatal error and the client MUST forcibly abort the connection immediately.

TTLの値が0xFFFFFFFFの場合、指定された名前、タイプ、クラス、およびRDATAのDNSリソースレコードが削除されます。タイプとクラスは255（すべて）であってはなりません。タイプまたはクラスが255（すべて）の場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。

If the TTL has the value 0xFFFFFFFE, then this is a 'collective' remove notification. For collective remove notifications, RDLEN MUST be zero, and consequently, the RDATA MUST be empty. If a change notification is received where TTL = 0xFFFFFFFE and RDLEN is not zero, this is a fatal error and the client MUST forcibly abort the connection immediately.

TTLの値が0xFFFFFFFEの場合、これは「一括」削除通知です。一括削除通知の場合、RDLENはゼロである必要があり、その結果、RDATAは空である必要があります。 TTL = 0xFFFFFFFEでRDLENがゼロでない場合に変更通知を受信すると、これは致命的なエラーであり、クライアントは直ちに接続を強制的に中止する必要があります。

There are three types of collective remove notification. For collective remove notifications:

一括削除通知には3つのタイプがあります。一括削除通知の場合：

* If CLASS is not 255 (ANY) and TYPE is not 255 (ANY), then for the given name, this removes all records of the specified type in the specified class.

* CLASSが255（ANY）でなく、TYPEが255（ANY）でない場合、指定された名前について、指定されたクラスの指定されたタイプのすべてのレコードが削除されます。

* If CLASS is not 255 (ANY) and TYPE is 255 (ANY), then for the given name, this removes all records of all types in the specified class.

* CLASSが255（ANY）ではなく、TYPEが255（ANY）の場合、指定された名前について、指定されたクラスのすべてのタイプのすべてのレコードが削除されます。

* If CLASS is 255 (ANY), then for the given name, this removes all records of all types in all classes. In this case, TYPE MUST be set to zero on transmission and MUST be silently ignored on reception.

* CLASSが255（ANY）の場合、指定された名前について、すべてのクラスのすべてのタイプのすべてのレコードが削除されます。この場合、TYPEは送信時にゼロに設定する必要があり、受信時には暗黙的に無視する必要があります。

Summary of change notification types:

変更通知タイプの要約：

* Remove all RRsets from a name in all classes: TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY).

* すべてのクラスの名前からすべてのRRsetを削除します：TTL = 0xFFFFFFFE、RDLEN = 0、CLASS = 255（すべて）。

* Remove all RRsets from a name in given class: TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255 (ANY).

* 指定されたクラスの名前からすべてのRRsetを削除します：TTL = 0xFFFFFFFE、RDLEN = 0、CLASSはクラスを提供し、TYPE = 255（すべて）。

* Remove specified RRset from a name in given class: TTL = 0xFFFFFFFE, RDLEN = 0, CLASS and TYPE specify the RRset being removed.

* 指定されたクラスの名前から指定されたRRsetを削除します：TTL = 0xFFFFFFFE、RDLEN = 0、CLASSおよびTYPEは削除されるRRsetを指定します。

* Remove an individual RR from a name: TTL = 0xFFFFFFFF, CLASS, TYPE, RDLEN, and RDATA specify the RR being removed.

* 名前から個々のRRを削除します。TTL= 0xFFFFFFFF、CLASS、TYPE、RDLEN、およびRDATAは、削除するRRを指定します。

* Add individual RR to a name: TTL >= 0 and TTL <= 0x7FFFFFFF, CLASS, TYPE, RDLEN, RDATA, and TTL specify the RR being added.

* 個々のRRを名前に追加します。TTL> = 0およびTTL <= 0x7FFFFFFF、CLASS、TYPE、RDLEN、RDATA、およびTTLは、追加されるRRを指定します。

Note that it is valid for the RDATA of an added or removed DNS Resource Record to be empty (zero length). For example, an Address Prefix List Resource Record [RFC3123] may have empty RDATA. Therefore, a change notification with RDLEN = 0 does not automatically indicate a remove notification. If RDLEN = 0 and TTL is in the range 0 to 0x7FFFFFFF, this change notification signals the addition of a record with the given name, type, class, and empty RDATA. If RDLEN = 0 and TTL = 0xFFFFFFFF, this change notification signals the removal specifically of that single record with the given name, type, class, and empty RDATA.

追加または削除されたDNSリソースレコードのRDATAが空（長さが0）であることは有効であることに注意してください。たとえば、アドレスプレフィックスリストリソースレコード[RFC3123]には空のRDATAがある場合があります。したがって、RDLEN = 0の変更通知は、削除通知を自動的に示しません。 RDLEN = 0で、TTLが0〜0x7FFFFFFFの範囲にある場合、この変更通知は、指定された名前、タイプ、クラス、および空のRDATAを持つレコードの追加を通知します。 RDLEN = 0およびTTL = 0xFFFFFFFFの場合、この変更通知は、特定の名前、タイプ、クラス、および空のRDATAを持つその単一レコードの削除を具体的に通知します。

If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value in the range 0 to 0x7FFFFFFF, then the receiver SHOULD silently ignore this particular change notification record. The connection is not terminated and other valid change notification records within this PUSH message are processed as usual.

TTLが0xFFFFFFFF、0xFFFFFFFE、または0〜0x7FFFFFFFの範囲以外の値である場合、受信者はこの特定の変更通知レコードを黙って無視する必要があります（SHOULD）。接続は終了せず、このPUSHメッセージ内の他の有効な変更通知レコードは通常どおり処理されます。

In the case where a single change affects more than one active subscription, only one PUSH message is sent. For example, a PUSH message adding a given record may match both a SUBSCRIBE request with the same TYPE and a different SUBSCRIBE request with TYPE = 255 (ANY). It is not the case that two PUSH messages are sent because the new record matches two active subscriptions.

1つの変更が複数のアクティブなサブスクリプションに影響を与える場合、1つのPUSHメッセージのみが送信されます。たとえば、特定のレコードを追加するPUSHメッセージは、同じTYPEのSUBSCRIBEリクエストと、TYPE = 255（ANY）の異なるSUBSCRIBEリクエストの両方に一致する場合があります。新しいレコードが2つのアクティブなサブスクリプションと一致するため、2つのPUSHメッセージが送信されるわけではありません。

The server SHOULD encode change notifications in the most efficient manner possible. For example, when three AAAA records are removed from a given name, and no other AAAA records exist for that name, the server SHOULD send a "Remove specified RRset from a name in given class" PUSH message, not three separate "Remove an individual RR from a name" PUSH messages. Similarly, when both an SRV and a TXT record are removed from a given name, and no other records of any kind exist for that name in that class, the server SHOULD send a "Remove all RRsets from a name in given class" PUSH message, not two separate "Remove specified RRset from a name in given class" PUSH messages.

サーバーは、可能な限り最も効率的な方法で変更通知をエンコードする必要があります（SHOULD）。たとえば、特定の名前から3つのAAAAレコードが削除され、その名前に他のAAAAレコードが存在しない場合、サーバーは3つの個別の「個別の削除RR from a name "PUSHメッセージ。同様に、SRVレコードとTXTレコードの両方が指定された名前から削除され、そのクラスにその名前の他の種類のレコードが存在しない場合、サーバーは「指定されたクラスの名前からすべてのRRsetを削除する」PUSHメッセージを送信する必要があります、2つの別々の「指定されたクラスの名前から指定されたRRsetを削除する」PUSHメッセージではありません。

For efficiency, when generating a PUSH message, rather than sending each change notification as a separate DSO message, a server SHOULD include as many change notifications as it has immediately available to send to that client, even if those change notifications apply to different subscriptions from that client. Conceptually, a PUSH message is a session-level mechanism, not a subscription-level mechanism. Once it has exhausted the list of change notifications immediately available to send to that client, a server SHOULD then send the PUSH message immediately rather than waiting speculatively to see if additional change notifications become available.

効率を上げるために、PUSHメッセージを生成するとき、各変更通知を個別のDSOメッセージとして送信するのではなく、サーバーは、変更通知が異なるサブスクリプションに適用される場合でも、そのクライアントにすぐに送信できる限り多くの変更通知を含める必要があります（SHOULD）。そのクライアント。概念的には、PUSHメッセージはセッションレベルのメカニズムであり、サブスクリプションレベルのメカニズムではありません。そのクライアントにすぐに送信できる変更通知のリストを使い果たしたら、サーバーは、追加の変更通知が使用可能になるかどうかを推測するのではなく、PUSHメッセージをすぐに送信する必要があります（SHOULD）。

For efficiency, when generating a PUSH message a server SHOULD use standard DNS name compression, with offsets relative to the beginning of the DNS message [RFC1035]. When multiple change notifications in a single PUSH message have the same owner name, this name compression can yield significant savings. Name compression should be performed as specified in Section 18.14 of the Multicast DNS specification [RFC6762]; namely, owner names should always be compressed, and names appearing within RDATA should be compressed for only the RR types listed below:

効率を上げるために、PUSHメッセージを生成するとき、サーバーはDNSメッセージ[RFC1035]の先頭からの相対オフセットで、標準のDNS名圧縮を使用する必要があります（SHOULD）。 1つのPUSHメッセージ内の複数の変更通知に同じ所有者名がある場合、この名前の圧縮により大幅な節約が可能になります。名前の圧縮は、マルチキャストDNS仕様[RFC6762]のセクション18.14で指定されているとおりに実行する必要があります。つまり、所有者名は常に圧縮する必要があり、RDATA内に表示される名前は、以下にリストされているRRタイプに対してのみ圧縮する必要があります。

NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC

NS、CNAME、PTR、DNAME、SOA、MX、AFSDB、RT、KX、RP、PX、SRV、NSEC

Servers may generate PUSH messages up to a maximum DNS message length of 16,382 bytes, counting from the start of the DSO 12-byte header. Including the two-byte length prefix that is used to frame DNS over a byte stream like TLS, this makes a total of 16,384 bytes. Servers MUST NOT generate PUSH messages larger than this. Where the immediately available change notifications are sufficient to exceed a DNS message length of 16,382 bytes, the change notifications MUST be communicated in separate PUSH messages of up to 16,382 bytes each. DNS name compression becomes less effective for messages larger than 16,384 bytes, so little efficiency benefit is gained by sending messages larger than this.

サーバーは、DSO 12バイトヘッダーの先頭から数えて、最大DNSメッセージ長16,382バイトまでのPUSHメッセージを生成できます。 TLSのようなバイトストリームを介してDNSをフレーム化するために使用される2バイト長のプレフィックスを含めると、合計で16,384バイトになります。サーバーはこれより大きなPUSHメッセージを生成してはいけません。 DNSメッセージの長さが16,382バイトを超えるのにすぐに利用できる変更通知で十分な場合、変更通知は、それぞれ最大16,382バイトの個別のPUSHメッセージで通信する必要があります。 DNS名の圧縮は、16,384バイトを超えるメッセージに対しては効果が低くなるため、これよりも大きいメッセージを送信しても、効率の向上はほとんど得られません。

If a client receives a PUSH message with a DNS message length larger than 16,382 bytes, this is a fatal error and the client MUST forcibly abort the connection immediately.

クライアントがDNSメッセージ長が16,382バイトを超えるPUSHメッセージを受信した場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |           MESSAGE ID (MUST BE ZERO)           |   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |QR| OPCODE(6) |         Z          |   RCODE   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             QDCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > HEADER
      |             ANCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             NSCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             ARCOUNT (MUST BE ZERO)            |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /
      |            DSO-TYPE = PUSH (0x0041)           |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |   DSO-LENGTH (number of octets in DSO-DATA)   |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      \                     NAME                      \   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                     TYPE                      |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                     CLASS                     |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                      TTL                      |    |
      |     (32-bit unsigned big-endian integer)      |     > DSO-DATA
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |  RDLEN (16-bit unsigned big-endian integer)   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      \           RDATA (sized as necessary)          \    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      :     NAME, TYPE, CLASS, TTL, RDLEN, RDATA      :    |
      :             Repeated As Necessary             :   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /

Figure 3: PUSH Message

図3：PUSHメッセージ

When processing the records received in a PUSH Message, the receiving client MUST validate that the records being added or removed correspond with at least one currently active subscription on that session. Specifically, the record name MUST match the name given in the SUBSCRIBE request, subject to the usual established DNS case-insensitivity for US-ASCII letters. For individual additions and removals, if the TYPE in the SUBSCRIBE request was not ANY (255), then the TYPE of the record must either be CNAME or match the TYPE given in the SUBSCRIBE request, and if the CLASS in the SUBSCRIBE request was not ANY (255), then the CLASS of the record must match the CLASS given in the SUBSCRIBE request. For collective removals, at least one of the records being removed must match an active subscription. If a matching active subscription on that session is not found, then that particular addition/removal record is silently ignored. The processing of other additions and removal records in this message is not affected. The DSO session is not closed. This is to allow for the unavoidable race condition where a client sends an outbound UNSUBSCRIBE while inbound PUSH messages for that subscription from the server are still in flight.

PUSHメッセージで受信したレコードを処理するとき、受信側クライアントは、追加または削除されるレコードが、そのセッションで現在アクティブなサブスクリプションの少なくとも1つに対応していることを検証する必要があります。具体的には、レコード名はSUBSCRIBEリクエストで指定された名前と一致する必要があります。これは、US-ASCII文字の通常の確立されたDNSの大文字小文字を区別しないことを条件とします。個別の追加と削除の場合、SUBSCRIBEリクエストのTYPEがANY（255）でない場合、レコードのTYPEはCNAMEであるか、SUBSCRIBEリクエストで指定されたTYPEと一致している必要があり、SUBSCRIBEリクエストのCLASSはANY（255）の場合、レコードのCLASSはSUBSCRIBEリクエストで指定されたCLASSと一致する必要があります。一括削除の場合、削除されるレコードの少なくとも1つがアクティブなサブスクリプションと一致する必要があります。そのセッションで一致するアクティブなサブスクリプションが見つからない場合、その特定の追加/削除レコードは通知なく無視されます。このメッセージの他の追加および削除レコードの処理は影響を受けません。 DSOセッションは閉じられていません。これは、サーバーからのサブスクリプションの受信PUSHメッセージがまだ処理中に、クライアントが送信UNSUBSCRIBEを送信するという不可避の競合状態を許容するためです。

The TTL of an added record is stored by the client. While the subscription is active the TTL is not decremented, because a change to the TTL would produce a new update. For as long as a relevant subscription remains active, the client SHOULD assume that when a record goes away, the server will notify it of that fact. Consequently, a client does not have to poll to verify that the record is still there. Once a subscription is canceled (individually, or as a result of the DSO session being closed), record aging for records covered by the subscription resumes and records are removed from the local cache when their TTL reaches zero.

追加されたレコードのTTLはクライアントによって保存されます。サブスクリプションがアクティブな間は、TTLが変更されると新しい更新が生成されるため、TTLは減少しません。関連するサブスクリプションがアクティブである限り、クライアントは、レコードがなくなると、サーバーがその事実を通知すると想定する必要があります（SHOULD）。したがって、クライアントは、レコードがまだ存在することを確認するためにポーリングする必要はありません。サブスクリプションがキャンセルされると（個別に、またはDSOセッションが終了した結果として）、サブスクリプションの対象となるレコードのレコードエージングが再開し、TTLがゼロに達したときにレコードがローカルキャッシュから削除されます。

6.4. DNS Push Notification UNSUBSCRIBE

6.4. DNSプッシュ通知UNSUBSCRIBE

To cancel an individual subscription without closing the entire DSO session, the client sends an UNSUBSCRIBE message over the established DSO session to the server.

DSOセッション全体を閉じずに個々のサブスクリプションをキャンセルするには、クライアントは確立されたDSOセッションを介してUNSUBSCRIBEメッセージをサーバーに送信します。

The entity that initiates an UNSUBSCRIBE message is by definition the client. A server MUST NOT send an UNSUBSCRIBE message over an existing session from a client. If a server does send an UNSUBSCRIBE message over a DSO session initiated by a client, or an UNSUBSCRIBE message is sent with the QR bit set indicating that it is a response, this is a fatal error and the receiver MUST forcibly abort the connection immediately.

UNSUBSCRIBEメッセージを開始するエンティティは、定義上クライアントです。サーバーは、クライアントからの既存のセッションを介してUNSUBSCRIBEメッセージを送信してはなりません（MUST NOT）。サーバーがクライアントによって開始されたDSOセッションを介してUNSUBSCRIBEメッセージを送信する場合、またはUNSUBSCRIBEメッセージが応答であることを示すQRビットが設定されて送信される場合、これは致命的なエラーであり、受信者は直ちに接続を強制的に中止する必要があります。

6.4.1. UNSUBSCRIBE Message

6.4.1. UNSUBSCRIBEメッセージ

An UNSUBSCRIBE unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the UNSUBSCRIBE Primary TLV. An UNSUBSCRIBE message is illustrated in Figure 4.

UNSUBSCRIBE単方向メッセージは、標準のDSO 12バイトヘッダー[RFC8490]で始まり、その後にUNSUBSCRIBEプライマリTLVが続きます。 UNSUBSCRIBEメッセージを図4に示します。

In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no server response to an UNSUBSCRIBE message.

DSO単方向メッセージの定義に従って、MESSAGE IDフィールドはゼロでなければなりません。 UNSUBSCRIBEメッセージに対するサーバーの応答はありません。

The DSO-TYPE is UNSUBSCRIBE (0x0042).

DSO-TYPEはUNSUBSCRIBE（0x0042）です。

The DSO-LENGTH field contains the value 2, the length of the 2-octet MESSAGE ID contained in the DSO-DATA.

DSO-LENGTHフィールドには、DSO-DATAに含まれている2オクテットのメッセージIDの長さである値2が含まれています。

The DSO-DATA contains the value previously given in the MESSAGE ID field of an active SUBSCRIBE request. This is how the server knows which SUBSCRIBE request is being canceled. After receipt of the UNSUBSCRIBE message, the SUBSCRIBE request is no longer active.

DSO-DATAには、アクティブなSUBSCRIBEリクエストのMESSAGE IDフィールドで以前に指定された値が含まれています。これは、サーバーがどのSUBSCRIBEリクエストがキャンセルされているかを知る方法です。 UNSUBSCRIBEメッセージの受信後、SUBSCRIBE要求はアクティブではなくなります。

It is allowable for the client to issue an UNSUBSCRIBE message for a previous SUBSCRIBE request for which the client has not yet received a SUBSCRIBE response. This is to allow for the case where a client starts and stops a subscription in less than the round-trip time to the server. The client is NOT required to wait for the SUBSCRIBE response before issuing the UNSUBSCRIBE message.

クライアントは、クライアントがまだSUBSCRIBE応答を受け取っていない前のSUBSCRIBE要求に対してUNSUBSCRIBEメッセージを発行することができます。これは、クライアントがサーバーへの往復時間よりも短い時間でサブスクリプションを開始および停止する場合に対応するためです。クライアントは、SUBSCRIBEメッセージを発行する前にSUBSCRIBE応答を待つ必要はありません。

Consequently, it is possible for a server to receive an UNSUBSCRIBE message that does not match any currently active subscription. This can occur when a client sends a SUBSCRIBE request, which subsequently fails and returns an error code, but the client sent an UNSUBSCRIBE message before it became aware that the SUBSCRIBE request had failed. Because of this, servers MUST silently ignore UNSUBSCRIBE messages that do not match any currently active subscription.

したがって、サーバーが、現在アクティブなサブスクリプションと一致しないUNSUBSCRIBEメッセージを受信する可能性があります。これは、クライアントがSUBSCRIBEリクエストを送信すると失敗し、エラーコードを返しますが、クライアントがSUBSCRIBEリクエストが失敗したことを認識する前にUNSUBSCRIBEメッセージを送信した場合に発生する可能性があります。このため、サーバーは、現在アクティブなサブスクリプションと一致しないUNSUBSCRIBEメッセージを黙って無視する必要があります。

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |           MESSAGE ID (MUST BE ZERO)           |   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |QR| OPCODE(6) |         Z          |   RCODE   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             QDCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > HEADER
      |             ANCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             NSCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             ARCOUNT (MUST BE ZERO)            |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /
      |         DSO-TYPE = UNSUBSCRIBE (0x0042)       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                DSO-LENGTH (2)                 |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |              SUBSCRIBE MESSAGE ID             |   > DSO-DATA
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /

Figure 4: UNSUBSCRIBE Message

図4：UNSUBSCRIBEメッセージ

6.5. DNS Push Notification RECONFIRM

6.5. DNSプッシュ通知の再確認

Sometimes, particularly when used with a Discovery Proxy [RFC8766], a DNS Zone may contain stale data. When a client encounters data that it believes may be stale (e.g., an SRV record referencing a target host+port that is not responding to connection requests), the client can send a RECONFIRM message to ask the server to re-verify that the data is still valid. For a Discovery Proxy, this causes it to issue new Multicast DNS queries to ascertain whether the target device is still present. How the Discovery Proxy causes these new Multicast DNS queries to be issued depends on the details of the underlying Multicast DNS implementation being used. For example, a Discovery Proxy built on Apple's dns_sd.h API [SD-API] responds to a DNS Push Notification RECONFIRM message by calling the underlying API's DNSServiceReconfirmRecord() routine.

ときどき、特にディスカバリプロキシ[RFC8766]と併用すると、DNSゾーンに古いデータが含まれる場合があります。クライアントは、古くなっていると思われるデータ（たとえば、接続要求に応答していないターゲットホスト+ポートを参照するSRVレコード）を検出すると、サーバーにデータの再確認を要求するRECONFIRMメッセージを送信できます。まだ有効です。 Discovery Proxyの場合、これにより、新しいマルチキャストDNSクエリが発行され、ターゲットデバイスがまだ存在しているかどうかが確認されます。 Discovery Proxyがこれらの新しいマルチキャストDNSクエリを発行する方法は、使用されている基になるマルチキャストDNS実装の詳細によって異なります。たとえば、Appleのdns_sd.h API [SD-API]で構築されたDiscovery Proxyは、基になるAPIのDNSServiceReconfirmRecord()ルーチンを呼び出すことにより、DNSプッシュ通知のRECONFIRMメッセージに応答します。

For other types of DNS server, the RECONFIRM operation is currently undefined and SHOULD result in a NOERROR response, but it need not cause any other action to occur.

他のタイプのDNSサーバーの場合、RECONFIRM操作は現在未定義であり、NOERROR応答が発生する必要がありますが、他のアクションを発生させる必要はありません。

Frequent use of RECONFIRM operations may be a sign of network unreliability, or some kind of misconfiguration, so RECONFIRM operations MAY be logged or otherwise communicated to a human administrator to assist in detecting and remedying such network problems.

RECONFIRM操作を頻繁に使用すると、ネットワークの信頼性が低下したり、何らかの設定ミスが発生したりする可能性があります。そのため、RECONFIRM操作をログに記録したり、人間の管理者に連絡して、このようなネットワークの問題の検出と修正を支援することができます。

If, after receiving a valid RECONFIRM message, the server determines that the disputed records are in fact no longer valid, then subsequent DNS PUSH Messages will be generated to inform interested clients. Thus, one client discovering that a previously advertised device (like a network printer) is no longer present has the side effect of informing all other interested clients that the device in question is now gone.

有効なRECONFIRMメッセージを受信した後、サーバーは、問題のあるレコードが実際には無効であると判断した場合、後続のDNS PUSHメッセージが生成されて、関心のあるクライアントに通知されます。したがって、以前にアドバタイズされたデバイス（ネットワークプリンターなど）が存在しないことを発見した1つのクライアントには、問題のデバイスがなくなったことを他のすべての関連クライアントに通知するという副作用があります。

The entity that initiates a RECONFIRM message is by definition the client. A server MUST NOT send a RECONFIRM message over an existing session from a client. If a server does send a RECONFIRM message over a DSO session initiated by a client, or a RECONFIRM message is sent with the QR bit set indicating that it is a response, this is a fatal error and the receiver MUST forcibly abort the connection immediately.

RECONFIRMメッセージを開始するエンティティは、定義上クライアントです。サーバーは、クライアントからの既存のセッションを介してRECONFIRMメッセージを送信してはなりません（MUST NOT）。サーバーがクライアントによって開始されたDSOセッションを介してRECONFIRMメッセージを送信する場合、またはそれが応答であることを示すQRビットが設定されたRECONFIRMメッセージが送信される場合、これは致命的なエラーであり、受信者は直ちに接続を強制的に中止する必要があります。

6.5.1. RECONFIRM Message

6.5.1. RECONFIRMメッセージ

A RECONFIRM unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the RECONFIRM Primary TLV. A RECONFIRM message is illustrated in Figure 5.

RECONFIRM単方向メッセージは、標準のDSO 12バイトヘッダー[RFC8490]で始まり、その後にRECONFIRMプライマリTLVが続きます。 RECONFIRMメッセージを図5に示します。

In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no server response to a RECONFIRM message.

DSO単方向メッセージの定義に従って、MESSAGE IDフィールドはゼロでなければなりません。 RECONFIRMメッセージに対するサーバーの応答はありません。

The DSO-TYPE is RECONFIRM (0x0043).

DSO-TYPEはRECONFIRM（0x0043）です。

The DSO-LENGTH is the length of the data that follows, which specifies the name, type, class, and content of the record being disputed.

DSO-LENGTHは、その後に続くデータの長さであり、紛争中のレコードの名前、タイプ、クラス、および内容を指定します。

A DNS Push Notifications RECONFIRM message contains exactly one RECONFIRM Primary TLV. The DSO-DATA in a RECONFIRM Primary TLV MUST contain exactly one record. The DSO-DATA in a RECONFIRM Primary TLV has no count field to specify more than one record. Since RECONFIRM messages are sent over TCP, multiple RECONFIRM messages can be concatenated in a single TCP stream and packed efficiently into TCP segments. Note that this means that DNS name compression cannot be used between different RECONFIRM messages. However, when a client is sending multiple RECONFIRM messages this indicates a situation with serious network problems, and this is not expected to occur frequently enough that optimizing efficiency in this case is important.

DNSプッシュ通知のRECONFIRMメッセージには、RECONFIRMプライマリTLVが1つだけ含まれています。 RECONFIRMプライマリTLVのDSO-DATAには、正確に1つのレコードが含まれている必要があります。 RECONFIRMプライマリTLVのDSO-DATAには、複数のレコードを指定するカウントフィールドがありません。 RECONFIRMメッセージはTCPを介して送信されるため、複数のRECONFIRMメッセージを単一のTCPストリームに連結し、効率的にTCPセグメントにパックできます。これは、異なるRECONFIRMメッセージ間でDNS名圧縮を使用できないことを意味することに注意してください。ただし、クライアントが複数のRECONFIRMメッセージを送信している場合、これは深刻なネットワークの問題がある状況を示しており、これは、この場合の効率の最適化が重要であるほど頻繁に発生するとは予想されません。

TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value ANY (255).

TYPEは値ANY（255）であってはならず、CLASSは値ANY（255）であってはなりません。

DNS wildcarding is not supported. That is, an asterisk character ("*") in a RECONFIRM message matches only a literal asterisk character ("*") in a name and nothing else. Similarly, a CNAME in a RECONFIRM message matches only a CNAME record with that name in the zone and no other records with that name.

DNSワイルドカードはサポートされていません。つまり、RECONFIRMメッセージのアスタリスク文字（ "*"）は、名前のリテラルアスタリスク文字（ "*"）のみに一致し、それ以外には一致しません。同様に、RECONFIRMメッセージ内のCNAMEは、ゾーン内のその名前を持つCNAMEレコードにのみ一致し、その名前を持つ他のレコードには一致しません。

Note that there is no RDLEN field, since the length of the RDATA can be inferred from DSO-LENGTH, so an additional RDLEN field would be redundant.

RDATAの長さはDSO-LENGTHから推測できるため、RDLENフィールドがないことに注意してください。追加のRDLENフィールドは冗長になります。

Following the same rules as for PUSH messages, DNS name compression SHOULD be used within the RDATA of the RECONFIRM message, with offsets relative to the beginning of the DNS message [RFC1035].

PUSHメッセージの場合と同じルールに従って、DNSメッセージの先頭からの相対オフセットで、RECONFIRMメッセージのRDATA内でDNS名圧縮を使用する必要があります[RFC1035]。

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      |           MESSAGE ID (MUST BE ZERO)           |   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |QR| OPCODE(6) |         Z          |   RCODE   |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             QDCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > HEADER
      |             ANCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             NSCOUNT (MUST BE ZERO)            |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |             ARCOUNT (MUST BE ZERO)            |   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /
      |         DSO-TYPE = RECONFIRM (0x0043)         |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |   DSO-LENGTH (number of octets in DSO-DATA)   |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  \
      \                     NAME                      \   \
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      |                     TYPE                      |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     > DSO-DATA
      |                     CLASS                     |    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    |
      \                     RDATA                     \   /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  /

Figure 5: RECONFIRM Message

図5：RECONFIRMメッセージ

6.6. DNS Stateful Operations TLV Context Summary

6.6. DNSステートフルオペレーションTLVコンテキストの概要

This document defines four new DSO TLVs. As recommended in Section 8.2 of the DNS Stateful Operations specification [RFC8490], the valid contexts of these new TLV types are summarized below.

このドキュメントでは、4つの新しいDSO TLVを定義しています。 DNS Stateful Operations仕様[RFC8490]のセクション8.2で推奨されているように、これらの新しいTLVタイプの有効なコンテキストは以下に要約されています。

The client TLV contexts are:

クライアントTLVコンテキストは次のとおりです。

C-P: Client request message, Primary TLV C-U: Client Unidirectional message, primary TLV C-A: Client request or unidirectional message, Additional TLV CRP: Response back to client, Primary TLV CRA: Response back to client, Additional TLV

C-P：クライアント要求メッセージ、プライマリTLV C-U：クライアント単方向メッセージ、プライマリTLV C-A：クライアント要求または単方向メッセージ、追加のTLV CRP：クライアントへの応答、プライマリTLV CRA：クライアントへの応答、追加TLV

               +-------------+-----+-----+-----+-----+-----+
               |    TLV Type | C-P | C-U | C-A | CRP | CRA |
               +=============+=====+=====+=====+=====+=====+
               |   SUBSCRIBE |  X  |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               |        PUSH |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               | UNSUBSCRIBE |     |  X  |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               |   RECONFIRM |     |  X  |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

Table 2: DSO TLV Client Context Summary

表2：DSO TLVクライアントコンテキストの概要

The server TLV contexts are:

サーバーのTLVコンテキストは次のとおりです。

S-P: Server request message, Primary TLV S-U: Server Unidirectional message, primary TLV S-A: Server request or unidirectional message, Additional TLV SRP: Response back to server, Primary TLV SRA: Response back to server, Additional TLV

S-P：サーバー要求メッセージ、プライマリTLV S-U：サーバー単方向メッセージ、プライマリTLV S-A：サーバー要求または単方向メッセージ、追加のTLV SRP：サーバーへの応答、プライマリTLV SRA：サーバーへの応答、追加のTLV

               +-------------+-----+-----+-----+-----+-----+
               |    TLV Type | S-P | S-U | S-A | SRP | SRA |
               +=============+=====+=====+=====+=====+=====+
               |   SUBSCRIBE |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               |        PUSH |     |  X  |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               | UNSUBSCRIBE |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+
               |   RECONFIRM |     |     |     |     |     |
               +-------------+-----+-----+-----+-----+-----+

Table 3: DSO TLV Server Context Summary

表3：DSO TLVサーバーコンテキストの概要

6.7. Client-Initiated Termination

6.7. クライアントが開始する終了

An individual subscription is terminated by sending an UNSUBSCRIBE TLV for that specific subscription, or all subscriptions can be canceled at once by the client closing the DSO session. When a client terminates an individual subscription (via UNSUBSCRIBE) or all subscriptions on that DSO session (by ending the session), it is signaling to the server that it is no longer interested in receiving those particular updates. It is informing the server that the server may release any state information it has been keeping with regards to these particular subscriptions.

個々のサブスクリプションは、その特定のサブスクリプションのUNSUBSCRIBE TLVを送信することで終了します。または、クライアントがDSOセッションを閉じることにより、すべてのサブスクリプションを一度にキャンセルできます。クライアントが（UNSUBSCRIBEを介して）個々のサブスクリプションまたはそのDSOセッションのすべてのサブスクリプションを（セッションを終了することによって）終了すると、クライアントは、特定の更新を受信する必要がなくなったことをサーバーに通知します。これらの特定のサブスクリプションに関して保持している状態情報をサーバーが解放できることをサーバーに通知しています。

After terminating its last subscription on a session via UNSUBSCRIBE, a client MAY close the session immediately or it may keep it open if it anticipates performing further operations on that session in the future. If a client wishes to keep an idle session open, it MUST respect the maximum idle time required by the server [RFC8490].

UNSUBSCRIBEを介してセッションの最後のサブスクリプションを終了した後、クライアントはすぐにセッションを閉じるか、将来そのセッションでさらに操作を実行することが予想される場合、セッションを開いたままにすることができます。クライアントがアイドルセッションを開いたままにしたい場合は、サーバーが必要とする最大アイドル時間を尊重する必要があります[RFC8490]。

If a client plans to terminate one or more subscriptions on a session and doesn't intend to keep that session open, then as an efficiency optimization, it MAY instead choose to simply close the session, which implicitly terminates all subscriptions on that session. This may occur because the client computer is being shut down, is going to sleep, the application requiring the subscriptions has terminated, or simply because the last active subscription on that session has been canceled.

クライアントがセッションで1つ以上のサブスクリプションを終了する予定で、そのセッションを開いたままにするつもりがない場合、効率の最適化として、代わりに単にセッションを閉じることを選択できます。これにより、そのセッションのすべてのサブスクリプションが暗黙的に終了します。これは、クライアントコンピューターがシャットダウン中、スリープ状態になる、サブスクリプションを必要とするアプリケーションが終了した、または単にそのセッションの最後のアクティブなサブスクリプションがキャンセルされたために発生する可能性があります。

When closing a session, a client should perform an orderly close of the TLS session. Typical APIs will provide a session close method that will send a TLS close_notify alert as described in Section 6.1 of the TLS 1.3 specification [RFC8446]. This instructs the recipient that the sender will not send any more data over the session. After sending the TLS close_notify alert, the client MUST gracefully close the underlying connection using a TCP FIN so that the TLS close_notify is reliably delivered. The mechanisms for gracefully closing a TCP connection with a TCP FIN vary depending on the networking API. For example, in the BSD Sockets API, sending a TCP FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the socket open until all remaining data has been read from it.

セッションを閉じるとき、クライアントはTLSセッションを適切に閉じる必要があります。典型的なAPIは、TLS 1.3仕様[RFC8446]のセクション6.1で説明されているように、TLS close_notifyアラートを送信するセッションクローズメソッドを提供します。これは、送信者がセッションを介してこれ以上データを送信しないことを受信者に指示します。 TLS close_notifyアラートを送信した後、TLS close_notifyが確実に配信されるように、クライアントはTCP FINを使用して基になる接続を正常に閉じる必要があります。 TCP FINを使用してTCP接続を適切に閉じるメカニズムは、ネットワークAPIによって異なります。たとえば、BSDソケットAPIでは、「shutdown（s、SHUT_WR）」を呼び出して、残りのすべてのデータが読み取られるまでソケットを開いたままにして、TCP FINを送信します。

If the session is forcibly closed at the TCP level by sending a RST from either end of the connection, data may be lost.

接続のいずれかの端からRSTを送信することにより、セッションがTCPレベルで強制的に閉じられると、データが失われる可能性があります。

6.8. Client Fallback to Polling

6.8. ポーリングへのクライアントフォールバック

There are cases where a client may exhaust all avenues for establishing a DNS Push Notification subscription without success. This can happen if the client's configured recursive resolver does not support DNS over TLS, or supports DNS over TLS but is not listening on TCP port 853, or supports DNS over TLS on TCP port 853 but does not support DSO on that port, or for some other reason is unable to provide a DNS Push Notification subscription. In this case, the client will attempt to communicate directly with an appropriate server, and it may be that the zone apex discovery fails, or there is no "_dns-push-tls._tcp.<zone>" SRV record, or the server indicated in the SRV record is misconfigured, overloaded, or is unresponsive for some other reason.

クライアントがDNSプッシュ通知サブスクリプションを確立するためのすべての手段を使い果たして成功しない場合があります。これは、クライアントの構成された再帰リゾルバーがDNS over TLSをサポートしていない、またはDNS over TLSをサポートしているがTCPポート853でリッスンしていない、またはTCPポート853でDNS over TLSをサポートしているがそのポートでDSOをサポートしていない、またはその他の理由により、DNSプッシュ通知サブスクリプションを提供できません。この場合、クライアントは適切なサーバーと直接通信しようとし、ゾーンの頂点の検出が失敗したか、「_ dns-push-tls._tcp。<zone>」SRVレコードがないか、サーバーである可能性があります。 SRVレコードに示されているのは、誤って構成されているか、過負荷であるか、または他の何らかの理由で応答していません。

Regardless of the reason for the failure, after being unable to establish the desired DNS Push Notification subscription, it is likely that the client will still wish to know the answer it seeks, even if that answer cannot be obtained with the timely change notifications provided by DNS Push Notifications. In such cases, it is likely that the client will obtain the answer it seeks via a conventional DNS query instead, repeated at some interval to detect when the answer RRset changes.

失敗の理由に関係なく、目的のDNSプッシュ通知サブスクリプションを確立できなかった後、クライアントが提供するタイムリーな変更通知でその回答を取得できない場合でも、クライアントは求めている回答を知りたいと思うでしょう。 DNSプッシュ通知。そのような場合、クライアントは従来のDNSクエリを介して求める回答を取得する可能性が高く、回答RRsetの変更を検出するために一定の間隔で繰り返されます。

In the case where a client responds to its failure to establish a DNS Push Notification subscription by falling back to polling with conventional DNS queries instead, the polling rate should be controlled to avoid placing excessive burden on the server. The interval between successive DNS queries for the same name, type, and class SHOULD be at least the minimum of 900 seconds (15 minutes) or two seconds more than the TTL of the answer RRset.

クライアントがDNSプッシュ通知サブスクリプションの確立に失敗した場合に、代わりに従来のDNSクエリによるポーリングにフォールバックする場合は、サーバーに過度の負担がかからないようにポーリングレートを制御する必要があります。同じ名前、タイプ、クラスの連続するDNSクエリの間隔は、最低でも900秒（15分）、または応答RRsetのTTLより2秒長い必要があります（SHOULD）。

The reason that for TTLs up to 898 seconds the query should not be reissued until two seconds _after_ the answer RRset has expired, is to ensure that the answer RRset has also expired from the cache on the client's configured recursive resolver. Otherwise (particularly if the clocks on the client and the recursive resolver do not run at precisely the same rate), there's a risk of a race condition where the client queries its configured recursive resolver just as the answer RRset has one second remaining in the recursive resolver's cache. The client would receive a reply telling it that the answer RRset has one second remaining; the client would then requery the recursive resolver again one second later. If by this time the answer RRset has actually expired from the recursive resolver's cache, the recursive resolver would then issue a new query to fetch fresh data from the authoritative server. Waiting until the answer RRset has definitely expired from the cache on the client's configured recursive resolver avoids this race condition and any unnecessary additional queries it causes.

最大898秒のTTLの場合、応答のRRsetが期限切れになる2秒後までクエリを再発行してはならない理由は、クライアントの構成された再帰リゾルバーのキャッシュからも、応答のRRsetが期限切れになるようにするためです。それ以外の場合（特に、クライアントのクロックと再帰リゾルバーが正確に同じレートで実行されない場合）、応答RRsetが再帰に1秒残っているのと同じように、クライアントが構成済みの再帰リゾルバーにクエリを実行するという競合状態のリスクがあります。リゾルバのキャッシュ。クライアントは、応答RRsetに残り1秒があることを伝える応答を受け取ります。その後、クライアントは1秒後に再帰リゾルバを再度クエリします。この時点までに、応答RRsetが再帰リゾルバのキャッシュから実際に期限切れになった場合、再帰リゾルバは新しいクエリを発行して、権限のあるサーバーから新しいデータをフェッチします。応答RRsetがクライアントの構成済みの再帰リゾルバーのキャッシュから確実に期限切れになるまで待機することで、この競合状態とそれによって引き起こされる不要な追加のクエリを回避できます。

Each time a client is about to reissue its query to discover changes to the answer RRset, it should first make a new attempt to establish a DNS Push Notification subscription using previously cached DNS answers as appropriate. After a temporary misconfiguration has been remedied, this allows a client that is polling to return to using DNS Push Notifications for asynchronous notification of changes.

クライアントがクエリを再発行して回答RRsetへの変更を検出しようとするたびに、以前にキャッシュされたDNS回答を適切に使用して、DNSプッシュ通知サブスクリプションを確立する新しい試行を最初に行う必要があります。一時的な設定ミスが修正された後、ポーリングを行っているクライアントは、変更の非同期通知にDNSプッシュ通知を使用するように戻すことができます。

7. Security Considerations

7. セキュリティに関する考慮事項

The Strict Privacy profile for DNS over TLS is REQUIRED for DNS Push Notifications [RFC8310]. Cleartext connections for DNS Push Notifications are not permissible. Since this is a new protocol, transition mechanisms from the Opportunistic Privacy profile are unnecessary.

TLS上のDNSの厳格なプライバシープロファイルは、DNSプッシュ通知[RFC8310]に必要です。 DNSプッシュ通知のクリアテキスト接続は許可されていません。これは新しいプロトコルであるため、日和見プライバシープロファイルからの移行メカニズムは不要です。

Also, see Section 9 of the document Usage Profiles for DNS over (D)TLS [RFC8310] for additional recommendations for various versions of TLS usage.

また、TLSのさまざまなバージョンの使用に関する追加の推奨事項については、ドキュメント（DNS over over（D）TLSの使用プロファイル[RFC8310]）のセクション9を参照してください。

As a consequence of requiring TLS, client certificate authentication and verification may also be enforced by the server for stronger client-server security or end-to-end security. However, recommendations for security in particular deployment scenarios are outside the scope of this document.

TLSを必要とする結果として、クライアントサーバーのセキュリティまたはエンドツーエンドのセキュリティを強化するために、サーバーによってクライアント証明書の認証と検証も実施される場合があります。ただし、特定の展開シナリオでのセキュリティに関する推奨事項は、このドキュメントの範囲外です。

DNSSEC is RECOMMENDED for the authentication of DNS Push Notification servers. TLS alone does not provide complete security. TLS certificate verification can provide reasonable assurance that the client is really talking to the server associated with the desired host name, but since the desired host name is learned via a DNS SRV query, if the SRV query is subverted, then the client may have a secure connection to a rogue server. DNSSEC can provide added confidence that the SRV query has not been subverted.

DNSプッシュ通知サーバーの認証にはDNSSECが推奨されます。 TLSだけでは完全なセキュリティは提供されません。 TLS証明書の検証により、目的のホスト名に関連付けられたサーバーとクライアントが実際に通信していることが合理的に保証されますが、目的のホスト名はDNS SRVクエリを通じて学習されるため、SRVクエリが破壊された場合、クライアントには不正なサーバーへの安全な接続。 DNSSECは、SRVクエリが破壊されていないという追加の信頼を提供できます。

7.1. Security Services

7.1. セキュリティサービス

It is the goal of using TLS to provide the following security services:

TLSを使用して次のセキュリティサービスを提供することが目標です。

Confidentiality: All application-layer communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver.

機密性：すべてのアプリケーション層の通信は暗号化されており、目的の受信者以外は誰も暗号化を解除できません。

Data integrity protection: Any changes made to the communication in transit are detectable by the receiver.

データ保全性保護：送信中の通信に加えられた変更は、受信者が検出できます。

Authentication: An endpoint of the TLS communication is authenticated as the intended entity to communicate with.

認証：TLS通信のエンドポイントは、通信対象のエンティティとして認証されます。

Anti-replay protection: TLS provides for the detection of and prevention against messages sent previously over a TLS connection (such as DNS Push Notifications). If prior messages are re-sent at a later time as a form of a man-in-the-middle attack, then the receiver will detect this and reject the replayed messages.

アンチリプレイ保護：TLSは、以前にTLS接続を介して送信されたメッセージ（DNSプッシュ通知など）の検出と防止を提供します。以前のメッセージがman-in-the-middle攻撃の形で後で再送信された場合、受信者はこれを検出し、再生されたメッセージを拒否します。

Deployment recommendations on the appropriate key lengths and cipher suites are beyond the scope of this document. Please refer to the current TLS Recommendations [BCP195] for the best current practices. Keep in mind that best practices only exist for a snapshot in time, and recommendations will continue to change. Updated versions or errata may exist for these recommendations.

適切なキーの長さと暗号スイートに関する展開の推奨事項は、このドキュメントの範囲を超えています。現在のベストプラクティスについては、現在のTLS推奨事項[BCP195]を参照してください。ベストプラクティスは時間内のスナップショットに対してのみ存在し、推奨事項は引き続き変更されることに注意してください。これらの推奨事項には、更新されたバージョンまたはエラッタが存在する場合があります。

7.2. TLS Name Authentication

7.2. TLS名前認証

As described in Section 6.1, the client discovers the DNS Push Notification server using an SRV lookup for the record name "_dns-push-tls._tcp.<zone>". The server connection endpoint SHOULD then be authenticated using DANE TLSA records for the associated SRV record. This associates the target's name and port number with a trusted TLS certificate [RFC7673]. This procedure uses the TLS Server Name Indication (SNI) extension [RFC6066] to inform the server of the name the client has authenticated through the use of TLSA records. Therefore, if the SRV record passes DNSSEC validation and a TLSA record matching the target name is usable, an SNI extension must be used for the target name to ensure the client is connecting to the server it has authenticated. If the target name does not have a usable TLSA record, then the use of the SNI extension is optional. See Usage Profiles for DNS over TLS and DNS over DTLS [RFC8310] for more information on authenticating domain names.

セクション6.1で説明したように、クライアントは、レコード名「_dns-push-tls._tcp。<zone>」のSRVルックアップを使用してDNSプッシュ通知サーバーを検出します。次に、サーバー接続エンドポイントは、関連するSRVレコードのDANE TLSAレコードを使用して認証される必要があります（SHOULD）。これにより、ターゲットの名前とポート番号が信頼できるTLS証明書[RFC7673]に関連付けられます。この手順では、TLSサーバー名表示（SNI）拡張[RFC6066]を使用して、クライアントがTLSAレコードを使用して認証した名前をサーバーに通知します。したがって、SRVレコードがDNSSEC検証に合格し、ターゲット名と一致するTLSAレコードが使用可能な場合、SNI拡張をターゲット名に使用して、クライアントが認証済みのサーバーに接続していることを確認する必要があります。ターゲット名に使用可能なTLSAレコードがない場合、SNI拡張の使用はオプションです。ドメイン名の認証の詳細については、DNS over TLSおよびDNS over DTLS [RFC8310]の使用プロファイルを参照してください。

7.3. TLS Early Data

7.3. TLS初期データ

DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted in TLS early data. Using TLS early data can save one network round trip and can result in the client obtaining results faster.

プライマリTLVとしてSUBSCRIBE TLVを持つDSOメッセージは、TLS初期データで許可されます。 TLSの初期データを使用すると、1つのネットワークラウンドトリップを節約でき、クライアントがより早く結果を取得できるようになります。

However, there are some factors to consider before using TLS early data.

ただし、TLS初期データを使用する前に考慮すべきいくつかの要因があります。

TLS early data is not forward secret. In cases where forward secrecy of DNS Push Notification subscriptions is required, the client should not use TLS early data.

TLSの初期データはフォワードシークレットではありません。 DNSプッシュ通知サブスクリプションの転送秘密が必要な場合、クライアントはTLS初期データを使用しないでください。

With TLS early data, there are no guarantees of non-replay between connections. If packets are duplicated and delayed in the network, the later arrivals could be mistaken for new subscription requests. Generally, this is not a major concern since the amount of state generated on the server for these spurious subscriptions is small and short lived since the TCP connection will not complete the three-way handshake. Servers MAY choose to implement rate-limiting measures that are activated when the server detects an excessive number of spurious subscription requests.

TLSの初期データでは、接続間での非再生の保証はありません。パケットが重複していてネットワークで遅延している場合、遅い到着が新しいサブスクリプション要求と間違われる可能性があります。 TCP接続は3ウェイハンドシェイクを完了しないため、これらの偽のサブスクリプションに対してサーバー上で生成される状態の量は少なく、有効期間が短いため、これは大きな問題ではありません。サーバーは、サーバーが過剰な数の偽のサブスクリプション要求を検出したときにアクティブになるレート制限措置を実装することを選択できます。

For further guidance on use of TLS early data, please see discussion of zero round-trip data in Sections 2.3 and 8, and Appendix E.5, of the TLS 1.3 specification [RFC8446].

TLS初期データの使用に関する詳細なガイダンスについては、TLS 1.3仕様[RFC8446]のセクション2.3と8、および付録E.5のゼロラウンドトリップデータの説明を参照してください。

7.4. TLS Session Resumption

7.4. TLSセッションの再開

TLS session resumption [RFC8446] is permissible on DNS Push Notification servers. However, closing the TLS connection terminates the DSO session. When the TLS session is resumed, the DNS Push Notification server will not have any subscription state and will proceed as with any other new DSO session. Use of TLS session resumption may allow a TLS connection to be set up more quickly, but the client will still have to recreate any desired subscriptions.

TLSセッションの再開[RFC8446]は、DNSプッシュ通知サーバーで許可されています。ただし、TLS接続を閉じると、DSOセッションが終了します。 TLSセッションが再開されると、DNSプッシュ通知サーバーはサブスクリプション状態を持たなくなり、他の新しいDSOセッションと同様に続行します。 TLSセッション再開を使用すると、TLS接続をより迅速にセットアップできる場合がありますが、クライアントは必要なサブスクリプションを再作成する必要があります。

8. IANA Considerations

8. IANAに関する考慮事項

This document defines a new service name, only applicable for the TCP protocol, which has been recorded in the IANA "Service Name and Transport Protocol Port Number Registry" [RFC6335] [SRVTYPE].

このドキュメントでは、IANAの「サービス名とトランスポートプロトコルのポート番号レジストリ」[RFC6335] [SRVTYPE]に記録されている、TCPプロトコルにのみ適用される新しいサービス名を定義しています。

     +-----------------------+------+----------------------+---------+
     | Name                  | Port |        Value         | Section |
     +=======================+======+======================+=========+
     | DNS Push Notification | None | "_dns-push-tls._tcp" |   6.1   |
     | Service Type          |      |                      |         |
     +-----------------------+------+----------------------+---------+

Table 4: IANA Service Type Assignments

表4：IANAサービスタイプの割り当て

This document defines four new DNS Stateful Operation TLV types, which have been recorded in the IANA "DSO Type Codes" registry [RFC8490] [DSOTYPE].

このドキュメントでは、IANAの「DSOタイプコード」レジストリ[RFC8490] [DSOTYPE]に記録されている4つの新しいDNSステートフルオペレーションTLVタイプを定義しています。

     +-------------+--------+------------+-----------------+---------+
     | Name        | Value  | Early Data |      Status     | Section |
     +=============+========+============+=================+=========+
     | SUBSCRIBE   | 0x0040 |     OK     | Standards Track |   6.2   |
     +-------------+--------+------------+-----------------+---------+
     | PUSH        | 0x0041 |     NO     | Standards Track |   6.3   |
     +-------------+--------+------------+-----------------+---------+
     | UNSUBSCRIBE | 0x0042 |     NO     | Standards Track |   6.4   |
     +-------------+--------+------------+-----------------+---------+
     | RECONFIRM   | 0x0043 |     NO     | Standards Track |   6.5   |
     +-------------+--------+------------+-----------------+---------+

Table 5: IANA DSO TLV Type Code Assignments

表5：IANA DSO TLVタイプコードの割り当て

This document defines no new DNS OPCODEs or RCODEs.

このドキュメントでは、新しいDNS OPCODEまたはRCODEは定義されていません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[DSOTYPE] IANA, "Domain Name System (DNS) Parameters", <https://www.iana.org/assignments/dns-parameters/>.

[DSOTYPE] IANA、「ドメインネームシステム（DNS）パラメータ」、<https://www.iana.org/assignments/dns-parameters/>。

[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[RFC0020] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。

[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https://www.rfc-editor.org/info / rfc1123>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.

[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、DOI 10.17487 / RFC2136、April 1997 、<https://www.rfc-editor.org/info/rfc2136>。

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.

[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https://www.rfc-editor.org/info/rfc2181>。

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.

[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。

[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

[RFC6895] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<https://www.rfc-editor.org/info/rfc6895 >。

[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <https://www.rfc-editor.org/info/rfc7673>.

[RFC7673] Finch、T.、Miller、M。、およびP. Saint-Andre、「DNSベースの名前付きエンティティの認証（DANE）TLSAレコードとSRVレコードの使用」、RFC 7673、DOI 10.17487 / RFC7673、2015年10月、 <https://www.rfc-editor.org/info/rfc7673>。

[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.

[RFC7766] Dickinson、J.、Dickinson、S.、Bellis、R.、Mankin、A。、およびD. Wessels、「DNS Transport over TCP-実装要件」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、< https://www.rfc-editor.org/info/rfc7766>。

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.

[RFC8310] Dickinson、S.、Gillmor、D。、およびT. Reddy、「DNS over TLSおよびDNS over DTLSの使用プロファイル」、RFC 8310、DOI 10.17487 / RFC8310、2018年3月、<https：//www.rfc -editor.org/info/rfc8310>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>.

[RFC8490]ベリス、R、チェシャー、S、ディキンソン、J、ディキンソン、S、レモン、T、プサテリ、「DNSステートフルオペレーション」、RFC 8490、DOI 10.17487 / RFC8490、2019年3月、 <https://www.rfc-editor.org/info/rfc8490>。

[SRVTYPE] IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>.

[SRVTYPE] IANA、「サービス名とトランスポートプロトコルのポート番号レジストリ」、<https://www.iana.org/assignments/service-names-port-numbers/>。

9.2. Informative References

9.2. 参考引用

[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>.

[BCP195] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<https://www.rfc-editor.org/info/bcp195>。

[OBS] Wikipedia, "Observer pattern", February 2020, <https://en.wikipedia.org/w/ index.php?title=Observer_pattern&oldid=939702131>.

[OBS] Wikipedia、「Observer pattern」、2020年2月、<https://en.wikipedia.org/w/ index.php？title = Observer_pattern＆oldid = 939702131>。

[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.

[RFC2308]アンドリュース、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<https://www.rfc-editor.org/info/rfc2308>。

[RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, <https://www.rfc-editor.org/info/rfc3123>.

[RFC3123] Koch、P。、「アドレスプレフィックスのリストのDNS RRタイプ（APL RR）」、RFC 3123、DOI 10.17487 / RFC3123、2001年6月、<https://www.rfc-editor.org/info/ rfc3123>。

[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.

[RFC4287]ノッティンガム、M。、エド。およびR. Sayre編、「The Atom Syndication Format」、RFC 4287、DOI 10.17487 / RFC4287、2005年12月、<https://www.rfc-editor.org/info/rfc4287>。

[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.

[RFC4953] Touch、J。、「なりすまし攻撃に対するTCPの防御」、RFC 4953、DOI 10.17487 / RFC4953、2007年7月、<https://www.rfc-editor.org/info/rfc4953>。

[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, DOI 10.17487/RFC6281, June 2011, <https://www.rfc-editor.org/info/rfc6281>.

[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R.、and L. Zhang、 "Understanding Apple's Back to My Mac（BTMM）Service、RFC 6281、DOI 10.17487 / RFC6281、June 2011、<https： //www.rfc-editor.org/info/rfc6281>。

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC6762]チェシャーS.およびM.クロマル、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。

[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。

[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013, <https://www.rfc-editor.org/info/rfc6886>.

[RFC6886] Cheshire、S。、およびM. Krochmal、「NAT Port Mapping Protocol（NAT-PMP）」、RFC 6886、DOI 10.17487 / RFC6886、2013年4月、<https://www.rfc-editor.org/info/ rfc6886>。

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.

[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、DOI 10.17487 / RFC6887、April 2013 、<https://www.rfc-editor.org/info/rfc6887>。

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：//www.rfc-editor .org / info / rfc7413>。

[RFC8010] Sweet, M. and I. McDonald, "Internet Printing Protocol/1.1: Encoding and Transport", STD 92, RFC 8010, DOI 10.17487/RFC8010, January 2017, <https://www.rfc-editor.org/info/rfc8010>.

[RFC8010] Sweet、M。およびI. McDonald、「Internet Printing Protocol / 1.1：Encoding and Transport」、STD 92、RFC 8010、DOI 10.17487 / RFC8010、2017年1月、<https://www.rfc-editor.org / info / rfc8010>。

[RFC8011] Sweet, M. and I. McDonald, "Internet Printing Protocol/1.1: Model and Semantics", STD 92, RFC 8011, DOI 10.17487/RFC8011, January 2017, <https://www.rfc-editor.org/info/rfc8011>.

[RFC8011] Sweet、M。およびI. McDonald、「Internet Printing Protocol / 1.1：Model and Semantics」、STD 92、RFC 8011、DOI 10.17487 / RFC8011、2017年1月、<https://www.rfc-editor.org / info / rfc8011>。

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[RFC8499]ホフマン、P。、サリバン、A。、およびK.藤原、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https://www.rfc-editor.org/ info / rfc8499>。

[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.

[RFC8684] Ford、A.、Raiciu、C.、Handley、M.、Bonaventure、O。、およびC. Paasch、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 8684、DOI 10.17487 / RFC8684、2020年3月、 <https://www.rfc-editor.org/info/rfc8684>。

[RFC8764] Cheshire, S. and M. Krochmal, "Apple's DNS Long-Lived Queries Protocol", RFC 8764, DOI 10.17487/RFC8764, June 2020, <https://www.rfc-editor.org/info/rfc8764>.

[RFC8764] Cheshire、S。およびM. Krochmal、「AppleのDNS長命クエリプロトコル」、RFC 8764、DOI 10.17487 / RFC8764、2020年6月、<https://www.rfc-editor.org/info/rfc8764> 。

[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, <https://www.rfc-editor.org/info/rfc8766>.

[RFC8766] Cheshire、S.、「マルチキャストDNSベースのサービスディスカバリ用のディスカバリプロキシ」、RFC 8766、DOI 10.17487 / RFC8766、2020年6月、<https://www.rfc-editor.org/info/rfc8766>。

[SD-API] Apple Inc., "dns_sd.h", <https://opensource.apple.com/source/mDNSResponder/ mDNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html>.

[SD-API] Apple Inc.、「dns_sd.h」、<https://opensource.apple.com/source/mDNSResponder/ mDNSResponder-878.70.2 / mDNSShared / dns_sd.h.auto.html>。

[SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The Internet Protocol Journal, Cisco Systems, Volume 9, Number 4, December 2006, <https://www.cisco.com/web/about/ac123/ac147/ archived_issues/ipj_9-4/ipj_9-4.pdf>.

[SYN] Eddy、W。、「TCP SYNフラッディング攻撃に対する防御」、インターネットプロトコルジャーナル、Cisco Systems、Volume 9、Number 4、2006年12月、<https://www.cisco.com/web/about/ac123 /ac147/archived_issues/ipj_9-4/ipj_9-4.pdf>。

[TCPRACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: a time-based fast loss detection algorithm for TCP", Work in Progress, Internet-Draft, draft-ietf-tcpm-rack-08, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-rack-08>.

[TCPRACK] Cheng、Y.、Cardwell、N.、Dukkipati、N。、およびP. Jha、「RACK：時間ベースのTCPの高速損失検出アルゴリズム」、Work in Progress、インターネットドラフト、draft-ietf- tcpm-rack-08、2020年3月9日、<https://tools.ietf.org/html/draft-ietf-tcpm-rack-08>。

[XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, October 2019, <https://xmpp.org/extensions/xep-0060.html>.

[XEP0060] Millard、P.、Saint-Andre、P。、およびR. Meijer、「Publish-Subscribe」、XSF XEP 0060、2019年10月、<https://xmpp.org/extensions/xep-0060.html> 。

Acknowledgments

謝辞

The authors would like to thank Kiren Sekar and Marc Krochmal for previous work completed in this field.

著者は、この分野で完了した以前の仕事をしてくれたKiren SekarとMarc Krochmalに感謝します。

This document has been improved due to comments from Ran Atkinson, Tim Chown, Sara Dickinson, Mark Delany, Ralph Droms, Jan Komissar, Eric Rescorla, Michael Richardson, David Schinazi, Manju Shankar Rao, Robert Sparks, Markus Stenberg, Andrew Sullivan, Michael Sweet, Dave Thaler, Brian Trammell, Bernie Volz, Éric Vyncke, Christopher Wood, Liang Xia, and Soraia Zlatkovic. Ted Lemon provided clarifying text that was greatly appreciated.

このドキュメントは、Ran Atkinson、Tim Chown、Sara Dickinson、Mark Delany、Ralph Droms、Jan Komissar、Eric Rescorla、Michael Richardson、David Schinazi、Manju Shankar Rao、Robert Sparks、Markus Stenberg、Andrew Sullivan、Michaelからのコメントにより改善されました。 Sweet、Dave Thaler、Brian Trammell、Bernie Volz、ÉricVyncke、Christopher Wood、Liang Xia、Soraia Zlatkovic。テッドレモンは、非常に高く評価された明確なテキストを提供しました。

Authors' Addresses

著者のアドレス

Tom Pusateri Unaffiliated Raleigh, NC 27608 United States of America

Tom Pusateri無関係のローリー、ノースカロライナ州27608アメリカ合衆国

   Phone: +1 919 867 1330
   Email: pusateri@bangj.com

Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America

スチュアートチェシャーアップルインクワンアップルパークウェイクパチーノ、カリフォルニア95014アメリカ合衆国

   Phone: +1 (408) 996-1010
   Email: cheshire@apple.com