[要約] RFC 8764は、AppleのDNS Long-Lived Queriesプロトコルに関する仕様書です。このプロトコルの目的は、デバイスがネットワーク上のリソースの変更をリアルタイムで検出し、適切なアクションを実行することです。
Independent Submission S. Cheshire
Request for Comments: 8764 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 June 2020
Apple's DNS Long-Lived Queries Protocol
AppleのDNS長命クエリプロトコル
Abstract
概要
Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement.
AppleのDNS Long-Lived Queries（LLQ）は、変更通知をサポートするようにDNSプロトコルを拡張するためのメカニズムです。これにより、クライアントはサーバーをポーリングすることなくDNSデータの変更について知ることができます。 2005年以降、LLQはMac OS X、Bonjour for Windows、AirPortワイヤレスベースステーションなどのアップル製品に実装されました。 2020年、LLQプロトコルはIETF標準トラックRFC 8765、「DNSプッシュ通知」に取って代わられました。これは、LLQプロトコルで得られた経験に基づいて優れた代替品を作成します。
The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications.
2005年から2020年に展開および使用された既存のLLQプロトコルは、DNSプッシュ通知の開発に情報を提供した運用経験に関する背景を提供し、LLQからDNSプッシュ通知へのスムーズな移行を促進するためにここに文書化されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8764.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8764で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Transition to DNS Push Notifications
2. Conventions and Terminology Used in This Document
3. Mechanisms
3.1. Assigned Numbers
3.2. Opt-RR Format
4. LLQ Address and Port Identification
5. LLQ Setup
5.1. Setup Message Retransmission
5.2. LLQ Setup Four-Way Handshake
5.2.1. Setup Request
5.2.2. Setup Challenge
5.2.3. Challenge Response
5.2.4. ACK + Answers
5.3. Resource Record TTLs
6. Event Responses
6.1. Add Events
6.2. Remove Events
6.3. Gratuitous Response Acknowledgments
7. LLQ Lease-Life Expiration
7.1. Refresh Request
7.2. LLQ Refresh Acknowledgment
8. Security Considerations
8.1. Server DoS
8.2. Client Packet Storms
8.3. Spoofing
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Problems with the LLQ Protocol
Acknowledgments
Authors' Addresses
In dynamic environments, DNS-based Service Discovery [RFC6763] benefits significantly from clients being able to learn about changes to DNS information via a mechanism that is both more timely and more efficient than simple polling. Such a mechanism enables "live browses" that (a) learn when a new instance of a service appears, (b) learn when an existing service instance disappears from the network, and (c) allows clients to monitor status changes to a service instance (e.g., printer ink levels). Multicast DNS [RFC6762] supports this natively. When a device on the network publishes or deletes Multicast DNS records, these changes are multicast to other hosts on the network. Those hosts deliver the change notifications to interested clients (applications running on that host). Hosts also send occasional queries to the network, in case gratuitous announcements are not received due to packet loss, and to detect records lost due to their publishers crashing or having become disconnected from the network.
動的環境では、DNSベースのサービスディスカバリ[RFC6763]は、クライアントがDNS情報の変更について、単純なポーリングよりもタイムリーで効率的なメカニズムを介して学習できるという大きなメリットがあります。このようなメカニズムにより、（a）サービスの新しいインスタンスが表示されたときに学習し、（b）既存のサービスインスタンスがネットワークから消えたときに学習し、（c）クライアントがサービスインスタンスのステータス変更を監視できる「ライブブラウズ」が可能になります。 （例えば、プリンターのインクレベル）。マルチキャストDNS [RFC6762]はこれをネイティブでサポートしています。ネットワーク上のデバイスがマルチキャストDNSレコードを公開または削除すると、これらの変更はネットワーク上の他のホストにマルチキャストされます。これらのホストは、関係するクライアント（そのホストで実行されているアプリケーション）に変更通知を配信します。ホストは、パケット損失が原因で不必要なアナウンスが受信されなかった場合、およびパブリッシャーがクラッシュしたりネットワークから切断されたために失われたレコードを検出するために、ネットワークに時々クエリを送信します。
This document defines an Apple extension to unicast DNS that enables a client to issue long-lived queries that allow a unicast DNS server to notify clients about changes to DNS data. This is a more scalable and practical solution than can be achieved by polling of the name server, because a low polling rate could leave the client with stale information, while a high polling rate would have an adverse impact on the network and server.
このドキュメントでは、ユニキャストDNSに対するApple拡張機能を定義します。これにより、クライアントは、ユニキャストDNSサーバーがDNSデータの変更についてクライアントに通知できるようにする、長期間有効なクエリを発行できます。これは、ネームサーバーのポーリングよりもスケーラブルで実用的なソリューションです。ポーリングレートが低いと、クライアントに古い情報が残り、ポーリングレートが高いと、ネットワークとサーバーに悪影響を及ぼすためです。
The mechanism defined in this document is now being replaced by DNS Push Notifications [RFC8765] as explained in Section 1.1.
このドキュメントで定義されているメカニズムは、セクション1.1で説明されているように、DNSプッシュ通知[RFC8765]に置き換えられています。
The LLQ protocol enjoyed over a decade of useful operation, enabling timely live updates for the service discovery user interface in Apple's Back to My Mac [RFC6281] service.
LLQプロトコルは10年以上の有用な操作を享受し、AppleのBack to My Mac [RFC6281]サービスでサービスディスカバリユーザーインターフェイスのタイムリーなライブアップデートを可能にしました。
However, some problems were discovered, as described in Appendix A. This operational experience with LLQ informed the design of its IETF Standards Track successor, DNS Push Notifications [RFC8765]. Since no further work is being done on the LLQ protocol, this LLQ specification will not be updated to remedy these problems.
ただし、付録Aで説明されているように、いくつかの問題が発見されました。LLQのこの運用経験により、IETF標準トラックの後継であるDNSプッシュ通知[RFC8765]の設計がわかりました。 LLQプロトコルではこれ以上の作業は行われていないため、このLLQ仕様はこれらの問題を解決するために更新されません。
All existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications instead.
既存のすべてのLLQ実装は、代わりにDNSプッシュ通知の使用に移行することをお勧めします。
Existing LLQ servers are RECOMMENDED to implement and support DNS Push Notifications so that clients can begin migrating to the newer protocol.
既存のLLQサーバーは、クライアントが新しいプロトコルへの移行を開始できるように、DNSプッシュ通知を実装およびサポートすることが推奨されています。
Existing LLQ clients are RECOMMENDED to query for the "_dns-push-tls._tcp.<zone>" SRV record first, and then only if DNS Push Notifications fail, fall back to query for "_dns-llq._udp.<zone>" instead. Use of the "_dns-llq._udp.<zone>" SRV record is described in Section 4.
既存のLLQクライアントは、 "_ dns-push-tls._tcp。<zone>" SRVレコードを最初に照会し、次にDNSプッシュ通知が失敗した場合のみ、 "_ dns-llq._udp。<zone>を照会するようにフォールバックすることをお勧めします"代わりに。 「_dns-llq._udp。<zone>」SRVレコードの使用については、セクション4で説明します。
This will cause clients to prefer the newer protocol when possible. It is RECOMMENDED that clients always attempt DNS Push Notifications first for every new request, and only if that fails, then fall back to using LLQ. Clients SHOULD NOT record that a given server only speaks LLQ and subsequently default to LLQ for that server, since server software gets updated and even a server that speaks only LLQ today may be updated to support DNS Push Notifications tomorrow.
これにより、クライアントは可能な限り新しいプロトコルを優先します。クライアントは常にすべての新しい要求に対して最初にDNSプッシュ通知を試み、それが失敗した場合にのみ、LLQの使用にフォールバックすることをお勧めします。サーバーソフトウェアは更新され、今日LLQのみを話すサーバーでさえも、明日DNSプッシュ通知をサポートするように更新される可能性があるため、クライアントは、特定のサーバーがLLQのみを話し、その後そのサーバーのLLQにデフォルト設定されることを記録しないでください。
New client and server implementations are RECOMMENDED to support only DNS Push Notifications.
新しいクライアントとサーバーの実装では、DNSプッシュ通知のみをサポートすることをお勧めします。
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]で説明されているように解釈されます。
DNS Long-Lived Queries (LLQ) are implemented using the standard DNS message format [RFC1035] in conjunction with an EDNS(0) OPT pseudo-RR [RFC6891] with a new OPTION-CODE and OPTION-DATA format specified here. Encoding the LLQ request in an OPT pseudo-RR allows for implementation of LLQ with minimal modification to a name server's front end. If a DNS query containing an LLQ option is sent to a server that does not implement LLQ, a server that complies with the EDNS(0) specification [RFC6891] will silently ignore the unrecognized option and answer the request as a normal DNS query without establishing any long-lived state and without returning an LLQ option in its response. If a DNS query containing an LLQ option is sent to a server that does not implement EDNS(0) at all, the server may silently ignore the EDNS(0) OPT pseudo-RR or it may return a nonzero RCODE. However, in practice, this issue is mostly theoretical, since having a zone's _dns-llq._udp.<zone> SRV record target a host that does not implement LLQ is a configuration error.
DNS Long-Lived Queries（LLQ）は、ここで指定された新しいOPTION-CODEおよびOPTION-DATA形式でEDNS（0）OPT疑似RR [RFC6891]とともに標準DNSメッセージ形式[RFC1035]を使用して実装されます。 OPT疑似RRでLLQ要求をエンコードすると、ネームサーバーのフロントエンドに最小限の変更を加えるだけでLLQを実装できます。 LLQオプションを含むDNSクエリがLLQを実装していないサーバーに送信された場合、EDNS（0）仕様[RFC6891]に準拠するサーバーは、認識されないオプションを黙って無視し、確立せずに通常のDNSクエリとして要求に応答します存続期間が長く、応答でLLQオプションを返さない。 LLQオプションを含むDNSクエリがEDNS（0）をまったく実装していないサーバーに送信された場合、サーバーはEDNS（0）OPT疑似RRを黙って無視するか、ゼロ以外のRCODEを返すことがあります。ただし、実際には、ゾーンの_dns-llq._udp。<zone> SRVレコードがLLQを実装していないホストをターゲットとすることは構成エラーであるため、この問題はほとんど理論的なものです。
Note that this protocol is designed for data set sizes of a few dozen resource records at most and change rates no more than once every 10 seconds on average. Data sets that frequently exceed a single IP packet, or that experience a rapid change rate, may have undesirable performance implications.
このプロトコルは、最大で数十のリソースレコードのデータセットサイズ用に設計されており、変更率は平均で10秒に1回以下です。単一のIPパケットを頻繁に超えるデータセット、または急激な変化率が発生するデータセットは、パフォーマンスに望ましくない影響を与える可能性があります。
This section describes constants used in this document.
このセクションでは、このドキュメントで使用される定数について説明します。
EDNS(0) OPTION-CODE (recorded with IANA):
EDNS（0）OPTION-CODE（IANAで記録）：
LLQ 1
LA 1
LLQ-PORT 5352 (recorded with IANA)
LLQ-PORT 5352（IANAで記録）
LLQ Opcodes (specific to this LLQ EDNS(0) Option):
LLQオペコード（このLLQ EDNS（0）オプションに固有）：
LLQ-SETUP 1 LLQ-REFRESH 2 LLQ-EVENT 3
LLQ-SETUP 1 LLQ-REFRESH 2 LLQ-EVENT 3
LLQ Error Codes (specific to this LLQ EDNS(0) Option):
LLQエラーコード（このLLQ EDNS（0）オプションに固有）：
NO-ERROR 0 SERV-FULL 1 STATIC 2 FORMAT-ERR 3 NO-SUCH-LLQ 4 BAD-VERS 5 UNKNOWN-ERR 6
NO-ERROR 0 SERV-FULL 1 STATIC 2 FORMAT-ERR 3 NO-SUCH-LLQ 4 BAD-VERS 5 UNKNOWN-ERR 6
As required by the EDNS(0) specification [RFC6891], all OPT pseudo-RRs used in LLQs are formatted as follows:
EDNS（0）仕様[RFC6891]で要求されているように、LLQで使用されるすべてのOPT擬似RRは次のようにフォーマットされます。
+------------+--------------+-------------------------+
| Field Name | Field Type | Description |
+============+==============+=========================+
| NAME | domain name | MUST be 0 (root domain) |
+------------+--------------+-------------------------+
| TYPE | u_int16_t | OPT (41) |
+------------+--------------+-------------------------+
| CLASS | u_int16_t | 0* |
+------------+--------------+-------------------------+
| TTL | u_int32_t | 0 |
+------------+--------------+-------------------------+
| RDLEN | u_int16_t | length of all RDATA |
+------------+--------------+-------------------------+
| RDATA | octet stream | (see below) |
+------------+--------------+-------------------------+
Table 1: OPT-RRs Used in LLQs
表1：LLQで使用されるOPT-RR
* The CLASS field indicates, as per the EDNS(0) specification [RFC6891], the sender's UDP payload size. However, clients and servers are not required to determine their reassembly buffer size, path MTU, etc., to support LLQ. Thus, the sender of an LLQ Request or Response MAY set the CLASS field to 0. The recipient MUST ignore the class field if it is set to 0.
* CLASSフィールドは、EDNS（0）仕様[RFC6891]に従って、送信者のUDPペイロードサイズを示します。ただし、クライアントとサーバーは、LLQをサポートするために、再構成バッファーサイズ、パスMTUなどを決定する必要はありません。したがって、LLQ要求または応答の送信者は、CLASSフィールドを0に設定することができます。0に設定されている場合、受信者はクラスフィールドを無視する必要があります。
The RDATA of an EDNS(0) OPT pseudo-RR consists of zero or more options of the form { OPTION-CODE, OPTION-LENGTH, OPTION-DATA } packed together, with the RDLEN field set accordingly to indicate the total size. An LLQ OPTION is illustrated below. An EDNS(0) OPT pseudo-RR may contain zero or more LLQ OPTIONS in addition to zero or more other EDNS(0) options.
EDNS（0）OPT擬似RRのRDATAは、{OPTION-CODE、OPTION-LENGTH、OPTION-DATA}形式のゼロ以上のオプションで構成され、RDLENフィールドが合計サイズを示すように設定されています。 LLQオプションを以下に示します。 EDNS（0）OPT疑似RRには、0個以上の他のEDNS（0）オプションに加えて、0個以上のLLQ OPTIONSが含まれる場合があります。
+---------------+------------+-------------------------------------+
| Field Name | Field Type | Description |
+===============+============+=====================================+
| OPTION-CODE | u_int16_t | LLQ (1) |
+---------------+------------+-------------------------------------+
| OPTION-LENGTH | u_int16_t | Length of following fields (18) |
+---------------+------------+-------------------------------------+
| LLQ-VERSION | u_int16_t | Version of LLQ protocol implemented |
+---------------+------------+-------------------------------------+
| LLQ-OPCODE | u_int16_t | Identifies LLQ operation |
+---------------+------------+-------------------------------------+
| LLQ-ERROR | u_int16_t | Identifies LLQ errors |
+---------------+------------+-------------------------------------+
| LLQ-ID | u_int64_t | Identifier for an LLQ |
+---------------+------------+-------------------------------------+
| LLQ-LEASE | u_int32_t | Requested or granted life of LLQ, |
| | | in seconds |
+---------------+------------+-------------------------------------+
Table 2: LLQ OPTION
表2：LLQオプション
The size and meaning of the OPTION-CODE and OPTION-LENGTH fields are as described in the EDNS(0) specification [RFC6891]. The remainder of the fields comprise the OPTION-DATA of the EDNS(0) LLQ OPTION. Since for LLQ the OPTION-DATA is a fixed size, in EDNS(0) LLQ OPTIONS the OPTION-LENGTH field always has the value 18.
OPTION-CODEおよびOPTION-LENGTHフィールドのサイズと意味は、EDNS（0）仕様[RFC6891]で説明されているとおりです。残りのフィールドは、EDNS（0）LLQ OPTIONのOPTION-DATAで構成されています。 LLQの場合、OPTION-DATAは固定サイズであるため、EDNS（0）LLQ OPTIONSでは、OPTION-LENGTHフィールドの値は常に18です。
In keeping with Internet convention, all multi-byte numeric quantities (u_int16_t, u_int32_t, and u_int64_t) are represented in big endian byte order (most significant byte first).
インターネットの規則に従って、すべてのマルチバイトの数値（u_int16_t、u_int32_t、およびu_int64_t）はビッグエンディアンのバイト順（最上位バイトが最初）で表されます。
The client requires a mechanism to determine to which server it should send LLQ operations.
クライアントには、LLQ操作を送信するサーバーを決定するメカニズムが必要です。
Additionally, some firewalls block direct communication with a name server on port 53 to avoid spoof responses. However, this direct communication is necessary for LLQs. Thus, servers MAY listen for LLQs on a different port (typically 5352). Clients, therefore, also need a mechanism to determine to which port to send LLQ operations.
さらに、ファイアウォールによっては、ポート53のネームサーバーとの直接通信をブロックして、なりすましの応答を回避します。ただし、この直接通信はLLQに必要です。したがって、サーバーは別のポート（通常5352）でLLQをリッスンできます（MAY）。したがって、クライアントには、LLQ操作を送信するポートを決定するメカニズムも必要です。
The client determines the server responsible for a given LLQ much as a client determines to which server to send a DNS dynamic update. The client begins by sending a standard DNS query for the name of the LLQ, with type SOA. If the record exists, then the server MUST answer with that SOA record in the Answer section. If a record of type SOA with the LLQ name does not exist, then the server SHOULD include an SOA record for that name's zone in the Authority section. For example, a query for "_ftp._tcp.example.com" with type SOA, when there is no SOA record with that name, might return an SOA record named "example.com" in the Authority section. If the named SOA record does not exist and the server fails to include the enclosing SOA record in the Authority section, the client strips the leading label from the name and tries again, repeating until an answer is received.
クライアントは、クライアントがDNS動的更新を送信するサーバーを決定するのと同じように、特定のLLQを担当するサーバーを決定します。クライアントはまず、タイプSOAのLLQの名前の標準DNSクエリを送信します。レコードが存在する場合、サーバーはAnswerセクションのSOAレコードで応答する必要があります。 LLQ名を持つタイプSOAのレコードが存在しない場合、サーバーはそのセクションにその名前のゾーンのSOAレコードを含める必要があります（SHOULD）。たとえば、SOAタイプの「_ftp._tcp.example.com」に対するクエリは、その名前のSOAレコードがない場合、Authorityセクションで「example.com」という名前のSOAレコードを返す可能性があります。名前付きSOAレコードが存在せず、サーバーがAuthorityセクションに囲みSOAレコードを含めない場合、クライアントは名前から先頭のラベルを取り除いて、再試行し、回答を受け取るまで繰り返します。
This iterative zone apex discovery algorithm is described in more detail in the DNS Push Notifications specification [RFC8765].
この反復ゾーン頂点検出アルゴリズムは、DNSプッシュ通知仕様[RFC8765]で詳細に説明されています。
Upon learning the zone apex (SOA), the client then constructs and sends an SRV query for the name, "_dns-llq._udp.<zone>", e.g., "_dns-llq._udp.example.com".
ゾーンの頂点（SOA）を学習すると、クライアントは名前「_dns-llq._udp。<zone>」、たとえば「_dns-llq._udp.example.com」のSRVクエリを作成して送信します。
An authoritative server for a zone implementing LLQ MUST answer with an SRV record [RFC2782] for this name. The SRV RDATA is as follows:
LLQを実装するゾーンの権限のあるサーバーは、この名前のSRVレコード[RFC2782]で応答する必要があります。 SRV RDATAは次のとおりです。
+----------+------------------------------------------------------+
| PRIORITY | typically 0 |
+----------+------------------------------------------------------+
| WEIGHT | typically 0 |
+----------+------------------------------------------------------+
| PORT | typically 53 or 5352 |
+----------+------------------------------------------------------+
| TARGET | name of server providing LLQs for the requested zone |
+----------+------------------------------------------------------+
Table 3: SRV RDATA
表3：SRV RDATA
The server SHOULD include the address record(s) for the target host in the Additional section of the response.
サーバーは、応答の「追加」セクションにターゲットホストのアドレスレコードを含める必要があります（SHOULD）。
If the server does not include the target host's address record(s) in the Additional section, the client SHOULD query explicitly for the address record(s) with the name of the SRV target.
サーバーが追加セクションにターゲットホストのアドレスレコードを含めない場合、クライアントはSRVターゲットの名前を使用してアドレスレコードを明示的に照会する必要があります（SHOULD）。
The client MUST send all LLQ requests, refreshes, and acknowledgments to the name server specified in the SRV target, at the address contained in the address record for that target. Note that the queries described in this section (including those for SOA and SRV records) MAY be sent to an intermediate DNS recursive resolver -- they need not be sent directly to the name server.
クライアントは、SRVターゲットで指定されたネームサーバーに、そのターゲットのアドレスレコードに含まれているアドレスで、すべてのLLQ要求、更新、および確認応答を送信する必要があります。このセクションで説明するクエリ（SOAおよびSRVレコードのクエリを含む）は、中間DNS再帰リゾルバに送信できます（ネームサーバーに直接送信する必要はありません）。
If, on issuing the SRV query, the client receives a negative response indicating that the SRV record does not exist, the client SHOULD conclude that the zone does not support LLQ. The client then SHOULD NOT send an LLQ request for the desired name, instead utilizing the behavior for LLQ-unaware servers described in Section 5, "LLQ Setup".
SRVクエリの発行時に、クライアントがSRVレコードが存在しないことを示す否定応答を受け取った場合、クライアントはゾーンがLLQをサポートしていないと結論付ける必要があります（SHOULD）。次にクライアントは、セクション5「LLQセットアップ」で説明されているLLQ非対応サーバーの動作を利用する代わりに、目的の名前のLLQリクエストを送信すべきではありません（SHOULD NOT）。
Servers should send all messages to the source address and port of the LLQ setup message received from the client.
サーバーは、クライアントから受信したLLQセットアップメッセージのソースアドレスとポートにすべてのメッセージを送信する必要があります。
An LLQ is initiated by a client and is completed via a four-way handshake. This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial-of-service attack opportunities (see Section 8, "Security Considerations").
LLQはクライアントによって開始され、4ウェイハンドシェイクを介して完了します。このハンドシェイクにより、パケット損失に対する回復力が提供され、クライアントの到達可能性が実証され、サービス拒否攻撃の機会が減少します（「セキュリティに関する考慮事項」を参照）。
LLQ Setup Requests and Responses sent by the client SHOULD be retransmitted if no acknowledgments are received. The client SHOULD retry up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST wait at least 2 seconds before the first retransmission and 4 seconds between the first and second retransmissions. The client SHOULD listen for a response for at least 8 seconds after the 3rd attempt before considering the server down or unreachable. Upon determining a server to be down, a client MAY periodically attempt to re-initiate an LLQ setup at a rate of not more than once per hour.
クライアントから送信されたLLQセットアップ要求と応答は、確認応答が受信されない場合に再送信する必要があります（SHOULD）。クライアントは、サーバーがダウンしているか到達不能であると見なす前に、最大2回（合計3回）再試行する必要があります（SHOULD）。クライアントは、最初の再送信の前に少なくとも2秒、最初と2番目の再送信の間に4秒待機する必要があります。クライアントは、3回目の試行後、サーバーがダウンしているか到達不能であると見なす前に、少なくとも8秒間応答をリッスンする必要があります（SHOULD）。サーバーがダウンしていると判断すると、クライアントは1時間に1回以下の速度でLLQセットアップの再開始を定期的に試みてもよい（MAY）。
Servers MUST NOT retransmit acknowledgments that do not generate responses from the client. Retransmission in setup is client driven, freeing servers from maintaining timers for incomplete LLQ setups. If servers receive duplicate messages from clients (perhaps due to the loss of the server's responses mid-flight), the server MUST resend its reply (possibly modifying the LLQ-LEASE as described in Section 5.2.4, "ACK + Answers").
サーバーは、クライアントからの応答を生成しない確認応答を再送信してはなりません（MUST NOT）。セットアップでの再送信はクライアント主導であり、不完全なLLQセットアップのタイマーを維持することからサーバーを解放します。サーバーがクライアントから重複したメッセージを受信した場合（おそらくサーバーの応答が途中で失われたため）、サーバーはその応答を再送信する必要があります（セクション5.2.4「ACK +回答」で説明されているようにLLQ-LEASEを変更する可能性があります）。
Servers MUST NOT garbage collect LLQs that fail to complete the four-way handshake until the initially granted LLQ-LEASE has elapsed.
サーバーは、最初に許可されたLLQ-LEASEが経過するまで、4ウェイハンドシェイクを完了できないLLQをガベージコレクションしてはなりません（MUST NOT）。
The four phases of the handshake include:
ハンドシェイクの4つのフェーズは次のとおりです。
1) Setup Request client to server, identifies LLQ(s) requested
1）クライアントからサーバーへのセットアップ要求、要求されたLLQを識別
2) Setup Challenge server to client, provides unique identifiers for successful requested LLQs, and error(s) for unsuccessful requested LLQs.
2）クライアントにチャレンジサーバーをセットアップし、要求された成功したLLQに一意の識別子を提供し、失敗した要求されたLLQにエラーを提供します。
3) Challenge Response client to server, echoes identifier(s), demonstrating client's reachability and willingness to participate
3）サーバーへのチャレンジレスポンスクライアント、識別子のエコー、クライアントの到達可能性と参加意欲の証明
4) ACK + Answers server to client, confirms setup and provides initial answers
4）サーバーへのACK +応答、クライアントへの応答、セットアップの確認、および初期応答の提供
A request for an LLQ is formatted like a standard DNS query but with an OPT pseudo-RR containing LLQ metadata in its Additional section. LLQ Setup Requests are identified by the LLQ-SETUP opcode and a zero-valued LLQ-ID.
LLQのリクエストは標準のDNSクエリのようにフォーマットされますが、追加セクションにLLQメタデータを含むOPT疑似RRが含まれます。 LLQセットアップ要求は、LLQ-SETUPオペコードとゼロ値のLLQ-IDによって識別されます。
The request MAY contain multiple questions to set up multiple LLQs. A Setup Request consisting of multiple questions MUST contain multiple LLQ OPTIONS, one per question, with the LLQ OPTIONS in the same order as the questions they correspond to (i.e., the first LLQ OPTION corresponds to the first question, the second LLQ OPTION corresponds to the second question, etc.). If requesting multiple LLQs, clients SHOULD request the same LLQ-LEASE for each LLQ. Requests over UDP MUST NOT contain multiple questions if doing so would cause the message to exceed a single IP packet.
リクエストには、複数のLLQを設定するための複数の質問が含まれる場合があります。複数の質問で構成されるセットアップ要求には、質問ごとに1つずつ、複数のLLQオプションが含まれている必要があります。LLQオプションは、対応する質問と同じ順序です（つまり、最初のLLQオプションは最初の質問に対応し、2番目のLLQオプションは2番目の質問など）。複数のLLQを要求する場合、クライアントは各LLQに対して同じLLQ-LEASEを要求する必要があります（SHOULD）。メッセージが単一のIPパケットを超える場合は、UDPを介した要求に複数の質問を含めることはできません。
A client MUST NOT request multiple identical LLQs (i.e., containing the same qname/type/class) from the same source IP address and port. This requirement is to avoid unnecessary load on servers. In the case of multiple independent client implementations that may run on the same device without knowledge of each other, it is allowable if they by chance send LLQ requests for the same qname/type/class. These independent implementations on the same client will be using different source ports. Likewise, to the server, multiple independent clients behind the same NAT gateway will appear as if they were multiple independent clients using different ports on the same host, and this is also allowable.
クライアントは、同じ送信元IPアドレスとポートから複数の同一のLLQ（つまり、同じqname / type / classを含む）を要求してはなりません（MUST NOT）。この要件は、サーバーへの不要な負荷を回避するためのものです。複数の独立したクライアント実装が相互に認識せずに同じデバイスで実行される可能性がある場合、偶然に同じqname / type / classのLLQ要求を送信することは許容されます。同じクライアントでのこれらの独立した実装は、異なる送信元ポートを使用します。同様に、サーバーからは、同じNATゲートウェイの背後にある複数の独立したクライアントは、同じホストの異なるポートを使用する複数の独立したクライアントのように見えますが、これも許容されます。
The query MUST NOT be for record type ANY (255), class ANY (255), or class NONE (0).
クエリは、レコードタイプANY（255）、クラスANY（255）、またはクラスNONE（0）に対するものであってはなりません（MUST NOT）。
+---------------+------------+---------------------------------+
| Field Name | Field Type | Description |
+===============+============+=================================+
| OPTION-CODE | u_int16_t | LLQ (1) |
+---------------+------------+---------------------------------+
| OPTION-LENGTH | u_int16_t | Length of following fields (18) |
+---------------+------------+---------------------------------+
| LLQ-VERSION | u_int16_t | Version of LLQ protocol |
| | | implemented by requester (1) |
+---------------+------------+---------------------------------+
| LLQ-OPCODE | u_int16_t | LLQ-SETUP (1) |
+---------------+------------+---------------------------------+
| LLQ-ERROR | u_int16_t | NO-ERROR (0) |
+---------------+------------+---------------------------------+
| LLQ-ID | u_int64_t | 0 |
+---------------+------------+---------------------------------+
| LLQ-LEASE | u_int32_t | Desired life of LLQ request |
+---------------+------------+---------------------------------+
Table 4: Setup Request LLQ OPTION Format
表4：セットアップ要求のLLQ OPTION形式
The Setup Request LLQ OPTION MUST be repeated once for each additional query in the Question section.
セットアップセクションのLLQオプションは、質問セクションの追加のクエリごとに1回繰り返す必要があります。
Upon receiving an LLQ Setup Request, a server implementing LLQs will send a Setup Challenge to the requester (client). An LLQ Setup Challenge is a DNS response, with the DNS message ID matching that of the Setup Request, and with all questions contained in the Setup Request present in the Question section of the response. Additionally, the challenge contains a single OPT pseudo-RR with an LLQ OPTION for each LLQ request, indicating the success or failure of each request. The LLQ OPTIONS MUST be in the same order as the questions they correspond to. Note that in a Setup Request containing multiple questions, some LLQs may succeed while others may fail.
LLQセットアップリクエストを受信すると、LLQを実装するサーバーはリクエスタ（クライアント）にセットアップチャレンジを送信します。 LLQセットアップチャレンジはDNS応答であり、DNSメッセージIDはセットアップ要求と一致し、セットアップ要求に含まれるすべての質問は応答の[質問]セクションに表示されます。さらに、チャレンジには、各LLQ要求のLLQ OPTIONを持つ単一のOPT疑似RRが含まれ、各要求の成功または失敗を示します。 LLQオプションは、対応する質問と同じ順序である必要があります。複数の質問を含むセットアップ要求では、一部のLLQが成功する場合と失敗する場合があることに注意してください。
+---------------+------------+---------------------------------+
| Field Name | Field Type | Description |
+===============+============+=================================+
| OPTION-CODE | u_int16_t | LLQ (1) |
+---------------+------------+---------------------------------+
| OPTION-LENGTH | u_int16_t | Length of following fields (18) |
+---------------+------------+---------------------------------+
| LLQ-VERSION | u_int16_t | Version of LLQ protocol |
| | | implemented in server (1) |
+---------------+------------+---------------------------------+
| LLQ-OPCODE | u_int16_t | LLQ-SETUP (1) |
+---------------+------------+---------------------------------+
| LLQ-ERROR | u_int16_t | [As Appropriate] |
+---------------+------------+---------------------------------+
| LLQ-ID | u_int64_t | [As Appropriate] |
+---------------+------------+---------------------------------+
| LLQ-LEASE | u_int32_t | [As Appropriate] |
+---------------+------------+---------------------------------+
Table 5: Setup Challenge LLQ OPTION Format
表5：セットアップチャレンジLLQ OPTION形式
The Setup Challenge LLQ OPTION MUST be repeated once for each query in the Questions section of the Setup Challenge. Further details for LLQ-ERROR, LLQ-ID and LLQ-LEASE are given below.
セットアップチャレンジのLLQオプションは、セットアップチャレンジの質問セクションにあるクエリごとに1回繰り返す必要があります。 LLQ-ERROR、LLQ-ID、LLQ-LEASEの詳細については、以下をご覧ください。
LLQ-ERROR:
LLQ-ERROR：
NO-ERROR: The LLQ Setup Request was successful.
エラーなし：LLQセットアップ要求は成功しました。
FORMAT-ERR: The LLQ was improperly formatted. Note that if the rest of the DNS message is properly formatted, the DNS header error code MUST NOT include a format error code, since to do so would cause ambiguity between the case where a client sends a valid LLQ Setup Request to a server that does not understand LLQ and the case where a client sends a malformed LLQ Setup Request to a server that does understand LLQ.
FORMAT-ERR：LLQのフォーマットが不適切です。 DNSメッセージの残りの部分が適切にフォーマットされている場合、DNSヘッダーエラーコードにフォーマットエラーコードを含めてはならないことに注意してください。これを行うと、クライアントが有効なLLQセットアップ要求をサーバーに送信するケースが不明確になるためです。 LLQおよびクライアントがLLQを理解しているサーバーに不正なLLQセットアップ要求を送信するケースを理解していません。
SERV-FULL: The server cannot grant the LLQ request because it is overloaded or the request exceeds the server's rate limit (see Section 8, Security Considerations). Upon returning this error, the server MUST include in the LLQ-LEASE field a time interval, in seconds, after which the client may retry the LLQ Setup.
SERV-FULL：LLQ要求が過負荷になっているか、要求がサーバーのレート制限を超えているため、サーバーはLLQ要求を許可できません（セクション8「セキュリティに関する考慮事項」を参照）。このエラーが返されると、サーバーはLLQ-LEASEフィールドに秒単位の時間間隔を含めなければなりません。その後、クライアントはLLQセットアップを再試行できます。
STATIC: The data for this name and type is not expected to change frequently, and the server, therefore, does not support the requested LLQ. The client MUST honor the resource record TTLs returned and MUST NOT poll sooner than indicated by those TTLs, nor should it retry the LLQ Setup for this name and type.
静的：この名前とタイプのデータは頻繁に変更されることは想定されていないため、サーバーは要求されたLLQをサポートしていません。クライアントは、返されたリソースレコードTTLを尊重しなければならず、それらのTTLによって示されるよりも早くポーリングしてはならず、この名前とタイプのLLQセットアップを再試行してはなりません。
BAD-VERS: The protocol version specified in the client's Setup Request is not supported by the server.
BAD-VERS：クライアントのセットアップ要求で指定されたプロトコルバージョンは、サーバーでサポートされていません。
UNKNOWN-ERR: The LLQ was not granted for some other reason not covered by the preceding error code values.
UNKNOWN-ERR：LLQは、前述のエラーコード値ではカバーされないその他の理由で許可されませんでした。
LLQ-ID: On success, a random number generated by the server that is unique on the server for the requested name/type/class. The LLQ-ID SHOULD be an unpredictable random number. A possible method of allocating LLQ-IDs with minimal bookkeeping would be to store the time, in seconds since the Epoch, in the high 32 bits of the field, and a cryptographically generated 32-bit random integer in the low 32 bits.
LLQ-ID：成功した場合、サーバーによって生成された、要求された名前/タイプ/クラスのサーバー上で一意の乱数。 LLQ-IDは、予測不可能な乱数である必要があります（SHOULD）。最小限の簿記でLLQ-IDを割り当てる可能な方法は、エポックからの秒数でフィールドの上位32ビットに時間を格納し、暗号で生成された32ビットランダム整数を下位32ビットに格納することです。
On error, the LLQ-ID is set to 0.
エラーの場合、LLQ-IDは0に設定されます。
LLQ-LEASE: On success, the actual life of the LLQ, in seconds. Value may be greater than, less than, or equal to the value requested by the client, as per the server administrator's policy. The server MAY discard the LLQ after this LLQ-LEASE expires unless the LLQ has been renewed by the client (see Section 7, "LLQ Lease-Life Expiration"). The server MUST NOT generate events (see Section 6, "Event Responses") for expired LLQs.
LLQ-LEASE：成功した場合の、LLQの実際の寿命（秒単位）。値は、サーバー管理者のポリシーに従って、クライアントから要求された値より大きい、小さい、または等しい場合があります。クライアントがLLQを更新していない限り、サーバーはこのLLQ-LEASEの有効期限が切れた後、LLQを破棄できます（セクション7、「LLQリースライフの有効期限」を参照）。サーバーは、期限切れのLLQに対してイベント（セクション6、「イベント応答」を参照）を生成してはならない（MUST NOT）。
On SERV-FULL error, LLQ-LEASE MUST be set to a time interval, in seconds, after which the client may retry the LLQ Setup.
SERV-FULLエラーでは、LLQ-LEASEを秒単位の時間間隔に設定する必要があります。その後、クライアントはLLQセットアップを再試行できます。
On other errors, the LLQ-LEASE MUST be set to 0.
その他のエラーでは、LLQ-LEASEを0に設定する必要があります。
Upon issuing a Setup Request, a client listens for a Setup Challenge (Section 5.2.2) retransmitting the Setup Request as necessary (Section 5.1). After receiving a successful Setup Challenge, the client SHOULD send a Challenge Response to the server. This Challenge Response is a DNS request with questions as in the Setup Request and Setup Challenge, and a single OPT pseudo-RR in the Additional section, with the LLQ OPTIONS corresponding to the LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for each LLQ OPTION, the random LLQ-ID and the granted LLQ-LEASE). If the Challenge Response contains multiple questions, the first question MUST correspond to the first LLQ OPTION, etc.
セットアップ要求を発行すると、クライアントはセットアップ要求（セクション5.2.2）をリッスンし、必要に応じてセットアップ要求を再送信します（セクション5.1）。セットアップチャレンジを正常に受信した後、クライアントはチャレンジレスポンスをサーバーに送信する必要があります（SHOULD）。このチャレンジレスポンスは、セットアップリクエストとセットアップチャレンジと同様の質問を含むDNSリクエストであり、追加セクションに単一のOPT擬似RRがあり、LLQ OPTIONSはセットアップチャレンジに含まれるLLQ OPTIONSに対応しています（つまり、各LLQオプション、ランダムLLQ-ID、および付与されたLLQ-LEASE）。チャレンジレスポンスに複数の質問が含まれている場合、最初の質問は最初のLLQオプションなどに対応している必要があります。
If the Setup Request for a particular LLQ fails with a STATIC error, the client MUST NOT poll the server for that LLQ. The client SHOULD honor the resource record TTLs contained in the response.
特定のLLQのセットアップ要求がSTATICエラーで失敗した場合、クライアントはそのLLQについてサーバーをポーリングしてはなりません（MUST NOT）。クライアントは、応答に含まれるリソースレコードTTLを尊重する必要があります（SHOULD）。
If a Setup Request fails with a SERV-FULL error, the client MAY retry the LLQ Setup Request (Section 5.2.1) after the time indicated in the LLQ-LEASE field.
セットアップ要求がSERV-FULLエラーで失敗した場合、クライアントはLLQ-LEASEフィールドに示された時間の後にLLQセットアップ要求（セクション5.2.1）を再試行できます（MAY）。
If the Setup Request fails with an error other than STATIC or SERV-FULL, or the server is determined not to support LLQ (i.e., the client receives a DNS response with a nonzero RCODE, or a DNS response containing no LLQ option), the client MAY poll the server periodically with standard DNS queries, inferring Add and Remove Events (see Section 6, "Event Responses") by comparing answers to these queries. The client SHOULD NOT poll more than once every 15 minutes for a given query. The client MUST NOT poll if it receives a STATIC error code in the acknowledgment.
STATICまたはSERV-FULL以外のエラーでセットアップ要求が失敗した場合、またはサーバーがLLQをサポートしていないと判断された場合（つまり、クライアントがゼロ以外のRCODEを含むDNS応答、またはLLQオプションを含まないDNS応答を受信した場合）、クライアントは、標準のDNSクエリを使用してサーバーを定期的にポーリングし、これらのクエリに対する回答を比較することにより、イベントの追加と削除（セクション6「イベント応答」を参照）を推測できます。クライアントは、指定されたクエリについて15分ごとに複数回ポーリングするべきではありません（SHOULD NOT）。クライアントは、肯定応答でSTATICエラーコードを受信した場合、ポーリングしてはなりません（MUST NOT）。
Upon receiving a correct Challenge Response, a server MUST return an acknowledgment, completing the LLQ setup, and provide all current answers to the question(s).
正しいチャレンジレスポンスを受信すると、サーバーは確認応答を返し、LLQセットアップを完了し、質問に対する現在のすべての回答を提供する必要があります。
To acknowledge a successful Challenge Response, i.e., a Challenge Response in which the LLQ-ID and LLQ-LEASE echoed by the client match the values issued by the server, the server MUST send a DNS response containing all available answers to the question(s) contained in the original Setup Request, along with all additional resource records appropriate for those answers in the Additional section. The Additional section also contains LLQ OPTIONS formatted as follows:
成功したチャレンジ応答、つまり、クライアントによってエコーされたLLQ-IDとLLQ-LEASEがサーバーによって発行された値と一致するチャレンジ応答を確認するには、サーバーは質問に対するすべての利用可能な回答を含むDNS応答を送信する必要があります）元のセットアップ要求に含まれ、追加セクションの回答に適切なすべての追加リソースレコードが含まれます。追加セクションには、次のようなフォーマットのLLQオプションも含まれます。
+---------------+------------+---------------------------------+
| Field Name | Field Type | Description |
+===============+============+=================================+
| OPTION-CODE | u_int16_t | LLQ (1) |
+---------------+------------+---------------------------------+
| OPTION-LENGTH | u_int16_t | Length of following fields (18) |
+---------------+------------+---------------------------------+
| LLQ-VERSION | u_int16_t | Version of LLQ protocol |
| | | implemented in server (1) |
+---------------+------------+---------------------------------+
| LLQ-OPCODE | u_int16_t | LLQ-SETUP (1) |
+---------------+------------+---------------------------------+
| LLQ-ERROR | u_int16_t | NO-ERROR (0) |
+---------------+------------+---------------------------------+
| LLQ-ID | u_int64_t | Originally granted ID, echoed |
| | | in client's Response |
+---------------+------------+---------------------------------+
| LLQ-LEASE | u_int32_t | Remaining life of LLQ, in |
| | | seconds |
+---------------+------------+---------------------------------+
Table 6: Successful ACK + Answers LLQ OPTION Format
表6：成功したACK +応答LLQ OPTION形式
If there is a significant delay in receiving a Challenge Response, or multiple Challenge Responses are issued (possibly because they were lost en route to the client, causing the client to resend the Challenge Response), the server MAY decrement the LLQ-LEASE by the time elapsed since the Setup Challenge was initially issued.
チャレンジレスポンスの受信に大幅な遅延がある場合、または複数のチャレンジレスポンスが発行された場合（クライアントへの途中で失われ、クライアントがチャレンジレスポンスを再送信したことが原因である可能性があります）、サーバーはLLQ-LEASEをセットアップチャレンジが最初に発行されてからの経過時間
If the setup is completed over UDP and all initially available answers to the question(s), additional records, and the OPT pseudo-RR do not fit in a single IP packet, some or all additional records (excluding the OPT pseudo-RR) MUST be omitted. If, after omission of all additional records, the answers still do not fit in a single message, answers MUST be removed until the message fits in a single IP packet. These answers not delivered in the ACK + Answers MUST be delivered without undue delay to the client via Add Events (Section 6, "Event Responses").
セットアップがUDPで完了し、最初に利用可能なすべての質問に対する回答、追加のレコード、およびOPT疑似RRが単一のIPパケットに適合しない場合、一部またはすべての追加のレコード（OPT疑似RRを除く）省略する必要があります。追加のレコードをすべて省略しても、回答が1つのメッセージに収まらない場合は、メッセージが1つのIPパケットに収まるまで回答を削除する必要があります。 ACK + Answersで配信されないこれらの回答は、Add Events（セクション6、「Event Responses」）を介して過度の遅延なしにクライアントに配信される必要があります。
The TTLs of resource records contained in answers to successful LLQs SHOULD be ignored by the client. The client MAY cache LLQ answers until the client receives a gratuitous announcement (see Section 6, "Event Responses") indicating that the answer to the LLQ has changed. The client SHOULD NOT cache answers after the LLQs LLQ-LEASE expires without being refreshed (see Section 7, "LLQ Lease-Life Expiration"). If an LLQ request fails, the client SHOULD NOT cache answers for a period longer than the client's polling interval.
成功したLLQへの回答に含まれているリソースレコードのTTLは、クライアントによって無視されるべきです（SHOULD）。クライアントは、LLQへの応答が変更されたことを示す不当なアナウンス（セクション6「イベント応答」を参照）を受信するまで、LLQ応答をキャッシュしてもよい（MAY）。 LLQのLLQ-LEASEが更新されずに期限切れになった後、クライアントは回答をキャッシュしないでください（セクション7「LLQのリース期間の期限切れ」を参照）。 LLQ要求が失敗した場合、クライアントはクライアントのポーリング間隔よりも長い期間、応答をキャッシュしてはなりません（SHOULD NOT）。
Note that resource records intended specifically to be transmitted via LLQs (e.g., DNS-based Service Discovery resource records) may have unusually short TTLs. This is because it is assumed that the records may change frequently, and that a client's cache coherence will be maintained via the LLQ and gratuitous responses. Short TTLs prevent stale information from residing in intermediate DNS recursive resolvers that are not LLQ aware.
特にLLQを介して送信することを目的としたリソースレコード（DNSベースのサービスディスカバリリソースレコードなど）のTTLは異常に短い場合があることに注意してください。これは、レコードが頻繁に変更される可能性があり、クライアントのキャッシュコヒーレンスがLLQと無償の応答によって維持されることが想定されているためです。短いTTLは、LLQに対応していない中間DNS再帰リゾルバーに古い情報が存在しないようにします。
TTLs of resource records included in the Additional section of an LLQ response (which do not directly answer the LLQ) SHOULD be honored by the client.
LLQ応答（LLQに直接応答しない）の追加セクションに含まれるリソースレコードのTTLは、クライアントによって尊重されるべきです（SHOULD）。
When a change ("event") occurs to a name server's zone, the server MUST check if the new or deleted resource records answer any LLQs. If so, the changes MUST be communicated to the LLQ requesters in the form of a gratuitous DNS response sent to the client, with the relevant question(s) in the Question section, and the corresponding answers in the Answer section. The response also includes an OPT pseudo-RR in the Additional section. This OPT pseudo-RR contains, in its RDATA, an LLQ OPTION for each LLQ being answered in the message. Each LLQ OPTION must include the LLQ-ID. This reduces the potential for spoof events being sent to a client.
ネームサーバーのゾーンに変更（「イベント」）が発生すると、サーバーは、新規または削除されたリソースレコードがLLQに応答するかどうかを確認する必要があります。もしそうなら、変更はクライアントに送信される無料のDNS応答の形式でLLQリクエスタに伝達されなければならず、関連する質問が質問セクションにあり、対応する回答が回答セクションにあります。応答には、追加セクションにOPT疑似RRも含まれています。このOPT疑似RRのRDATAには、メッセージで応答される各LLQのLLQオプションが含まれています。各LLQオプションにはLLQ-IDを含める必要があります。これにより、なりすましイベントがクライアントに送信される可能性が低くなります。
+---------------+------------+---------------------------------+
| Field Name | Field Type | Description |
+===============+============+=================================+
| OPTION-CODE | u_int16_t | LLQ (1) |
+---------------+------------+---------------------------------+
| OPTION-LENGTH | u_int16_t | Length of following fields (18) |
+---------------+------------+---------------------------------+
| LLQ-VERSION | u_int16_t | Version of LLQ protocol |
| | | implemented in server (1) |
+---------------+------------+---------------------------------+
| LLQ-OPCODE | u_int16_t | LLQ-EVENT (3) |
+---------------+------------+---------------------------------+
| LLQ-ERROR | u_int16_t | NO-ERROR (0) |
+---------------+------------+---------------------------------+
| LLQ-ID | u_int64_t | [As Appropriate] |
+---------------+------------+---------------------------------+
| LLQ-LEASE | u_int32_t | 0 |
+---------------+------------+---------------------------------+
Table 7: Event Response LLQ OPTION Format
表7：イベント応答LLQ OPTION形式
Gratuitous responses for a single LLQ MAY be batched such that multiple changes are communicated in a single message. Responses MUST NOT be batched if this would cause a message that would otherwise fit in a single IP packet to be truncated. While responses MAY be deferred to provide opportunities for batching, responses SHOULD NOT be delayed, for purposes of batching, for more than 30 seconds, as this would cause an unacceptable latency for the client.
単一のLLQに対する不要な応答は、複数の変更が単一のメッセージで伝達されるようにバッチ処理される場合があります。これにより、1つのIPパケットに収まるメッセージが切り捨てられる場合は、応答をバッチ処理しないでください。応答はバッチ処理の機会を提供するために延期される場合がありますが、応答がバッチ処理の目的で30秒を超えて遅延してはなりません。これはクライアントに許容できない遅延を引き起こすためです。
After sending a gratuitous response, the server MUST listen for an acknowledgment from the client. If the client does not respond, the server MUST resend the response. The server MUST resend two times (for a total of 3 transmissions), after which the server MUST consider the client to be unreachable and delete its LLQ. The server MUST listen for 2 seconds before resending the response, 4 more seconds before resending again, and must wait an additional 8 seconds after the 3rd transmission before terminating the LLQ.
不要な応答を送信した後、サーバーはクライアントからの確認応答をリッスンする必要があります。クライアントが応答しない場合、サーバーは応答を再送信する必要があります。サーバーは2回（合計3回の送信に対して）再送信しなければならず（MUST）、その後サーバーはクライアントが到達不能であると見なしてLLQを削除しなければなりません（MUST）。サーバーは、応答を再送信する前に2秒間リッスンし、再度再送信する前にさらに4秒間リッスンする必要があります。LLQを終了する前に、3番目の送信からさらに8秒待機する必要があります。
The DNS message header of the response SHOULD include an unpredictable random number in the DNS message ID field, which is to be echoed in the client's acknowledgment.
応答のDNSメッセージヘッダーは、クライアントの確認でエコーされるDNSメッセージIDフィールドに予測不可能な乱数を含める必要があります（SHOULD）。
Add Events occur when a new resource record appears, usually as the result of a dynamic update [RFC2136], that answers an LLQ. This record must be sent in the Answer section of the event to the client. Records that normally accompany this record in responses MAY be included in the Additional section as per truncation restrictions described above.
イベントの追加は、通常、動的更新[RFC2136]の結果として、LLQに応答する新しいリソースレコードが表示されたときに発生します。このレコードは、イベントの回答セクションでクライアントに送信する必要があります。応答で通常このレコードに付随するレコードは、上記の切り捨て制限に従って追加セクションに含まれる場合があります。
Remove Events occur when a resource record previously sent to a client, either in an initial response or in an Add Event, becomes invalid (normally as a result of being removed via a dynamic update). The deleted resource record is sent in the Answer section of the event to the client. The resource record TTL is set to -1, indicating that the record has been removed.
削除イベントは、以前にクライアントに送信されたリソースレコードが初期応答または追加イベントで無効になったときに発生します（通常、動的更新によって削除された結果として）。削除されたリソースレコードは、イベントの[回答]セクションでクライアントに送信されます。リソースレコードのTTLは-1に設定され、レコードが削除されたことを示します。
Upon receiving a gratuitous response ("event"), the client MUST send an acknowledgment to the server. This acknowledgment is a DNS response echoing the OPT pseudo-RR contained in the event, with the message ID of the gratuitous response echoed in the message header. The acknowledgment MUST be sent to the source IP address and port from which the event originated.
不要な応答（「イベント」）を受信すると、クライアントはサーバーに確認応答を送信する必要があります。この確認応答は、イベントに含まれているOPT疑似RRをエコーするDNS応答であり、メッセージヘッダーにエコーされる無償応答のメッセージIDが含まれます。確認は、イベントが発生した送信元IPアドレスとポートに送信する必要があります。
If the client desires to maintain the LLQ beyond the duration specified in the LLQ-LEASE field of the ACK + Answers (Section 5.2.4), the client MUST send a Refresh Request. A Refresh Request is identical to an LLQ Challenge Response (Section 5.2.3) but with the LLQ-OPCODE set to LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request returns no answers.
クライアントがACK + Answers（セクション5.2.4）のLLQ-LEASEフィールドで指定された期間を超えてLLQを維持したい場合、クライアントは更新リクエストを送信しなければなりません（MUST）。更新要求はLLQチャレンジ応答（セクション5.2.3）と同じですが、LLQ-OPCODEがLLQ-REFRESHに設定されています。チャレンジレスポンスとは異なり、更新リクエストは応答を返しません。
The client SHOULD refresh an LLQ when 80% of its LLQ-LEASE has elapsed.
クライアントは、LLQ-LEASEの80％が経過したときにLLQを更新する必要があります（SHOULD）。
As a means of reducing network traffic, when constructing refresh messages the client SHOULD include all LLQs established with a given server, even those not yet close to expiration. However, at least one LLQ MUST have elapsed at least 80% of its original LLQ-LEASE. The client MUST NOT include additional LLQs if doing so would cause the message to no longer fit in a single IP packet. In this case, the LLQs furthest from expiration should be omitted such that the message fits in a single IP packet. (These LLQs SHOULD be refreshed in a separate message when 80% of one or more of their lease lives have elapsed.) When refreshing multiple LLQs simultaneously, the message contains multiple questions and a single OPT pseudo-RR with multiple LLQ OPTIONS, one per question, with the LLQ OPTIONS in the same order as the questions they correspond to.
ネットワークトラフィックを削減する手段として、更新メッセージを作成する場合、クライアントは、指定されたサーバーで確立されたすべてのLLQを含める必要があります。ただし、少なくとも1つのLLQが元のLLQ-LEASEの少なくとも80％を経過している必要があります。メッセージが単一のIPパケットに収まらなくなる原因となる場合、クライアントは追加のLLQを含めてはなりません（MUST NOT）。この場合、メッセージが単一のIPパケットに収まるように、有効期限から最も遠いLLQを省略する必要があります。 （これらのLLQは、1つ以上のリースライフの80％が経過したときに、別のメッセージで更新する必要があります。）複数のLLQを同時に更新すると、メッセージには複数の質問と複数のLLQオプションを持つ1つのOPT疑似RRが含まれます。質問、LLQオプションは、対応する質問と同じ順序で
The client SHOULD specify the original LLQ-LEASE granted in the LLQ response as the desired LLQ-LEASE in the Refresh Request. If refreshing multiple LLQs simultaneously, the client SHOULD request the same LLQ-LEASE for all LLQs being refreshed (with the exception of termination requests; see below).
クライアントは、リフレッシュ要求で必要なLLQ-LEASEとして、LLQ応答で許可された元のLLQ-LEASEを指定する必要があります（SHOULD）。複数のLLQを同時に更新する場合、クライアントは、更新されるすべてのLLQに対して同じLLQ-LEASEを要求する必要があります（終了要求を除く。以下を参照）。
To terminate an LLQ prior to its scheduled expiration (for instance, when the client terminates a DNS-based Service Discovery browse operation or when a client is about to go to sleep or shut down), the client specifies an LLQ-LEASE value of 0.
スケジュールされた有効期限の前にLLQを終了するには（たとえば、クライアントがDNSベースのサービスディスカバリのブラウズ操作を終了したとき、またはクライアントがスリープまたはシャットダウンしようとしているとき）、クライアントはLLQ-LEASE値として0を指定します。 。
The client MUST listen for an acknowledgment from the server. The client MAY retry up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST NOT retry a first time before 90% of the LLQ-LEASE has expired and MUST NOT retry again before 95% of the LLQ-LEASE has expired. If the server is determined to be down, the client MAY periodically attempt to re-establish the LLQ via an LLQ Setup Request message. The client MUST NOT attempt the LLQ Setup Request more than once per hour.
クライアントはサーバーからの確認応答をリッスンする必要があります。クライアントは、サーバーがダウンしているか到達不能であると見なす前に、さらに最大2回（合計3回）再試行してもよい（MAY）。クライアントは、LLQ-LEASEの90％が期限切れになる前に最初に再試行してはならず、LLQ-LEASEの95％が期限切れになる前に再試行してはなりません。サーバーがダウンしていると判断された場合、クライアントは定期的にLLQセットアップ要求メッセージを介してLLQの再確立を試みることができます（MAY）。クライアントはLLQセットアップ要求を1時間に複数回試行してはなりません（MUST NOT）。
Upon receiving an LLQ Refresh message, a server MUST send an acknowledgment of the Refresh. This acknowledgment is formatted like the "ACK + Answers" message described in Section 5.2.4, but with the following variations:
LLQリフレッシュメッセージを受信すると、サーバーはリフレッシュの確認応答を送信する必要があります。この確認応答は、セクション5.2.4で説明されている「ACK + Answers」メッセージのようにフォーマットされますが、次のバリエーションがあります。
* It contains no answers.
* 答えはありません。
* The LLQ-OPCODE is set to LLQ-REFRESH.
* LLQ-OPCODEはLLQ-REFRESHに設定されます。
* NO-SUCH-LLQ MUST be returned as an error code if the client attempts to refresh an expired or non-existent LLQ (as determined by the LLQ-ID in the request).
* クライアントが期限切れまたは存在しないLLQ（リクエストのLLQ-IDによって決定される）を更新しようとした場合、NO-SUCH-LLQはエラーコードとして返されなければなりません（MUST）。
* The LLQ-ID in the acknowledgment is set to the LLQ-ID in the request.
* 確認応答のLLQ-IDは、要求のLLQ-IDに設定されます。
In datagram-based protocols (i.e., protocols running over UDP, or directly over IP, or similar), servers may be susceptible to denial-of-service (DoS) attacks, and clients may be subjected to packet storms. Carefully designed mechanisms are needed to limit potential for these attacks.
データグラムベースのプロトコル（つまり、UDPを介して実行されるプロトコル、またはIPを介して直接実行されるプロトコルなど）では、サーバーがサービス拒否（DoS）攻撃を受けやすく、クライアントがパケットストームにさらされる可能性があります。これらの攻撃の可能性を制限するには、注意深く設計されたメカニズムが必要です。
Note: This section contains no new protocol elements -- it serves only to explain the rationale behind protocol elements described above as they relate to security.
注：このセクションには、新しいプロトコル要素は含まれていません。セキュリティに関連するため、上記のプロトコル要素の背後にある理論的根拠を説明するためだけのものです。
LLQs require that servers be stateful, maintaining entries for each LLQ over a potentially long period of time. If unbounded in quantity, these entries may overload the server. By returning SERV-FULL in Setup Challenges, the server may limit the maximum number of LLQs it maintains. Additionally, the server may return SERV-FULL to limit the number of LLQs requested for a single name and type, or by a single client. This throttling may be in the form of a hard limit, or, preferably, by token-bucket rate limiting. Such rate limiting should occur rarely in normal use and is intended to prevent DoS attacks -- thus, it is not built into the protocol explicitly but is instead implemented at the discretion of an administrator via the SERV-FULL error and the LLQ-LEASE field to indicate a retry time to the client.
LLQでは、サーバーがステートフルであり、潜在的に長期間にわたって各LLQのエントリを維持する必要があります。数量に制限がない場合、これらのエントリはサーバーに過負荷をかける可能性があります。セットアップチャレンジでSERV-FULLを返すことにより、サーバーは維持するLLQの最大数を制限できます。さらに、サーバーはSERV-FULLを返し、単一の名前とタイプ、または単一のクライアントから要求されたLLQの数を制限する場合があります。このスロットリングは、ハードリミットの形式、または、好ましくはトークンバケットレートリミットによるものです。このようなレート制限は、通常の使用ではめったに発生しないはずであり、DoS攻撃を防ぐことを目的としています。したがって、プロトコルに明示的に組み込まれているのではなく、SERV-FULLエラーとLLQ-LEASEフィールドを介して管理者の裁量で実装されています。クライアントに再試行時間を示します。
In addition to protecting the server from DoS attacks, the LLQ protocol limits the ability of a malicious host to cause the server to flood a client with packets. This is achieved via the four-way handshake upon setup, demonstrating reachability and willingness of the client to participate, and by requiring that gratuitous responses be ACK'd by the client.
LLQプロトコルは、DoS攻撃からサーバーを保護するだけでなく、悪意のあるホストがサーバーにクライアントをパケットでフラッディングさせる機能を制限します。これは、セットアップ時に4ウェイハンドシェイクを介して実現され、クライアントの参加可能性と参加意欲を示し、クライアントが無償の応答をACKすることを要求します。
Additionally, rate limiting by LLQ client address, as described in Section 8.1, serves to limit the number of packets that can be delivered to an unsuspecting client.
さらに、セクション8.1で説明されているように、LLQクライアントアドレスによるレート制限は、疑いのないクライアントに配信できるパケットの数を制限するのに役立ちます。
A large random ID greatly reduces the risk of an off-path attacker sending spoof packets to the client (containing spoof events) or to the server (containing phony requests or refreshes).
ランダムなIDが大きいと、オフパス攻撃者がクライアント（スプーフィングイベントを含む）またはサーバー（偽の要求または更新を含む）にスプーフィングパケットを送信するリスクが大幅に減少します。
The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension. IANA has updated the record in the "DNS EDNS0 Option Codes (OPT)" registry from "On-hold" to "Optional" and has set the reference to this document.
EDNS（0）オプションコード1は、このDNS拡張にすでに割り当てられています。 IANAは、「DNS EDNS0オプションコード（OPT）」レジストリのレコードを「保留」から「オプション」に更新し、このドキュメントへの参照を設定しました。
TCP and UDP ports 5352 have already been assigned for LLQ. IANA has added a reference to this document.
TCPおよびUDPポート5352はすでにLLQに割り当てられています。 IANAはこのドキュメントへの参照を追加しました。
[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>。
[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>。
[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>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：// www.rfc-editor.org/info/rfc6891>。
[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>。
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", RFC 8765, DOI 10.17487/RFC8765, June 2020, <https://www.rfc-editor.org/info/rfc8765>.
[RFC8765] Pusateri、T。およびS. Cheshire、「DNS Push Notifications」、RFC 8765、DOI 10.17487 / RFC8765、2020年6月、<https://www.rfc-editor.org/info/rfc8765>。
[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>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[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>。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382] Guha、S。、編、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、 2008年10月、<https://www.rfc-editor.org/info/rfc5382>。
[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>。
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857] Penno、R.、Perreault、S.、Boucadair、M.、Ed。、Sivakumar、S.、and K. Naito、 "Updates to Network Address Translation（NAT）Behavioral Requirements"、BCP 127、RFC 7857、 DOI 10.17487 / RFC7857、2016年4月、<https://www.rfc-editor.org/info/rfc7857>。
[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>。
[SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", Volume 9, Number 4, The Internet Protocol Journal, Cisco Systems, December 2006, <https://www.cisco.com/web/about/ac123/ac147/ archived_issues/ipj_9-4/ipj_9-4.pdf>.
[SYN] Eddy、W。、「TCP SYNフラッディング攻撃に対する防御」、第9巻、第4巻、インターネットプロトコルジャーナル、シスコシステムズ、2006年12月、<https://www.cisco.com/web/about/ac123 /ac147/archived_issues/ipj_9-4/ipj_9-4.pdf>。
In the course of using LLQ since 2005, some problems were discovered. Since no further work is being done on the LLQ protocol, this LLQ specification will not be updated to remedy these problems.
2005年以降、LLQを使用する過程で、いくつかの問題が発見されました。 LLQプロトコルではこれ以上の作業は行われていないため、このLLQ仕様はこれらの問題を解決するために更新されません。
LLQ's IETF Standards Track successor, "DNS Push Notifications" [RFC8765], does not suffer from these problems, so all existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications, and all new implementations are RECOMMENDED to implement DNS Push Notifications instead of LLQ.
LLQのIETF標準トラックの後継である「DNSプッシュ通知」[RFC8765]はこれらの問題の影響を受けないため、既存のすべてのLLQ実装はDNSプッシュ通知の使用に移行することが推奨され、すべての新しい実装はDNSプッシュ通知の代わりに実装することをお勧めしますLLQ。
Known problems with LLQ are documented here as a cautionary tale about the challenges of building an application protocol directly using datagrams (like IP or UDP) without the benefit of a mature and thoroughly reviewed intervening transport layer (such as TCP or QUIC).
LLQの既知の問題は、成熟した完全に見直された介在トランスポート層（TCPやQUICなど）を利用せずに、データグラム（IPやUDPなど）を直接使用してアプリケーションプロトコルを構築する際の課題に関する注意書きとして、ここに記載されています。
An LLQ "Setup Challenge" message from server to client is identical to an LLQ "ACK + Answers" message from server to client when there are no current answers for the query. If there is packet loss, retransmission, and duplication in the network, then a duplicated "Setup Challenge" message arriving late at the client would look like an "ACK + Answers" message with no answers, causing the client to clear its cache of any records matching the query.
サーバーからクライアントへのLLQ「セットアップチャレンジ」メッセージは、クエリに対する現在の回答がない場合のサーバーからクライアントへのLLQ「ACK +回答」メッセージと同じです。ネットワークでパケット損失、再送信、および重複がある場合、クライアントに遅れて到着する複製された「セットアップチャレンジ」メッセージは、応答のない「ACK +回答」メッセージのようになり、クライアントのキャッシュをクリアします。クエリに一致するレコード。
Section 5.1 of this LLQ specification states, "Servers MUST NOT garbage collect LLQs that fail to complete the four-way handshake until the initially granted LLQ-LEASE has elapsed." This is probably a mistake since it exposes LLQ servers to an easy resource-exhaustion denial-of-service attack. LLQ's replacement, DNS Push Notifications [RFC8765], is built using DNS Stateful Operations [RFC8490], which uses TLS over TCP; a benefit of building on TCP is that there are already established industry best practices to guard against SYN flooding and similar attacks [SYN] [RFC4953].
このLLQ仕様のセクション5.1には、「最初に許可されたLLQ-LEASEが経過するまで、サーバーは4ウェイハンドシェイクを完了できないLLQをガベージコレクションしてはならない」と記載されています。 LLQサーバーを簡単にリソース枯渇サービス拒否攻撃にさらすため、これはおそらく間違いです。 LLQの後継であるDNSプッシュ通知[RFC8765]は、TLS over TCPを使用するDNSステートフルオペレーション[RFC8490]を使用して構築されています。 TCP上に構築することの利点は、SYNフラッディングおよび類似の攻撃[SYN] [RFC4953]から保護するための確立された業界のベストプラクティスがすでに存在することです。
The attempts here to pack multiple questions into a single UDP/IP packet for efficiency are awkward and lead to error-prone programming to deal with cases where some requests in a packet succeed and other requests in the same packet fail. Fully specifying the correct handling in all possible cases would be a lot of work to document, a lot of work to implement, and even more work to thoroughly test. DNS Push Notifications [RFC8765] avoids this problem by using an underlying stream protocol (TLS/TCP) to deal with packing small multiple messages into larger IP packets for efficiency.
効率を上げるために複数の質問を単一のUDP / IPパケットにパックするここでの試みは厄介であり、パケット内の一部の要求が成功し、同じパケット内の他の要求が失敗する場合に対処するエラーが発生しやすいプログラミングにつながります。可能なすべてのケースで正しい処理を完全に指定することは、文書化する多くの作業、実装する多くの作業、そして徹底的にテストするさらに多くの作業になります。 DNSプッシュ通知[RFC8765]は、基になるストリームプロトコル（TLS / TCP）を使用して小さな複数のメッセージを大きなIPパケットにパッキングして効率を上げることでこの問題を回避します。
In some cases, initial LLQ answers are delivered in the "ACK + Answers" message, and in other cases, such as when all the initial answers will not fit in a single IP packet, some of the initial answers are delivered in a subsequent "Add Event" message. Having two different ways to accomplish the same thing increases the possibility for programming errors. DNS Push Notifications [RFC8765] corrects this error by having only one single consistent way to deliver results.
場合によっては、初期LLQ回答が「ACK + Answers」メッセージで配信されます。また、すべての初期回答が単一のIPパケットに収まらない場合など、一部の初期回答は後続の「イベントの追加」メッセージ。同じことを実行する2つの異なる方法があると、プログラミングエラーが発生する可能性が高くなります。 DNSプッシュ通知[RFC8765]は、結果を配信する一貫した単一の方法のみを持つことにより、このエラーを修正します。
LLQ is built using UDP, and because UDP has no standardized way of indicating the start and end of a session, firewalls and NAT gateways tend to be fairly aggressive about recycling UDP mappings that they believe to be disused [RFC4787] [RFC5382] [RFC7857]. Using a high keepalive traffic rate to maintain firewall or NAT mapping state could remedy this but would largely defeat the purpose of using LLQ in the first place, which is to provide efficient change notification without wasteful polling. Because of this, existing LLQ clients use the NAT Port Mapping Protocol (NAT-PMP) [RFC6886] and/or Port Control Protocol (PCP) [RFC6887] to establish longer port mapping lifetimes. This solves the problem but adds extra complexity and doesn't work with firewalls and NAT gateways that don't support NAT-PMP or PCP. By using TCP instead of UDP, the DNS Push Notifications protocol benefits from better longevity of sessions through firewalls and NAT gateways that don't support NAT-PMP or PCP.
LLQはUDPを使用して構築されており、UDPにはセッションの開始と終了を示す標準化された方法がないため、ファイアウォールとNATゲートウェイは、使用されないと思われるUDPマッピングのリサイクルにかなり積極的になる傾向があります[RFC4787] [RFC5382] [RFC7857 ]。ファイアウォールまたはNATマッピング状態を維持するために高いキープアライブトラフィックレートを使用すると、これを改善できますが、そもそもLLQを使用する目的を大いに損ない、無駄なポーリングなしで効率的な変更通知を提供します。このため、既存のLLQクライアントは、NATポートマッピングプロトコル（NAT-PMP）[RFC6886]および/またはポート制御プロトコル（PCP）[RFC6887]を使用して、より長いポートマッピングライフタイムを確立します。これにより問題は解決しますが、複雑さが増し、NAT-PMPまたはPCPをサポートしないファイアウォールやNATゲートウェイでは機能しません。 UDPの代わりにTCPを使用することにより、DNSプッシュ通知プロトコルは、NAT-PMPまたはPCPをサポートしないファイアウォールおよびNATゲートウェイを通過するセッションの寿命が長くなるというメリットがあります。
Acknowledgments
謝辞
The concepts described in this document were originally explored, developed, and implemented with help from Chris Sharp and Roger Pantos.
このドキュメントで説明されている概念は、当初、Chris SharpとRoger Pantosの助けを借りて探索、開発、実装されたものです。
Kiren Sekar made significant contributions to the first draft of this document and he wrote much of the code for the implementation of LLQ that shipped in Mac OS X 10.4 Tiger in April 2005.
Kiren Sekarはこのドキュメントの最初のドラフトに多大な貢献をし、2005年4月にMac OS X 10.4 Tigerに同梱されたLLQの実装のためのコードの多くを書きました。
Thanks to Independent Stream Editor Adrian Farrel for his support and assistance in the publication of this RFC.
このRFCの発行に対するサポートと支援をしてくれた独立ストリーム編集者のAdrian Farrelに感謝します。
Authors' Addresses
著者のアドレス
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
Marc Krochmal Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America
Marc Krochmal Apple Inc. One Apple Park Way Cupertino、CA 95014アメリカ合衆国
Phone: +1 (408) 996-1010
Email: marc@apple.com