Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 9665 S. Cheshire
Category: Standards Track Apple Inc.
ISSN: 2070-1721 June 2025
The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations.
DNSベースのサービスディスカバリー（DNS-SD）のサービス登録プロトコル（SRP）は、標準のDNS更新メカニズムを使用して、ユニキャストパケットのみを使用してDNS-SDを有効にします。これにより、マルチキャストなしでDNS-SDを展開できます。これにより、スケーラビリティが大幅に向上し、マルチキャストサービスが最適な選択ではないネットワーク、特にIEEE 802.11（Wi-Fi）およびIEEE 802.15.4ネットワークのパフォーマンスが向上します。DNS-SDサービス登録では、パブリックキーとSIG（0）を使用して、サービスが登録を守ることができます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9665.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9665で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology Used in This Document
3. Service Registration Protocol
3.1. Protocol Variants
3.1.1. Full-Featured Hosts
3.1.2. Constrained Hosts
3.1.3. Why two variants?
3.2. Protocol Details
3.2.1. What to Publish
3.2.2. Where to Publish It
3.2.3. How to Publish It
3.2.3.1. How the DNS-SD Service Registration Process Differs
from DNS Update
3.2.3.2. Retransmission Strategy
3.2.3.3. Successive Updates
3.2.4. How to Secure It
3.2.4.1. FCFS Naming
3.2.5. SRP Requester Behavior
3.2.5.1. Public/Private Key Pair Generation and Storage
3.2.5.2. Name Conflict Handling
3.2.5.3. Record Lifetimes
3.2.5.4. Compression in SRV Records
3.2.5.5. Removing Published Services
3.3. Validation and Processing of SRP Updates
3.3.1. Validation of DNS Update Add and Delete RRs
3.3.1.1. Service Discovery Instruction
3.3.1.2. Service Description Instruction
3.3.1.3. Host Description Instruction
3.3.2. Valid SRP Update Requirements
3.3.3. FCFS Name and Signature Validation
3.3.4. Handling of Service Subtypes
3.3.5. SRP Update Response
3.3.6. Optional Behavior
4. TTL Consistency
5. Maintenance
5.1. Cleaning Up Stale Data
6. Security Considerations
6.1. Source Validation
6.2. Other DNS Updates
6.3. Risks of Allowing Arbitrary Names to be Registered in SRP
Updates
6.4. Security of Local Service Discovery
6.5. SRP Registrar Authentication
6.6. Required Signature Algorithm
7. Privacy Considerations
8. Domain Name Reservation Considerations
8.1. Users
8.2. Application Software
8.3. Name Resolution APIs and Libraries
8.4. Recursive Resolvers
8.5. Authoritative DNS Servers
8.6. DNS Server Operators
8.7. DNS Registries/Registrars
9. Delegation of "service.arpa."
10. IANA Considerations
10.1. Registration and Delegation of "service.arpa." as a
Special-Use Domain Name
10.2. Addition of "service.arpa." to the Locally-Served Zones
Registry
10.3. Subdomains of "service.arpa."
10.4. Service Name Registrations
10.4.1. "dnssd-srp" Service Name
10.4.2. "dnssd-srp-tls" Service Name
10.5. Anycast Address
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Using Standard Authoritative DNS Servers Compliant
with RFC 2136 to Test SRP Requesters
Appendix B. How to Allow SRP Requesters to Update Standard Servers
Compliant with RFC 2136
Appendix C. Sample BIND 9 Configuration for
"default.service.arpa."
Acknowledgments
Authors' Addresses
DNS-SD [RFC6763] is a component of Zero Configuration Networking [RFC6760] [ZC] [ROADMAP].
DNS-SD [RFC6763]は、ゼロ構成ネットワーク[RFC6760] [ZC] [ロードマップ]のコンポーネントです。
This document describes an enhancement to DNS-SD that allows servers to register the services they offer using the DNS protocol over unicast rather than using Multicast DNS (mDNS) [RFC6762]. There is already a large installed base of DNS-SD clients that can discover services using the DNS protocol (e.g., Android, Windows, Linux, Apple operating systems).
このドキュメントでは、マルチキャストDNS（MDNS）[RFC6762]を使用するのではなく、ユニキャストを介してDNSプロトコルを使用して提供するサービスをサーバーが登録できるDNS-SDの拡張について説明します。DNSプロトコル（Android、Windows、Linux、Appleオペレーティングシステムなど）を使用してサービスを発見できるDNS-SDクライアントの大きなインストールベースがすでにあります。
This document is intended for three audiences: Implementers of software that provides services that should be advertised using DNS-SD, implementers of authoritative DNS servers that will be used in contexts where DNS-SD registration is needed, and administrators of networks where DNS-SD service is required. The document is expected to provide sufficient information to allow interoperable implementation of the Service Registration Protocol.
このドキュメントは、DNS-SDを使用して宣伝すべきサービスを提供するソフトウェアの実装者、DNS-SD登録が必要なコンテキストで使用される権威あるDNSサーバーの実装者、およびDNS-SDサービスが必要なネットワークの管理者を使用するソフトウェアの実装者を対象としています。このドキュメントは、サービス登録プロトコルの相互運用可能な実装を可能にするのに十分な情報を提供することが期待されています。
DNS-SD allows servers to publish the information required to access the services they provide. DNS-SD clients can then discover the set of service instances of a particular type that are available. They can then select an instance from among those that are available and obtain the information required to use it. Although DNS-SD using the DNS protocol can be more efficient and versatile than using mDNS, it is not common in practice because of the difficulties associated with updating authoritative DNS services with service information.
DNS-SDを使用すると、サーバーが提供するサービスにアクセスするために必要な情報を公開できます。DNS-SDクライアントは、利用可能な特定のタイプのサービスインスタンスのセットを発見できます。その後、利用可能なインスタンスの中からインスタンスを選択し、使用するために必要な情報を取得できます。DNSプロトコルを使用したDNS-SDは、MDNSを使用するよりも効率的かつ多用途な場合がありますが、サービス情報で権威あるDNSサービスを更新することに関連する困難のため、実際には一般的ではありません。
The existing practice for updating DNS zones is either to enter new data manually or to use DNS Update [RFC2136]. Unfortunately, DNS Update requires either:
DNSゾーンを更新するための既存のプラクティスは、新しいデータを手動で入力するか、DNS更新[RFC2136]を使用することです。残念ながら、DNSアップデートには次のいずれかが必要です。
* that the authoritative DNS server automatically trust updates or
* 権威あるDNSサーバーが更新を自動的に信頼することまたは
* that the DNS Update requester have some kind of shared secret or public key that is known to the authoritative DNS server and can be used to authenticate the update.
* DNSアップデートリクエスターには、権威あるDNSサーバーに知られており、更新の認証に使用できるような共有秘密または公開キーがあること。
Furthermore, DNS Update can be a fairly chatty process, requiring multiple roundtrips with different conditional predicates to complete the update process.
さらに、DNSの更新はかなりおしゃべりなプロセスである可能性があり、更新プロセスを完了するために異なる条件付き述語を使用した複数の往復が必要です。
The Service Registration Protocol (SRP) adds a set of default heuristics for processing DNS updates that eliminates the need for conditional predicates. Instead, the SRP registrar (an authoritative DNS server that supports SRP Updates) has a set of default predicates that are applied to the update; and the update either succeeds entirely or fails in a way that allows the requester to know what went wrong and construct a new update.
サービス登録プロトコル（SRP）は、条件付き述語の必要性を排除するDNS更新を処理するためのデフォルトのヒューリスティックのセットを追加します。代わりに、SRPレジストラ（SRP更新をサポートする権威あるDNSサーバー）には、更新に適用されるデフォルトの述語のセットがあります。更新は完全に成功するか、要求者が何がうまくいかなかったかを知り、新しいアップデートを構築できるように失敗します。
SRP also adds a feature called "First Come, First Served Naming" (or "FCFS Naming"), which allows the requester to:
SRPは、「First Come、First Server Naming」（または「FCFSネーミング」）と呼ばれる機能も追加します。
* claim a name that is not yet in use, and
* まだ使用されていない名前を主張し、
* authenticate, using SIG(0) [RFC2931], both the initial claim (to ensure it has not been modified in transit) and subsequent updates (to ensure they come from the same entity that performed the initial claim).
* SIG（0）[RFC2931]を使用して認証する、最初のクレーム（輸送中に変更されていないことを確認するため）とその後の更新（最初のクレームを実行したのと同じエンティティから来ることを確認するため）。
This prevents a new service instance from "stealing" a name that is already in use: A second SRP requester attempting to claim an existing name will not possess the SIG(0) key used by the first requester to claim it. Because of this, its claim will be rejected. This will force it to choose a new name.
これにより、新しいサービスインスタンスが既に使用されている名前を「盗む」ことを防ぎます。既存の名前を請求しようとする2番目のSRP要求者は、最初の要求者がそれを請求するために使用するSIG（0）キーを所有していません。このため、その主張は拒否されます。これにより、新しい名前を選択するように強制されます。
It is important to understand that "authenticate" here just means that we can tell that an update came from the same source as the original registration. We have not established trust. This has important implications for what we can and can't do with data the SRP requester sends us. You will notice as you read this document that we only support adding a very restricted set of records, and the content of those records is further constrained.
ここでの「認証」は、元の登録と同じソースからアップデートが来たことを知ることができることを意味することを理解することが重要です。私たちは信頼を確立していません。これは、SRP要求者が送信するデータでできることとできないことに対して重要な意味を持ちます。このドキュメントを読んでいると、非常に制限されたレコードのセットの追加のみをサポートしていることに気付くでしょう。これらのレコードのコンテンツはさらに制約されています。
The reason for this is precisely that we have not established trust. So, we can only publish information that we feel safe in publishing even though we do not have any basis for trusting the requester. We reason that mDNS [RFC6762] allows arbitrary hosts on a single IP link to advertise services [RFC6763], relying on whatever service is advertised to provide authentication as a part of its protocol rather than in the service advertisement.
その理由は、まさに私たちが信頼を確立していないことです。そのため、リクエスターを信頼するための根拠がない場合でも、公開が安全だと感じる情報のみを公開できます。MDNS [RFC6762]により、広告サービス[RFC6763]への単一のIPリンクで任意のホストが許可されており、サービス広告ではなくプロトコルの一部として認証を提供するために広告されているサービスに依存しています。
This is considered reasonably safe because it requires physical presence on the network in order to advertise. An off-network mDNS attack is simply not possible. Our goal with this specification is to impose similar constraints. Therefore, you will see in Section 3.3.1 that a very restricted set of records with a very restricted set of relationships are allowed. You will also see in Section 6.1 that we give advice on how to prevent off-network attacks.
これは、宣伝するためにネットワーク上に物理的な存在が必要であるため、合理的に安全であると考えられています。ネットワーク外のMDNS攻撃は単に不可能です。この仕様に関する私たちの目標は、同様の制約を課すことです。したがって、セクション3.3.1で、非常に制限された関係セットを持つ非常に制限されたレコードのセットが許可されていることがわかります。また、セクション6.1で、ネットワークオフ攻撃を防ぐ方法についてアドバイスをすることがわかります。
This leads us to the disappointing observation that this protocol is not a mechanism for adding arbitrary information to DNS zones. We have not evaluated the security properties of adding, for example, an SOA record, an MX record, or a CNAME record; therefore, these are forbidden. Future updates to this specification might include analyses for other records and extend the set of records and/or record content that can be registered here. Or it might require establishment of trust, and add an authorization model to the authentication model we now have. But that is work for a future document.
これにより、このプロトコルはDNSゾーンに任意の情報を追加するメカニズムではないという残念な観察につながります。たとえば、SOAレコード、MXレコード、またはCNAMEレコードを追加するセキュリティプロパティを評価していません。したがって、これらは禁止されています。この仕様の将来の更新には、他のレコードの分析が含まれ、ここに登録できるレコードのセットやレコードコンテンツを拡張する場合があります。または、信頼の確立が必要であり、現在の認証モデルに承認モデルを追加する場合があります。しかし、それは将来のドキュメントでは機能します。
Finally, SRP adds the concept of a "lease" [RFC9664], analogous to leases in DHCP [RFC2131] [RFC8415]. The SRP registration itself has a lease that may be on the order of two hours; if the requester does not renew the lease before it has elapsed, the registration is removed. The claim on the name can have a longer lease so that another requester cannot immediately claim the name, even though the registration itself has expired.
最後に、SRPは、DHCP [RFC2131] [RFC8415]のリースに類似した「リース」[RFC9664]の概念を追加します。SRP登録自体には、2時間のオーダーにあるリースがあります。要求者がリースが経過する前にリースを更新しない場合、登録は削除されます。名前の請求は、登録自体が期限切れになっていても、別の要求者がすぐに名前を請求できないように、より長いリースを持つことができます。
The Service Registration Protocol for DNS-SD specified in this document provides a reasonably secure mechanism for publishing this information. Once published, these services can be readily discovered by DNS-SD clients using standard DNS lookups.
このドキュメントで指定されたDNS-SDのサービス登録プロトコルは、この情報を公開するための合理的に安全なメカニズムを提供します。公開されると、これらのサービスは、標準のDNSルックアップを使用してDNS-SDクライアントによって容易に発見できます。
Section 10 of the DNS-SD specification [RFC6763] briefly discusses ways that servers can advertise the services they provide in the DNS namespace. In the case of mDNS, it allows servers to advertise their services on the local link, using names in the "local." namespace, which makes their services directly discoverable by peers attached to that same local link.
DNS-SD仕様[RFC6763]のセクション10では、サーバーがDNSネームスペースで提供するサービスを宣伝できる方法について簡単に説明します。MDNSの場合、サーバーは「ローカル」の名前を使用して、ローカルリンクでサービスを宣伝できます。名前空間は、同じローカルリンクに添付されているピアがサービスを直接発見できるようにします。
DNS-SD [RFC6763] also allows clients to discover services by using the DNS protocol over traditional unicast [RFC1035]. This can be done by having a system administrator manually configure service information in the DNS; however, manually populating DNS authoritative server databases is costly and potentially error-prone and requires a knowledgeable network administrator. Consequently, although all DNS-SD client implementations of which we are aware support DNS-SD using DNS queries, in practice it is used much less frequently than mDNS.
DNS-SD [RFC6763]により、クライアントは従来のユニキャスト[RFC1035]を介してDNSプロトコルを使用してサービスを発見できます。これは、システム管理者にDNSでサービス情報を手動で構成することで実行できます。ただし、DNSの権威あるサーバーデータベースを手動で埋めることは、コストがかかり、潜在的にエラーが発生しやすく、知識豊富なネットワーク管理者が必要です。その結果、すべてのDNS-SDクライアントの実装は、DNSクエリを使用してDNS-SDをサポートしていることを認識していますが、実際にはMDNSよりもはるかに少ない頻度で使用されます。
The Discovery Proxy [RFC8766] provides one way to automatically populate the DNS namespace but is only appropriate on networks where services are easily advertised using mDNS. The present document describes a solution more suitable for networks where multicast is inefficient, or where sleepy devices are common, by supporting the use of unicast for both the offering of and the discovery of services.
Discovery Proxy [RFC8766]は、DNS名前空間を自動的に設定する1つの方法を提供しますが、MDNSを使用してサービスを簡単に宣伝できるネットワークでのみ適切です。現在のドキュメントでは、サービスの提供と発見の両方にユニキャストの使用をサポートすることにより、マルチキャストが非効率的である、または眠そうなデバイスが一般的なネットワークにより適したソリューションについて説明しています。
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] で説明されているように解釈されます。
Strictly speaking, fully qualified domain names end with a dot ("."). In DNS zone files and other similar contexts, if the final dot is omitted, then a name may be treated incorrectly as relative to some other parent domain. This document follows the formal DNS convention, ending fully qualified domain names with a dot. When this document mentions domain names such as "local." and "default.service.arpa.", the final dot is part of the domain name; it is not a period indicating the end of the sentence.
厳密に言えば、完全に適格なドメイン名はドット（ "。"）で終わります。DNSゾーンファイルおよびその他の同様のコンテキストでは、最終ドットが省略されている場合、名前は他の親ドメインと比較して誤って扱われる場合があります。このドキュメントは、正式なDNS条約に従い、ドットで完全に適格なドメイン名を終了します。このドキュメントが「ローカル」などのドメイン名に言及している場合。「default.service.arpa。」、最終ドットはドメイン名の一部です。文の終わりを示す期間ではありません。
Services that implement SRP use DNS Update [RFC2136] with SIG(0) [RFC3007] to publish service information in the DNS. Two variants exist: One for full-featured hosts and one for devices designed for Constrained-Node Networks (CNNs) [RFC7228]. An SRP registrar is most likely an authoritative DNS server or is a source of data for one or more authoritative DNS servers. There is no requirement that the authoritative DNS server that is receiving SRP Updates be the same authoritative DNS server that is answering queries that return records that have been registered. For example, an SRP registrar could be the "hidden primary" that is the source of data for a fleet of secondary authoritative DNS servers.
SRPを実装するサービスは、DNSアップデート[RFC2136]を使用してSIG（0）[RFC3007]を使用して、DNSでサービス情報を公開します。2つのバリエーションが存在します。1つはフル機能のホスト用で、もう1つは制約ノードネットワーク（CNNS）用に設計されたデバイス用です[RFC7228]。SRPレジストラは、おそらく権威あるDNSサーバーであるか、1つ以上の権威あるDNSサーバーのデータソースです。SRPの更新を受信している権威あるDNSサーバーが、登録されているレコードを返すクエリに応答しているのと同じ権威あるDNSサーバーであるという要件はありません。たとえば、SRPレジストラは、二次権威あるDNSサーバーの艦隊のデータソースである「隠されたプライマリ」である可能性があります。
Full-featured hosts either are configured manually with a registration domain or discover the default registration domain automatically using the Domain Enumeration process described in Section 11 of the DNS-SD specification [RFC6763]. If this process does not produce a default registration domain, the SRP registrar is not discoverable on the local network using this mechanism. Other discovery mechanisms are possible, but they are out of scope for this document.
フル機能のホストは、DNS-SD仕様[RFC6763]のセクション11で説明されているドメイン列挙プロセスを使用して、登録ドメインで手動で設定されるか、デフォルトの登録ドメインを自動的に発見します。このプロセスでデフォルトの登録ドメインが生成されない場合、SRPレジストラはこのメカニズムを使用してローカルネットワークで発見できません。他の発見メカニズムは可能ですが、このドキュメントの範囲外です。
Configuration of the registration domain can be done either:
登録ドメインの構成は次のとおりです。
* by querying the list of available registration domains ("r._dns-sd._udp") and allowing the user to select one from the UI, or
* 利用可能な登録ドメインのリスト（ "r._dns-sd._udp"）を照会し、ユーザーがUIから1つを選択できるようにすることにより、
* by any other means appropriate to the particular use case being addressed.
* 対処されている特定のユースケースに適した他の手段により。
Full-featured devices construct the names of the SRV, TXT, and PTR records describing their service or services as subdomains of the chosen service registration domain. For these names, they then discover the zone apex of the closest enclosing DNS zone using SOA queries as described in Section 6.1 of the DNS Push Notification specification [RFC8765]. Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the SRP registrar to which they can send SRP Updates. Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead.
フル機能のデバイスは、選択したサービス登録ドメインのサブドメインとしてサービスまたはサービスを説明するSRV、TXT、およびPTRレコードの名前を作成します。これらの名前については、DNSプッシュ通知仕様[RFC8765]のセクション6.1で説明されているように、SOAクエリを使用して、DNSゾーンの最も近い囲いのゾーン頂点を発見します。囲まれたDNSゾーンを発見した後、彼らは「_DNSSD-SRP._TCP。<ZONER>」SRVレコードをクエリして、SRPアップデートを送信できるSRPレジストラを発見します。TLSを使用してSRP更新をサポートするホストは、代わりに「_DNSSD-SRP-TLS._TCP。<ZONER>」SRVレコードを使用します。
Examples of full-featured hosts include devices such as home computers, laptops, powered peripherals with network connections (such as printers and home routers), and even battery-operated devices such as mobile phones that have long battery lives.
フル機能のホストの例には、ホームコンピューター、ラップトップなどのデバイス、ネットワーク接続（プリンターやホームルーターなど）を備えた駆動周辺機器、バッテリーの寿命が長い携帯電話などのバッテリー操作デバイスも含まれます。
For devices designed for CNNs [RFC7228], some simplifications are available. Instead of being configured with (or discovering) the service registration domain, the special-use domain name [RFC6761] "default.service.arpa." is used. The details of how SRP registrars are discovered will be specific to the constrained network; therefore, we do not suggest a specific mechanism here.
CNNS [RFC7228]用に設計されたデバイスの場合、いくつかの単純化が利用可能です。サービス登録ドメインで構成（または発見）する代わりに、特別使用ドメイン名[rfc6761]「default.service.arpa」使用されています。SRPレジストラの発見方法の詳細は、制約されたネットワークに固有のものになります。したがって、ここで特定のメカニズムを提案しません。
SRP requesters on CNNs are expected to receive, from the network, a list of SRP registrars with which to register. It is the responsibility of a CNN supporting SRP to provide at least one registrar address and port. It is the responsibility of the registrar supporting a CNN to handle the updates appropriately. In some network environments, updates may be accepted directly into a local "default.service.arpa." zone, which has only local visibility. In other network environments, updates for names ending in "default.service.arpa." may be rewritten by the registrar to names with broader visibility. Domain name rewriting should be performed as appropriate for the network environment in question. Some suggested techniques for how domain names can be translated from a locally scoped name to a domain name with larger scope can be found in the discussion of data translation for names in Multicast DNS answers in Section 5.5 of the Discovery Proxy specification [RFC8766].
CNNのSRPリクエスト担当者は、ネットワークから登録するSRPレジストラのリストを受信すると予想されます。少なくとも1つのレジストラアドレスとポートを提供することは、SRPをサポートするCNNの責任です。更新を適切に処理することは、CNNをサポートするレジストラの責任です。一部のネットワーク環境では、更新はローカル「default.service.arpa」に直接受け入れられる場合があります。ゾーン。局所的な可視性のみがあります。他のネットワーク環境では、「default.service.arpa」で終わる名前の更新。レジストラによって、より広い可視性の名前に書き直される場合があります。ドメイン名の書き換えは、問題のネットワーク環境に適しているように実行する必要があります。ドメイン名をローカルでスコープされた名前からより大きなスコープのドメイン名に翻訳する方法についてのいくつかの推奨される手法は、ディスカバリープロキシ仕様[RFC8766]のセクション5.5のマルチキャストDNS回答の名前のデータ翻訳のディスカッションにあります。
The reason for these different variants is that low-power devices that typically use CNNs may have very limited battery capacity. The series of DNS lookups required to discover an SRP registrar and then communicate with it will increase the energy required to advertise a service; for low-power devices, the additional flexibility this provides does not justify the additional use of energy. It is also fairly typical of such networks that some network service information is obtained as part of the process of joining the network; thus, this can be relied upon to provide nodes with the information they need.
これらのさまざまなバリエーションの理由は、通常、CNNを使用する低電力デバイスが非常に限られたバッテリー容量を持っている可能性があるためです。SRPレジストラを発見してから通信するために必要な一連のDNSルックアップは、サービスを宣伝するのに必要なエネルギーが増加します。低電力デバイスの場合、これが提供する追加の柔軟性は、エネルギーの追加の使用を正当化するものではありません。また、ネットワークに参加するプロセスの一部としていくつかのネットワークサービス情報が取得されることは、このようなネットワークのかなり典型的なものです。したがって、これは、必要な情報をノードに提供するために依存することができます。
Networks that are not CNNs can have more complicated topologies at the IP layer. Nodes connected to such networks can be assumed to be able to do DNS-SD service registration domain discovery. Such networks are generally able to provide registration domain discovery and routing. This creates the possibility of off-network spoofing, where a device from a foreign network registers a service on the local network in order to attack devices on the local network. To guard against off-path spoofing, TCP is required for such networks.
CNNではないネットワークは、IPレイヤーでより複雑なトポロジを持つことができます。このようなネットワークに接続されたノードは、DNS-SDサービス登録ドメイン発見を実行できると想定できます。このようなネットワークは通常、登録ドメインの発見とルーティングを提供することができます。これにより、外国ネットワークのデバイスがローカルネットワーク上のデバイスを攻撃するためにローカルネットワーク上のサービスを登録する可能性が生じます。オフパスのスポーフを防ぐために、このようなネットワークにはTCPが必要です。
We will discuss several parts to this process:
このプロセスのいくつかの部分について説明します。
* how to know what to publish (Section 3.2.1),
* 何を公開するかを知る方法（セクション3.2.1）、
* how to know where to publish it (under what name) (Section 3.2.2),
* どこで公開するかを知る方法（名前で）（セクション3.2.2）、
* how to publish it (Section 3.2.3),
* それを公開する方法（セクション3.2.3）、
* how to secure its publication (Section 3.2.4), and
* その出版物を確保する方法（セクション3.2.4）、および
* how to maintain the information once published (Section 5).
* 公開されたら情報を維持する方法（セクション5）。
SRP Updates are sent by SRP requesters to SRP registrars. Three types of instructions appear in an SRP Update: Service Discovery instructions, Service Description instructions, and Host Description instructions. These instructions are made up of DNS Update Resource Records (RRs) that are either adds or deletes. The types of records that are added, updated, and removed in each of these instructions, as well as the constraints that apply to them, are described in Section 3.3. An SRP Update is a DNS Update message [RFC2136] that is constructed so as to meet the constraints described in that section. The following is a brief overview of what is included in a typical SRP Update:
SRP更新は、SRPリクエスト担当者からSRPレジストラに送信されます。SRPアップデートには、3種類の手順が表示されます。サービスの発見手順、サービスの説明手順、およびホストの説明手順です。これらの命令は、追加または削除のいずれかであるDNS更新リソースレコード（RRS）で構成されています。これらの各命令で追加、更新、削除されたレコードの種類、およびそれらに適用される制約については、セクション3.3で説明します。SRPアップデートは、そのセクションで説明されている制約を満たすために構築されたDNSアップデートメッセージ[RFC2136]です。以下は、典型的なSRPアップデートに含まれるものの概要です。
* Service Discovery PTR RR(s) for service(s), which map from a generic service type (or subtype(s)) to a specific service instance name [RFC6763].
* サービス用のサービスディスカバリーPTR RR（s）は、一般的なサービスタイプ（またはサブタイプ）から特定のサービスインスタンス名[RFC6763]にマッピングされます。
* For each service instance name, an SRV RR, one or more TXT RRs, and a KEY RR. Although, in principle, DNS-SD Service Description records can include other record types with the same service instance name, in practice, they rarely do. Currently, SRP does not permit other record types. The KEY RR is used to support FCFS Naming and has no specific meaning for DNS-SD lookups. SRV records for all services described in an SRP Update point to the same hostname.
* 各サービスインスタンス名、SRV RR、1つ以上のTXT RRS、およびキーRR。原則として、DNS-SDサービスの説明レコードには、同じサービスインスタンス名を持つ他のレコードタイプを含めることができますが、実際にはめったにありません。現在、SRPは他のレコードタイプを許可していません。重要なRRは、FCFSネーミングをサポートするために使用され、DNS-SDルックアップに具体的な意味はありません。SRPアップデートで説明されているすべてのサービスのSRVレコードは、同じホスト名を指します。
* There is always exactly one hostname in a single SRP Update. A DNS Update containing more than one hostname is not an SRP Update. The hostname has one or more address RRs (AAAA or A) and a KEY RR (used for FCFS Naming). Depending on the use case, an SRP requester may be required to suppress some addresses that would not be usable by hosts discovering the service through the SRP registrar. The exact address record suppression behavior required may vary for different types of SRP requesters. Some suggested policies for suppressing unusable records can be found in Section 5.5.2 of the Discovery Proxy specification [RFC8766].
* 単一のSRPアップデートには、常に正確に1つのホスト名があります。複数のホスト名を含むDNSアップデートは、SRPアップデートではありません。ホスト名には、1つ以上のアドレスRRS（AAAAまたはA）とキーRR（FCFSネーミングに使用）があります。ユースケースに応じて、SRPリクエスト担当者は、SRPレジストラを介してサービスを発見するホストが使用できないアドレスを抑制する必要があります。必要な正確なアドレスレコード抑制動作は、SRP要求者によって異なる場合があります。使用不可能な記録を抑制するための提案されたポリシーは、発見プロキシ仕様[RFC8766]のセクション5.5.2に記載されています。
The DNS-Based Service Discovery specification [RFC6763] describes the details of what each of these RR types mean, with the exception of the KEY RR, which is defined in the specification for how to store Diffie-Hellman Keys in the DNS [RFC2539]. These specifications should be considered the definitive sources for information about what to publish; the reason for summarizing this here is to provide the reader with enough information about what will be published that the service registration process can be understood at a high level without first learning the full details of DNS-SD. Also, the "service instance name" is an important aspect of FCFS Naming, which we describe later on in this document.
DNSベースのサービスディスカバリー仕様[RFC6763]は、DNS [RFC2539]にDiffie-Hellmanキーを保存する方法の仕様で定義されているキーRRを除き、これらのRRタイプのそれぞれの意味の詳細を説明しています。これらの仕様は、公開するものに関する情報の決定的なソースと見なされる必要があります。これをここにまとめる理由は、DNS-SDの詳細を最初に学習せずに、サービス登録プロセスを高レベルで理解できるという公開されたものについて、読者に十分な情報を提供することです。また、「サービスインスタンス名」はFCFSネーミングの重要な側面であり、このドキュメントで後で説明します。
Multicast DNS (mDNS) uses a single namespace, "local.". Subdomains of "local." are specific to the local link on which they are advertised. This convenience is not available for DNS-SD using the DNS protocol: Services must exist in some specific DNS namespace that is chosen either by the network operator or automatically.
マルチキャストDNS（MDNS）は、単一の名前空間「ローカル」を使用します。「ローカル」のサブドメイン。それらが宣伝されているローカルリンクに固有のものです。この利便性は、DNSプロトコルを使用してDNS-SDでは利用できません。サービスは、ネットワークオペレーターまたは自動的に選択される特定のDNS名前空間に存在する必要があります。
As described above, full-featured devices are responsible for knowing the domain in which to register their services. Such devices MAY optionally support configuration of a registration domain by the operator of the device. However, such devices MUST support registration domain discovery as described in Section 11 of the DNS-SD specification [RFC6763].
上記のように、フル機能のデバイスは、サービスを登録するドメインを知る責任があります。このようなデバイスは、デバイスのオペレーターによる登録ドメインの構成をオプションでサポートする場合があります。ただし、そのようなデバイスは、DNS-SD仕様[RFC6763]のセクション11で説明されているように、登録ドメインの発見をサポートする必要があります。
Devices made for CNNs register in the special-use domain name [RFC6761] "default.service.arpa." and let the SRP registrar handle rewriting that to a different domain if necessary, as mentioned in Section 3.1.2.
特別使用ドメイン名[RFC6761]でCNNSレジスタ用に作成されたデバイス「default.service.arpa」セクション3.1.2に記載されているように、必要に応じて、必要に応じて別のドメインに書き換えます。
It is possible to send a DNS Update message that does several things at once: For example, it's possible in a single transaction to add or update a single Host Description while also adding or updating the RRs comprising the Service Description(s) for one or more service instance(s) available on that host and adding or updating the RRs comprising the Service Discovery instruction(s) for those service instance(s).
一度にいくつかのことを行うDNSアップデートメッセージを送信することができます。たとえば、単一のトランザクションでは、ホストで利用可能な1つ以上のサービスインスタンスのサービス説明を含むRRSを追加または更新することが可能です。
An SRP Update takes advantage of this: It is implemented as a single DNS Update message that contains a service's Service Discovery records, Service Description records, and Host Description records.
SRPアップデートはこれを利用します。これは、サービスのサービスディスカバリーレコード、サービスの説明レコード、およびホストの説明レコードを含む単一のDNSアップデートメッセージとして実装されています。
Updates done according to this specification are somewhat different from normal DNS Updates [RFC2136] where the update process could involve many update attempts. The requester might first attempt to add a name if it doesn't exist; if that fails, then in a second message the requester might update the name if it does exist but matches certain preconditions. Because the Service Registration Protocol described in this document uses a single transaction, some of this adaptability is lost.
この仕様に従って行われた更新は、更新プロセスに多くの更新試行が含まれる可能性がある通常のDNSアップデート[RFC2136]とは多少異なります。要求者は、最初に存在しない場合に名前を追加しようとする場合があります。それが失敗した場合、2番目のメッセージで、要求者は存在する場合は名前を更新する可能性がありますが、特定の前提条件に一致します。このドキュメントで説明されているサービス登録プロトコルは単一のトランザクションを使用しているため、この適応性の一部は失われます。
In order to allow updates to happen in a single transaction, SRP Updates do not include update prerequisites. The requirements specified in Section 3.3 are implicit in the processing of SRP Updates; thus, there is no need for the SRP requester to put in any explicit prerequisites.
単一のトランザクションでアップデートが発生することを許可するために、SRPアップデートには更新の前提条件が含まれていません。セクション3.3で指定された要件は、SRP更新の処理に暗黙的です。したがって、SRP要求者が明示的な前提条件を入力する必要はありません。
DNS-SD Service Registration uses the DNS Update specification [RFC2136] with some additions:
DNS-SDサービス登録は、いくつかの追加を使用してDNSアップデート仕様[RFC2136]を使用します。
* It implements FCFS Naming, protected using SIG(0) [RFC2931].
* SIG（0）[RFC2931]を使用して保護されたFCFSネーミングを実装します。
* It enforces policy about what updates are allowed.
* 更新が許可されていることに関するポリシーが実施されます。
* It optionally performs rewriting of "default.service.arpa." to some other domain.
* オプションで「default.service.arpa」の書き換えを実行します。他のドメインに。
* It optionally performs automatic population of the address-to-name reverse mapping domains.
* オプションで、アドレスから名前への逆マッピングドメインの自動母集団を実行します。
* An SRP registrar is not required to implement general DNS Update prerequisite processing.
* 一般的なDNS更新前提条件処理を実装するためにSRPレジストラは必要ありません。
* CNN SRP requesters are allowed to send updates to the generic domain "default.service.arpa.".
* CNN SRP要求者は、一般的なドメイン「Default.service.arpa」に更新を送信できます。
The DNS protocol, including DNS updates, can operate over UDP or TCP. For UDP updates from CNN devices, reliable transmission must be guaranteed by retransmitting when a DNS UDP message is not acknowledged in a reasonable interval. Section 4.2.1 of the DNS specification [RFC1035] provides some guidance on this topic, as does Section 1 of the IETF document describing common DNS implementation errors [RFC1536]. Section 3.1.3 of the UDP Usage Guidelines document [RFC8085] also provides useful guidance that is particularly relevant to DNS.
DNSアップデートを含むDNSプロトコルは、UDPまたはTCPを介して動作できます。CNNデバイスからのUDP更新の場合、DNS UDPメッセージが合理的な間隔で認められていない場合に再送信することにより、信頼できる伝送を保証する必要があります。DNS仕様[RFC1035]のセクション4.2.1は、一般的なDNS実装エラー[RFC1536]を説明するIETFドキュメントのセクション1と同様に、このトピックに関するいくつかのガイダンスを提供します。UDP使用ガイドラインドキュメント[RFC8085]のセクション3.1.3は、DNSに特に関連する有用なガイダンスも提供します。
SRP does not require that every update contain the same information. When an SRP requester needs to send more than one SRP Update to the SRP registrar, it SHOULD combine these into a single SRP Update, when possible, subject to DNS message size limits and link-specific size limits (e.g., an IEEE 802.15.4 network will perform poorly when asked to deliver a packet larger than about 500 bytes). If the updates do not fit into a single SRP Update, then the SRP requester MUST send subsequent SRP Updates sequentially: Until an earlier SRP Update has been acknowledged, the requester MUST NOT send any subsequent SRP Updates. If a configuration change occurs while an outstanding SRP Update is in flight, the SRP registrar MUST defer sending a new SRP Update for that change until the previous SRP Update has completed.
SRPは、すべてのアップデートに同じ情報が含まれることを要求しません。SRP要求者がSRPレジストラに複数のSRPアップデートを送信する必要がある場合、DNSメッセージサイズの制限とリンク固有のサイズの制限を条件として、これらを単一のSRPアップデートに組み合わせる必要があります（たとえば、IEEE 802.15.4ネットワークは、約500バイトよりも大きいパケットを配信すると依頼するとパフォーマンスが低下します）。更新が単一のSRPアップデートに収まらない場合、SRP要求者は以前のSRPアップデートを順番に送信する必要があります。以前のSRPアップデートが認められるまで、リクエスターは後続のSRPアップデートを送信してはなりません。優れたSRPアップデートが飛行中に構成の変更が発生した場合、SRPレジストラは、以前のSRPアップデートが完了するまで、その変更の新しいSRPアップデートの送信を延期する必要があります。
DNS Update messages can be secured using secret key transaction signatures (TSIG) [RFC8945]. This approach uses a secret key shared between the DNS Update requester (which issues the update) and the authoritative DNS server (which authenticates it). This model does not work for automatic service registration.
DNS更新メッセージは、Secret Key Transaction Signatures（TSIG）[RFC8945]を使用して保護できます。このアプローチは、DNSアップデートリクエスター（更新を発行する）と権威あるDNSサーバー（認証）の間で共有されるシークレットキーを使用します。このモデルは、自動サービス登録には機能しません。
The goal of securing the DNS-SD Registration Protocol is to provide the best possible security given the constraint that service registration has to be automatic. It is possible to layer more operational security on top of what we describe here, but FCFS Naming is already an improvement over the security of mDNS.
DNS-SD登録プロトコルを確保するという目標は、サービス登録が自動でなければならないという制約を考えると、可能な限り最高のセキュリティを提供することです。ここで説明しているものに加えて、より多くの運用セキュリティを重ねることは可能ですが、FCFSネーミングはすでにMDNSのセキュリティよりも改善されています。
FCFS Naming provides a limited degree of security. A server that registers its service using SRP is given ownership of a name for an extended period of time based on a lease specific to the key used to authenticate the SRP Update, which may be longer than the lease associated with the registered RRs. As long as the registrar remembers the name and the public key corresponding to the private key used to register RRs on that name, no other SRP requester can add or update the information associated with that name. If the SRP requester fails to renew its service registration before the KEY lease expires (Section 4 of the DNS Update Lease specification [RFC9664]) its name is no longer protected. FCFS Naming is used to protect both the Service Description and the Host Description.
FCFSネーミングは、限られた程度のセキュリティを提供します。SRPを使用してサービスを登録するサーバーには、SRPアップデートの認証に使用されるキーに固有のリースに基づいて、長期間にわたって名前の所有権が与えられます。これは、登録されたRRSに関連するリースよりも長い場合があります。レジストラがその名前でRRを登録するために使用される秘密鍵に対応する名前と公開キーを覚えている限り、他のSRP要求者はその名前に関連付けられた情報を追加または更新することはできません。Keyリースの有効期限が切れる前にSRPリクエスト担当者がサービス登録を更新できない場合（DNSアップデートリース仕様[RFC9664]）、その名前はもはや保護されていません。FCFSネーミングは、サービスの説明とホストの説明の両方を保護するために使用されます。
The requester generates a public/private key pair (Section 6.6). This key pair MUST be stored in stable storage; if there is no writable stable storage on the SRP requester, the SRP requester MUST be preconfigured with a public/private key pair in read-only storage. This key pair MUST be unique to the device. A device with rewritable storage SHOULD retain this key indefinitely. When the device changes ownership, it may be appropriate for the former owner to erase the old key pair, which would then require the new owner to install a new one. Therefore, the SRP requester on the device SHOULD provide a mechanism to erase the key (for example, as the result of a "factory reset") and to generate a new key.
リクエスターは、パブリック/プライベートキーペアを生成します（セクション6.6）。このキーペアは、安定したストレージに保存する必要があります。SRPリクエスト担当者に書き込み可能な安定したストレージがない場合、SRPリクエスト担当者は、読み取り専用ストレージにパブリック/プライベートキーペアを使用して事前に設定する必要があります。このキーペアは、デバイスに固有のものでなければなりません。書き換え可能なストレージを備えたデバイスは、このキーを無期限に保持する必要があります。デバイスが所有権を変更すると、前の所有者が古いキーペアを消去することが適切かもしれません。これにより、新しい所有者が新しい所有者をインストールする必要があります。したがって、デバイス上のSRP要求者は、キー（たとえば、「工場リセット」の結果として）を消去し、新しいキーを生成するメカニズムを提供する必要があります。
Note that when a new key is generated, this will prevent the device from registering with the name associated with the old key in the same domain where it had previously registered. So, implicit in the generation of a new key is the generation of a new name; this can be done either proactively when regenerating a key or only in the event that the SRP update produces a name conflict.
新しいキーが生成されると、これにより、デバイスが以前に登録されていた同じドメインの古いキーに関連付けられた名前に登録できないことに注意してください。したがって、新しいキーの生成に暗示されていることは、新しい名前の生成です。これは、キーを再生するときに積極的に行うことができます。また、SRPアップデートが名前の競合を生成した場合にのみ実行できます。
The policy described here for managing keys assumes that the keys are only used for SRP. If a key that is used for SRP is also used for other purposes, the policy described here is likely to be insufficient. The policy stated here is NOT RECOMMENDED in such a situation: a policy appropriate to the full set of uses for the key must be chosen. Specifying such a policy is out of scope for this document.
キーの管理に関するここで説明されているポリシーは、キーがSRPにのみ使用されると想定しています。SRPに使用されるキーが他の目的にも使用されている場合、ここで説明するポリシーは不十分である可能性があります。このような状況では、ここに記載されているポリシーは推奨されません。キーの使用の完全なセットに適したポリシーを選択する必要があります。このようなポリシーを指定することは、このドキュメントの範囲外です。
When sending DNS updates, the requester includes a KEY record containing the public portion of the key in each Host Description Instruction and each Service Description Instruction. Each KEY record MUST contain the same public key. The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record. The lifetimes of the records in the update are set using the EDNS(0) Update Lease option [RFC9664].
DNSアップデートを送信するとき、リクエスターには、各ホスト説明命令と各サービス説明命令のキーの公開部分を含むキーレコードが含まれています。各キーレコードには同じ公開キーが含まれている必要があります。この更新は、キーレコードの公開キーに対応する秘密鍵を使用して、SIG（0）を使用して署名されます。アップデート内のレコードの寿命は、EDNS（0）アップデートリースオプション[RFC9664]を使用して設定されます。
The format of the KEY resource record in the SRP Update is defined in the IETF specification for DNSSEC Resource Records [RFC4034]. Because the KEY RR used in SIG(0) is not a zone-signing key, the flags field in the KEY RR MUST be all zeroes.
SRPアップデートのキーリソースレコードの形式は、DNSSECリソースレコード[RFC4034]のIETF仕様で定義されています。SIG（0）で使用されるキーRRはゾーン署名キーではないため、キーRRのフラグフィールドはすべてゼロでなければなりません。
The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the same KEY record that is given for the Host Description is also given for each Service Description for which no KEY record is provided. Omitted KEY records are not used when computing the SIG(0) signature.
サービスの説明の主要な記録は、簡潔にするために省略される場合があります。省略されている場合、SRPレジストラは、キーレコードが提供されていない各サービス説明に対してホストの説明に与えられた同じキーレコードも与えられているかのように振る舞う必要があります。省略されたキーレコードは、SIG（0）署名を計算するときに使用されません。
"Add" operations for both Host Description RRs and Service Description RRs can have names that result in name conflicts. Service Discovery record "Add" operations cannot have name conflicts. If any Host Description or Service Description record is found by the SRP registrar to have a conflict with an existing name, the registrar will respond to the SRP Update with a YXDomain RCODE [RFC2136], indicating that the desired name is already owned by a different SIG(0) key. In this case, the SRP requester MUST choose a new name or give up.
ホストの説明RRとサービスの説明の両方の「追加」操作RRSには、名前の競合をもたらす名前を持つことができます。サービスディスカバリーレコード「追加」操作には、名前が競合することはできません。SRPレジストラが既存の名前と競合するためにホストの説明またはサービスの説明レコードが見つかった場合、レジストラはYXDomain RCode [RFC2136]を使用してSRPアップデートに応答します。この場合、SRP要求者は新しい名前を選択するか、あきらめる必要があります。
There is no specific requirement for how the SRP requester should choose a new name. Typically, however, the requester will append a number to the preferred name. This number could be sequentially increasing or could be chosen randomly. One existing implementation attempts several sequential numbers before choosing randomly. For instance, it might try host.default.service.arpa., then host-1.default.service.arpa., then host-2.default.service.arpa., then host-31773.default.service.arpa.
SRP要求者が新しい名前を選択する方法については、特定の要件はありません。ただし、通常、リクエスターは優先名に番号を追加します。この数値は連続的に増加するか、ランダムに選択することができます。既存の実装の1つは、ランダムに選択する前にいくつかのシーケンシャル番号を試みます。たとえば、host.default.service.arpa。、その後host-1.default.service.arpa。、host-2.default.service.arpa。、host-31773.default.service.arpaを試してみることがあります。
The lifetime of the DNS-SD PTR, SRV, A, AAAA, and TXT records [RFC6763] uses the LEASE field of the Update Lease option and is typically set to two hours. Thus, if a device is disconnected from the network, it does not continue to appear for too long in the user interfaces of devices looking for instances of that service type.
DNS-SD PTR、SRV、A、AAAA、およびTXT Records [RFC6763]の寿命は、アップデートリースオプションのリースフィールドを使用し、通常2時間に設定されます。したがって、デバイスがネットワークから切断されている場合、そのサービスタイプのインスタンスを探しているデバイスのユーザーインターフェイスにはあまり長く表示され続けません。
The lifetime of the KEY records is set using the KEY-LEASE field of the Update Lease Option and SHOULD be set to a much longer time, typically 14 days. The result being that even though a device may be temporarily disconnected or powered off -- disappearing from the network for a few days -- it makes a claim on its name that lasts much longer.
キーレコードの寿命は、更新リースオプションのキーリースフィールドを使用して設定され、通常14日間、はるかに長い時間に設定する必要があります。その結果、デバイスが一時的に切断されたり、電源を切ったりしても、数日間ネットワークから消えてしまう可能性がありますが、その名前がずっと長く続くと主張することになります。
Therefore, even if a device is disconnected from the network for a few days, and its services are not available for that time, no other device can come along and claim its name the moment it disappears from the network. In the event that a device is disconnected from the network and permanently discarded, then its name is eventually cleaned up and made available for reuse.
したがって、デバイスがネットワークから数日間切断され、そのサービスが利用できない場合でも、他のデバイスが登場し、ネットワークから消えた瞬間にその名前を請求することはできません。デバイスがネットワークから切断され、永続的に廃棄された場合、その名前は最終的にクリーンアップされ、再利用できるようになります。
Although the original SRV specification [RFC2782] requires that the target hostname in the RDATA of an SRV record not be compressed in DNS queries and responses, an SRP requester MAY compress the target in the SRV record, since an SRP Update is neither a DNS query nor a DNS response. The motivation for _not_ compressing is not stated in the SRV specification but is assumed to be because a recursive resolver (caching server) that does not understand the format of the SRV record might store it as binary data without decoding a compression pointer embedded with the target hostname field and thus return nonsensical RDATA in response to a query. This concern does not apply in the case of SRP. An SRP registrar needs to understand SRV records in order to validate the SRP Update. Compression of the target can save space in the SRP Update, so we want SRP requesters to be able to assume that the registrar will handle this. Therefore, SRP registrars MUST support compression of SRV RR targets.
元のSRV仕様[RFC2782]では、SRVレコードのRDATAのターゲットホスト名がDNSクエリと応答で圧縮されないことが必要ですが、SRPリクエストターはSRVレコードのターゲットを圧縮することができます。_NOT_圧縮の動機は、SRV仕様に記載されていませんが、SRVレコードの形式を理解していない再帰リゾルバー（キャッシュサーバー）が、ターゲットホスト名フィールドに埋め込まれた圧縮ポインターをデコードせずにバイナリデータとして保存する可能性があるため、想定されているためです。この懸念は、SRPの場合には適用されません。SRPレジストラは、SRPアップデートを検証するためにSRVレコードを理解する必要があります。ターゲットの圧縮により、SRPアップデートのスペースを節約できるため、SRPリクエスト担当者にレジストラがこれを処理すると仮定できるようにしたいと考えています。したがって、SRPレジストラは、SRV RRターゲットの圧縮をサポートする必要があります。
Note that this document does not update the SRV specification [RFC2782]: Authoritative DNS servers still MUST NOT compress SRV record targets. The requirement to accept compressed SRV records in updates only applies to SRP registrars. SRP registrars that are also authoritative DNS servers still MUST NOT compress SRV record targets in DNS responses. We note also that Multicast DNS [RFC6762] similarly compresses SRV records in mDNS messages.
このドキュメントは、SRV仕様[RFC2782]を更新しないことに注意してください。信頼できるDNSサーバーは、SRVレコードターゲットを圧縮してはなりません。更新で圧縮されたSRVレコードを受け入れる要件は、SRPレジストラにのみ適用されます。権威あるDNSサーバーでもあるSRPレジストラは、DNS応答でSRVレコードターゲットを圧縮してはなりません。また、マルチキャストDNS [RFC6762]が同様にMDNSメッセージでSRVレコードを圧縮することに注意してください。
In addition, we note that an implementer of an SRP requester might update existing code that creates SRV records or compresses DNS messages so that it compresses the target of an SRV record. Care must be taken if such code is used both in requesters and in authoritative DNS servers that the code only compresses SRV targets in the case where a requester is generating an SRP Update.
さらに、SRP要求者の実装者は、SRVレコードを作成する既存のコードを更新するか、DNSメッセージを圧縮してSRVレコードのターゲットを圧縮する場合があることに注意してください。要求者がSRPアップデートを生成している場合にコードがSRVターゲットのみを圧縮するという要求者と権威あるDNSサーバーの両方でそのようなコードが使用される場合は、注意する必要があります。
To remove all the services registered to a particular hostname, the SRP requester transmits an SRP Update for that hostname with an Update Lease option that has a LEASE value of zero. The SRP Update MUST contain exactly one Host Description Instruction that contains exactly one "Delete All RRsets From A Name" instruction for the hostname and no "Add to an RRSet" instructions for that hostname. If the registration is to be permanently removed, KEY-LEASE SHOULD also be zero. Otherwise, it SHOULD be set to the same value it had previously; this holds the name in reserve for when the SRP requester is once again able to provide the service.
特定のホスト名に登録されているすべてのサービスを削除するために、SRP Requesterは、ゼロのリース値を持つ更新リースオプションを使用して、そのホスト名のSRPアップデートを送信します。SRPアップデートには、ホスト名の「名前からすべてのrrsetを削除する」という正確に1つの「すべてのrrsetを削除する」と正確に1つのホスト説明命令を含む必要があります。登録を永久に削除する場合、キーリースもゼロにする必要があります。それ以外の場合は、以前に持っていたのと同じ値に設定する必要があります。これにより、SRP要求者が再びサービスを提供できる場合、予備の名前が保持されます。
This method of removing services is intended for the case where the requester is going offline and does not want any of its services to continue being advertised.
サービスを削除するこの方法は、リクエスターがオフラインになっており、そのサービスのいずれかが宣伝され続けることを望まない場合を対象としています。
To support this, when removing a hostname, an SRP registrar MUST remove all service instances pointing to that hostname and all Service Discovery PTR records pointing to those service instances, even if the SRP requester doesn't list them explicitly. If the KEY lease time is nonzero, the SRP registrar MUST NOT delete the KEY records for these service instances.
これをサポートするために、ホスト名を削除する場合、SRPレジストラは、SRP要求者がそれらを明示的にリストしていなくても、そのホスト名とすべてのサービスディスカバリーPTRレコードを指すすべてのサービスインスタンスとそれらのサービスインスタンスを指すすべてのサービスインスタンスを削除する必要があります。キーリース時間がゼロでない場合、SRPレジストラはこれらのサービスインスタンスのキーレコードを削除してはなりません。
In some use cases, a requester may need to remove a specific service instance without removing its other services. For example, a device may shut down its remote screen access (_rfb._tcp) service while retaining its command-line login (_ssh._tcp) service. This can be accomplished in one of two ways:
一部のユースケースでは、要求者は他のサービスを削除せずに特定のサービスインスタンスを削除する必要がある場合があります。たとえば、デバイスは、コマンドラインログイン（_SSH._TCP）サービスを保持しながら、リモート画面アクセス（_RFB._TCP）サービスをシャットダウンする場合があります。これは、2つの方法のいずれかで達成できます。
1. To simply remove a specific service instance, the requester sends a valid SRP Update with a Service Description Instruction (Section 3.3.1.2) containing a single "Delete All RRsets From A Name" update to the service instance name. The SRP Update SHOULD include Service Discovery Instructions (Section 3.3.1.1) consisting of "Delete An RR From An RRset" updates [RFC2136] that delete any Service Discovery PTR records whose target is the service instance name. However, even in the absence of such Service Discovery Instructions, the SRP registrar MUST delete any Service Discovery PTR records that point to the deleted service instance name.
1. 特定のサービスインスタンスを単純に削除するために、リクエスターは、単一の「名前からすべてのrrsetを削除する」update update in the Serviceインスタンス名を含むサービス説明命令（セクション3.3.1.2）を使用して有効なSRPアップデートを送信します。SRPアップデートには、「RRSetからRRを削除する」Updates [RFC2136]で構成されるサービス発見指示（セクション3.3.1.1）を含める必要があります。ただし、このようなサービスディスカバリーの指示がない場合でも、SRPレジストラは、削除されたサービスインスタンス名を指すサービスディスカバリーPTRレコードを削除する必要があります。
2. When deleting one service instance while simultaneously creating a new service instance with a different service instance name, an alternative is to perform both operations using a single SRP Update. In this case, the old service is deleted as in the first alternative. The new service is added, just as it would be in an update that wasn't deleting the old service. Because both the removal of the old service and the add of the new service consist of a valid Service Discovery Instruction and a valid Service Description Instruction, the update as a whole is a valid SRP Update and will result in the old service being removed and the new one added; or, to put it differently, the SRP Update will result in the old service being replaced by the new service.
2. 異なるサービスインスタンス名を使用して新しいサービスインスタンスを同時に作成しながら1つのサービスインスタンスを削除する場合、代替案は、単一のSRPアップデートを使用して両方の操作を実行することです。この場合、古いサービスは最初の代替品のように削除されます。古いサービスを削除しなかったアップデートにあるのと同じように、新しいサービスが追加されます。古いサービスの削除と新しいサービスの追加の両方が有効なサービスディスカバリー命令と有効なサービス説明命令で構成されているため、アップデート全体は有効なSRPアップデートであり、古いサービスが削除され、新しいサービスが追加されます。または、異なる方法で言うと、SRPアップデートにより、古いサービスが新しいサービスに置き換えられます。
It is perhaps worth noting that if a service is being updated without the service instance name changing (for example, when only the target port in the SRV record is being updated), then that SRP Update will look very much like the second alternative above. The PTR record in the Service Discovery Instruction will be the same for both the "Delete An RR From An RRset" update and the "Add To An RRset" update [RFC2136]. Since the removal of the old service and the addition of the new service are both valid SRP Update operations, the combined operation is a valid SRP Update operation. The SRP registrar does not need to include code to recognize this special case and does not need to take any special actions to handle it correctly.
サービスインスタンス名が変更されずにサービスが更新されている場合（たとえば、SRVレコードのターゲットポートのみが更新されている場合）、そのSRPアップデートは上記の2番目の代替品と非常によく似ていることに注意する価値があります。Service Discovery命令のPTRレコードは、「RRSetからRRを削除する」アップデートと「RRSetに追加」アップデート[RFC2136]の両方で同じになります。古いサービスの削除と新しいサービスの追加は両方とも有効なSRPアップデート操作であるため、複合操作は有効なSRPアップデート操作です。SRPレジストラは、この特別なケースを認識するためにコードを含める必要はなく、それを正しく処理するために特別なアクションをとる必要はありません。
Whichever of these two alternatives is used, the hostname lease will be updated with the lease time provided in the SRP update. In neither of these cases is it permissible to delete the hostname. All services must point to a hostname. If a hostname is to be deleted, this must be done using the method described in Section 3.2.5.5.1, which deletes the hostname and all services that have that hostname as their target.
これらの2つの代替品のいずれかが使用されている場合でも、SRPアップデートで提供されるリース時間とともにホスト名のリースが更新されます。どちらの場合も、ホスト名を削除することは許可されていません。すべてのサービスは、ホスト名を指す必要があります。ホスト名を削除する場合、これはセクション3.2.5.5.1で説明されているメソッドを使用して実行する必要があります。セクション3.2.5.5.1は、ホスト名とそのホスト名をターゲットとして削除するすべてのサービスを削除します。
The SRP registrar first validates that the DNS Update message is a syntactically and semantically valid DNS Update message according to the usual DNS Update rules [RFC2136].
SRPレジストラは、最初に、DNS更新メッセージが通常のDNS更新ルール[RFC2136]に従って構文的および意味的に有効なDNS更新メッセージであることを検証します。
SRP Updates consist of a set of _instructions_ that together add or remove one or more services. Each _instruction_ consists of one or more delete update(s), or one or more add update(s), or some combination of both delete updates and add updates.
SRPの更新は、1つ以上のサービスを追加または削除する_instructions_のセットで構成されています。各_INSTRUCTION_は、1つまたは複数の削除アップデート、または1つ以上の更新を追加する、または更新を削除して更新を追加する両方の組み合わせで構成されています。
The SRP registrar checks each instruction in the SRP Update to see that it is either a Service Discovery Instruction, a Service Description Instruction, or a Host Description Instruction. Order matters in DNS updates. Specifically, deletes must precede adds for records that the deletes would affect; otherwise, the add will have no effect. This is the only ordering constraint: Aside from this constraint, updates may appear in whatever order is convenient when constructing the update.
SRPレジストラは、SRPアップデートの各命令をチェックして、サービスの発見命令、サービス説明命令、またはホストの説明命令のいずれかであることを確認します。DNSアップデートで問題を注文します。具体的には、削除は、削除が影響するレコードの追加の追加を先行する必要があります。それ以外の場合、ADDには効果がありません。これが唯一の順序付け制約です。この制約は別として、更新を構築するときに便利な順序で更新が表示される場合があります。
Because the SRP Update is a DNS update, it MUST contain a single entry in the Zone Section (what would be the Question Section in a DNS query or response) that indicates the zone to be updated. Every delete and update in an SRP Update MUST be within the zone that is specified for the SRP Update.
SRPアップデートはDNSアップデートであるため、ゾーンセクションに単一のエントリ（DNSクエリまたは応答の質問セクションとは何か）を含める必要があります。SRPアップデートのすべての削除と更新は、SRPアップデート用に指定されているゾーン内にある必要があります。
An instruction is a Service Discovery Instruction if it:
指示は、それがあればサービス発見の指示です。
* consists of exactly one "Add To An RRSet" or exactly one "Delete An RR From An RRSet" RR update (Section 2.5 of the DNS Update specification [RFC2136]),
* 正確に1つの「RRSetに追加」または「RRSet」RRアップデートからRRを削除する正確な「DNSアップデート仕様[RFC2136]）で構成されています。
* which updates a PTR RR,
* PTR RRを更新します。
* the target of which is a service instance name
* その目標はサービスインスタンス名です
* for which name a Service Description Instruction is present in the SRP Update, and:
* SRPアップデートには、サービスの説明命令が存在します。
- if the Service Discovery Instruction is an "Add To An RRSet" instruction, that Service Description Instruction contains a "Delete All RRsets From A Name" instruction for that service instance name followed by "Add To An RRset" instructions for the SRV and TXT records describing that service; or
- サービスディスカバリー命令が「RRSetに追加」命令である場合、そのサービスの説明命令には、そのサービスインスタンス名の「名前」命令の「すべてのrrset」が含まれています。または
- if the Service Discovery Instruction is a "Delete An RR From An RRSet" instruction, that Service Description Instruction contains a "Delete All RRsets From A Name" instruction for that service instance name with no following "Add To An RRset" instructions for the SRV and TXT records describing that service. An "Add to an RRset" instruction for the KEY record here is allowed but not implicit.
- サービスディスカバリー命令が「RRSetからRRを削除する」命令である場合、そのサービスの説明には、そのサービスインスタンス名の「名前」という名前の「すべてのrrset」が含まれています。ここでのキーレコードの「RRSetに追加」命令は許可されていますが、暗黙的ではありません。
Note that there can be more than one Service Discovery Instruction for the same service name (the owner name of the Service Discovery PTR record) if the SRP requester is advertising more than one instance of the same service type or is changing the target of a PTR RR. When subtypes are being used (Section 7.1 of the DNS-SD specification [RFC6763]), each subtype is a separate Service Discovery Instruction. For each such PTR RR add or delete, the above constraints must be met.
SRP要求者が同じサービスタイプの複数のインスタンスを広告しているか、PTR RRのターゲットを変更している場合、同じサービス名（サービスディスカバリーPTRレコードの所有者名）に複数のサービスディスカバリー命令がある可能性があることに注意してください。サブタイプが使用されている場合（DNS-SD仕様のセクション7.1 [RFC6763]）、各サブタイプは別のサービス発見命令です。このようなptr rrを追加または削除するごとに、上記の制約を満たす必要があります。
An instruction is a Service Description Instruction if, for the given service instance name, all of the following are true:
指定されたサービスインスタンス名について、次のすべてが真である場合、命令はサービス説明命令です。
* It contains exactly one "Delete All RRsets From A Name" update for the service instance name (Section 2.5.3 of the DNS Update specification [RFC2136]).
* Serviceインスタンス名（DNS更新仕様[RFC2136]のセクション2.5.3）の「名前からすべてのrrsets」アップデートが正確に1つ含まれています。
* It contains zero or one "Add To An RRset" KEY RRs that, if present, contains the public key corresponding to the private key that was used to sign the message (if present, the KEY RR MUST match the KEY RR given in the Host Description).
* ゼロまたは1つの「RRSetに追加」キーRRSが含まれています。これは、存在する場合、メッセージの署名に使用された秘密鍵に対応する公開キーを含む（存在する場合、キーRRはホストの説明で指定されたキーRRと一致する必要があります）。
* It contains zero or one "Add To An RRset" SRV RR.
* ゼロまたは1つの「RRSetに追加」SRV RRが含まれます。
* If an "Add To An RRSet" update for an SRV RR is present, there MUST be at least one "Add To An RRset" update for the corresponding TXT RR, and the target of the SRV RR MUST be the hostname given in the Host Description Instruction in the SRP Update, or
* SRV RRの「RRSETに追加」アップデートが存在する場合、対応するTXT RRの少なくとも1つの「RRSET」アップデートが必要であり、SRV RRのターゲットは、SRPアップデートのホスト説明命令、またはSRPアップデートまたは
* If there is no "Add To An RRset" update for an SRV RR, then there MUST be no "Add To An RRset" updates for the corresponding TXT RR, and either:
* SRV RRの「RRSETに追加」アップデートがない場合、対応するTXT RRの「RRSETに追加」アップデートはない必要があります。
- the name to which the "Delete All RRsets From A Name" applies does not exist, or
- 「名前からすべてのrrsetを削除する」が適用される名前は存在しない、または
- there is an existing KEY RR on that name that matches the key with which the SRP Update was signed.
- SRPアップデートが署名されたキーと一致する、その名前に既存のキーRRがあります。
Service Description Instructions do not add any other resource records.
サービスの説明手順他のリソースレコードは追加されません。
An SRP registrar MUST correctly handle compressed names in the SRV target.
SRPレジストラは、SRVターゲットの圧縮名を正しく処理する必要があります。
Every SRP Update always contains exactly one Host Description Instruction.
すべてのSRPアップデートには、常に正確に1つのホスト説明命令が含まれています。
An instruction is a Host Description Instruction if, for the appropriate hostname, it contains the following:
命令は、適切なホスト名の場合、以下が含まれている場合、ホスト説明命令です。
* exactly one "Delete All RRsets From A Name" RR
* ちょうど1つの「名前からすべてのrrsetを削除」rr
* exactly one "Add To An RRset" RR that adds a KEY RR that contains the public key corresponding to the private key that was used to sign the message
* メッセージの署名に使用された秘密鍵に対応する公開キーを含むキーRRを追加するキーRRを追加する「RRSetに追加」RRを1つちょうど1つ
* zero "Add To An RRset" operations (in the case of deleting a registration) or one or more "Add To An RRset" RRs of type A and/ or AAAA (in the case of creating or updating a registration)
* Zero "rrset操作に追加（登録の削除の場合）または1つ以上の「rrset」RRSのタイプAおよび/またはAAAA（登録の作成または更新の場合）
Host Description Instructions do not add any other resource records.
ホストの説明手順他のリソースレコードは追加されません。
A and/or AAAA records that are not of sufficient scope to be validly published in a DNS zone MAY be ignored by the SRP registrar, which could result in a Host Description effectively containing zero reachable addresses even when it contains one or more addresses.
DNSゾーンで有効に公開されるのに十分な範囲ではないAおよび/またはAAAAレコードは、SRPレジストラによって無視される場合があります。これにより、1つ以上のアドレスが含まれていても、範囲の範囲のアドレスを効果的に含むホスト説明が得られる可能性があります。
For example, if an IPv4 link-local address [RFC3927] or an IPv6 link-local address [RFC4862] is provided by the SRP requester, the SRP registrar could elect not to publish this in a DNS zone. However, in some situations, the registrar might make the records available through a mechanism such as an advertising proxy only on the specific link from which the SRP Update originated. In such a situation, locally scoped records are still valid.
たとえば、IPv4リンクローカルアドレス[RFC3927]またはIPv6リンクローカルアドレス[RFC4862]がSRP要求者によって提供されている場合、SRPレジストラはこれをDNSゾーンで公開しないことを選択できます。ただし、状況によっては、レジストラは、SRPアップデートが発信された特定のリンクのみの広告プロキシなどのメカニズムを通じてレコードを利用可能にする場合があります。このような状況では、ローカルでスコープされたレコードはまだ有効です。
An SRP Update MUST contain exactly one Host Description Instruction. Multiple Service Discovery updates and Service Description updates may be combined into a single SRP Update along with a single Host Description update, as described in Section 3.2.3. A DNS Update message that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description, or Host Description Instructions is not an SRP Update. A DNS update that contains any prerequisites is not an SRP Update.
SRPアップデートには、正確に1つのホスト説明命令が含まれている必要があります。セクション3.2.3で説明されているように、複数のサービスの発見の更新とサービスの説明の更新を単一のSRPアップデートと単一のホスト説明更新に結合することができます。サービスの発見、サービスの説明、またはホストの説明手順として識別できない追加の追加または削除を含むDNS更新メッセージは、SRPアップデートではありません。前提条件を含むDNSアップデートは、SRPアップデートではありません。
An SRP Update MUST include an EDNS(0) Update Lease option [RFC9664]. The LEASE time specified in the Update Lease option MUST be less than or equal to the KEY-LEASE time. A DNS update that does not include the Update Lease option, or that includes a KEY-LEASE value that is less than the LEASE value, is not an SRP Update.
SRPアップデートには、EDNS（0）更新リースオプション[RFC9664]を含める必要があります。更新リースオプションで指定されたリース時間は、キーリース時間以下でなければなりません。更新リースオプションを含まないDNSアップデート、またはリース値よりも少ないキーリース値を含む、SRPアップデートではありません。
When an SRP registrar receives a DNS Update message that is not an SRP update, it MAY process the update as normal DNS Update [RFC2136], including access control checks and constraint checks, if supported. Otherwise, the SRP registrar MUST reject the DNS Update with the Refused RCODE.
SRPレジストラがSRPアップデートではないDNSアップデートメッセージを受信すると、サポートされていれば、アクセス制御チェックと制約チェックを含む、通常のDNSアップデート[RFC2136]として更新を処理できます。それ以外の場合、SRPレジストラは、拒否されたRCODEでDNSアップデートを拒否する必要があります。
If the definitions of each of these instructions are followed carefully and the update requirements are validated correctly, many DNS Update messages that look very much like SRP Updates nevertheless will fail to validate. For example, a DNS update that contains an "Add To An RRset" instruction for a Service Name and an "Add to an RRset" instruction for a service instance name where the PTR record added to the Service Name does not reference the service instance name is not a valid SRP Update but may be a valid DNS Update.
これらの各命令の定義が慎重に追跡され、更新要件が正しく検証されている場合、多くのDNSは、SRP更新に非常によく似たメッセージを更新しますが、それでも検証に失敗します。たとえば、サービス名の「RRSETに追加」命令を含むDNSアップデートと、サービス名に追加されたPTRレコードがサービスインスタンス名を参照しないサービスインスタンス名の「RRSETに追加」命令を含むDNSアップデートは、有効なSRPアップデートではなく、有効なDNSアップデートである可能性があります。
Assuming that the SRP registrar has confirmed that a DNS Update message is a valid SRP Update (Section 3.3.2), it then checks that the name in the Host Description Instruction exists in the zone being updated. If so, then the registrar checks to see if the KEY record on that name is the same as the KEY record in the Host Description Instruction. The registrar performs the same check for the KEY records in any Service Description Instructions. For KEY records that were omitted from Service Description Instructions, the KEY from the Host Description Instruction is used. If any existing KEY record corresponding to a KEY record in the SRP Update does not match the KEY record in the SRP Update (whether provided or taken from the Host Description Instruction), then the SRP registrar MUST reject the SRP Update with a YXDomain RCODE indicating that the desired name is already owned by a different SIG(0) key. This informs the SRP requester that it should select a different name and try again.
SRPレジストラがDNSアップデートメッセージが有効なSRPアップデートであることを確認したと仮定すると（セクション3.3.2）、ホストの説明命令の名前が更新されていることを確認します。もしそうなら、レジストラはその名前のキーレコードがホスト説明命令のキーレコードと同じかどうかを確認します。レジストラは、サービスの説明手順でキーレコードに対して同じチェックを実行します。サービスの説明命令から省略されたキーレコードの場合、ホストの説明命令のキーが使用されます。SRPアップデートのキーレコードに対応する既存のキーレコードがSRPアップデートのキーレコードと一致しない場合（ホストの説明命令から提供されるか、採取されたかどうか）、SRPレジストラは、希望の名前が既に別のSIG（0）キーが所有していることを示すYxDomain RCodeでSRPアップデートを拒否する必要があります。これにより、SRP要求者に別の名前を選択し、再試行する必要があることが通知されます。
If the SRP Update is not in conflict with existing data in the zone being updated, the SRP registrar validates the SRP Update using SIG(0) against the public key in the KEY record of the Host Description Instruction. If the validation fails, the SRP Update is malformed, and the registrar MUST reject the SRP Update with the Refused RCODE. Otherwise, the SRP Update is considered valid and authentic and is processed as for a normal DNS Update [RFC2136].
SRPアップデートが更新されるゾーン内の既存のデータと競合していない場合、SRPレジストラは、ホスト説明命令のキーレコードで公開キーに対してSIG（0）を使用してSRPアップデートを検証します。検証が失敗した場合、SRPアップデートは奇形であり、レジストラは拒否されたRCodeでSRPアップデートを拒否する必要があります。それ以外の場合、SRPアップデートは有効かつ本物と見なされ、通常のDNSアップデート[RFC2136]のように処理されます。
KEY record updates omitted from Service Description Instruction(s) are processed as if they had been explicitly present. After the SRP Update has been applied, every Service Description that is updated MUST have a KEY RR, which MUST have the same value as the KEY RR that is present in the Host Description to which the Service Description refers.
サービスの説明命令から省略されたキーレコードの更新は、明示的に存在しているかのように処理されます。SRPアップデートが適用された後、更新されるすべてのサービス説明にはキーRRが必要です。これは、サービス説明が参照するホスト説明に存在するキーRRと同じ値を持つ必要があります。
The IETF specification for DNSSEC Resource Records [RFC4034] states that the flags field in the KEY RR MUST be zero except for bit 7, which can be one in the case of a zone key. SRP requesters implementing this version of the SRP specification MUST set the flags field in the KEY RR to all zeroes. SRP registrars implementing this version of the SRP specification MUST accept and store the flags field in the KEY RR as received, without checking or modifying its value.
DNSSECリソースレコード[RFC4034]のIETF仕様は、キーRRのフラグフィールドはビット7を除いてゼロでなければならないことを示しています。これはゾーンキーの場合の場合があります。このバージョンのSRP仕様を実装するSRP要求者は、キーRRのフラグフィールドをすべてのゼロに設定する必要があります。このバージョンのSRP仕様を実装するSRPレジストラは、その価値を確認または変更せずに、受信したキーRRにフラグフィールドを受け入れて保存する必要があります。
SRP registrars MUST treat the update instructions for a service type and all its subtypes as atomic. That is, when a service and its subtypes are being updated, whatever information appears in the SRP Update is the entirety of information about that service and its subtypes. If any subtype appeared in a previous update but does not appear in the current update, then the SRP registrar MUST remove that subtype.
SRPレジストラは、サービスタイプとそのすべてのサブタイプの更新指示をAtomicとして扱う必要があります。つまり、サービスとそのサブタイプが更新されている場合、SRPアップデートに表示される情報は、そのサービスとそのサブタイプに関する情報全体です。以前のアップデートにサブタイプが表示されたが現在の更新に表示されない場合、SRPレジストラはそのサブタイプを削除する必要があります。
There is intentionally no mechanism for deleting a single subtype individually. A delete of a service deletes all of its subtypes. To delete a single subtype individually, an SRP Update must be constructed that contains the service type and all subtypes for that service except for the subtype(s) to be deleted.
単一のサブタイプを個別に削除するメカニズムは意図的にありません。サービスの削除は、すべてのサブタイプを削除します。単一のサブタイプを個別に削除するには、削除するサブタイプを除き、サービスタイプとそのサービスのすべてのサブタイプを含むSRPアップデートを構築する必要があります。
The status that is returned depends on the result of processing the update and can be either NoError, ServFail, Refused, or YXDomain. All other possible outcomes will already have been accounted for when applying the constraints that qualify the update as an SRP Update. The meanings of these responses are explained in Section 2.2 of the DNS Update specification [RFC2136].
返されるステータスは、アップデートの処理の結果によって異なり、NoError、Servfail、拒否、またはYxdomainのいずれかにすることができます。他のすべての可能な結果は、アップデートをSRPアップデートとして適格にする制約を適用する際にすでに説明されています。これらの応答の意味は、DNS更新仕様[RFC2136]のセクション2.2で説明されています。
In the case of a response other than NoError, Section 3.8 of the DNS Update specification [RFC2136] states that the authoritative DNS server is permitted to respond either with no RRs or to copy the RRs sent by the DNS Update client into the response. The SRP requester MUST NOT attempt to validate any RRs that are included in the response. It is possible that a future SRP extension may include per-RR indications as to why the update failed, but at the time of writing this is not specified. So, if an SRP requester were to attempt to validate the RRs in the response, it might reject such a response, since it would contain RRs but probably not a set of RRs identical to what was sent in the SRP Update.
NOERROR以外の応答の場合、DNS更新仕様[RFC2136]のセクション3.8は、権威あるDNSサーバーがRRSなしで応答するか、DNSアップデートクライアントから送信されたRRSを応答にコピーすることが許可されていると述べています。SRP要求者は、応答に含まれるRRSを検証しようとしてはなりません。将来のSRP拡張には、更新が失敗した理由に関するRRごとの適応症が含まれる可能性がありますが、執筆時点ではこれは指定されていません。したがって、SRP要求者が応答のRRを検証しようとした場合、RRSが含まれているが、おそらくSRPアップデートで送信されたものと同一のRRSセットではないため、そのような応答を拒否する可能性があります。
The SRP registrar MAY add a Reverse Mapping PTR record (described for IPv4 in Section 3.5 of the DNS specification [RFC1035] and for IPv6 in Section 2.5 of the later document updating DNS for IPv6 [RFC3596]) that corresponds to the Host Description. This is optional: The reverse mapping PTR record serves no essential protocol function. One reason to provide reverse mappings is that they can be used to annotate logs and network packet traces. In order for the registrar to do a reverse mapping update, it must be authoritative for the zone that would need to be updated or have credentials to do the update. The SRP requester MAY also do a reverse mapping update if it has credentials to do so.
SRPレジストラは、ホストの記述に対応するIPv6 [RFC3596]のDNSを更新する後のドキュメントのセクション2.5のDNS仕様[RFC1035]のセクション3.5のIPv4について説明されている逆マッピングPTRレコードを追加できます。これはオプションです。リバースマッピングPTRレコードは、必須のプロトコル関数を機能させません。逆マッピングを提供する理由の1つは、ログとネットワークパケットトレースの注釈に使用できることです。レジストラがリバースマッピングアップデートを実行するためには、更新する必要があるゾーンの権威あるか、更新を行うために資格情報を持つ必要があります。SRP要求者は、資格情報がある場合、リバースマッピングアップデートを実行する場合があります。
The SRP registrar MAY apply additional criteria when accepting updates. In some networks, it may be possible to do out-of-band registration of keys and only accept updates from preregistered keys. In this case, an update for a key that has not been registered SHOULD be rejected with the Refused RCODE. When use of managed keys is desired, there are at least two benefits to doing this in conjunction with SRP rather than simply performing traditional DNS Updates using SIG(0) keys:
SRPレジストラは、更新を受け入れるときに追加の基準を適用する場合があります。一部のネットワークでは、キーの帯域外登録を行い、事前登録されたキーからの更新のみを受け入れることができる場合があります。この場合、登録されていないキーの更新は、拒否されたRCodeで拒否されるべきです。マネージドキーの使用が必要な場合、SIG（0）キーを使用して従来のDNSアップデートを単に実行するだけでなく、SRPと併せてこれを行うことには少なくとも2つの利点があります。
1. The same over-the-air registration protocol is used in both cases, so both use cases can be addressed by the same SRP requester implementation.
1. どちらの場合も、同じ空気登録プロトコルが使用されているため、両方のユースケースに同じSRP要求者の実装で対処できます。
2. The Service Registration Protocol includes maintenance functionality not present with normal DNS updates.
2. サービス登録プロトコルには、通常のDNS更新が存在しないメンテナンス機能が含まれています。
Note that the semantics of using SRP in this way are different from the semantics of typical implementations of DNS Update. The KEY used to sign the SRP Update only allows the SRP requester to update records that refer to its Host Description. Implementations of traditional DNS Update [RFC2136] do not normally provide a way to enforce a constraint of this type.
この方法でSRPを使用するセマンティクスは、DNSアップデートの典型的な実装のセマンティクスとは異なることに注意してください。SRPアップデートに署名するために使用されるキーは、SRP要求者がホストの説明を参照するレコードを更新することのみを可能にします。従来のDNSアップデート[RFC2136]の実装は、通常、このタイプの制約を実施する方法を提供しません。
The SRP registrar could also have a dictionary of names or name patterns that are not permitted. If such a list is used, updates for service instance names that match entries in the dictionary are rejected with a Refused RCODE.
SRPレジストラには、許可されていない名前または名前のパターンの辞書も持つことができます。そのようなリストが使用されている場合、辞書のエントリに一致するサービスインスタンス名の更新は、拒否されたRCodeで拒否されます。
All RRs within an RRset are required to have the same TTL (required by Section 5.2 of the DNS Clarifications document [RFC2181]). In order to avoid inconsistencies, SRP places restrictions on TTLs sent by requesters and requires that SRP registrars enforce consistency.
RRSET内のすべてのRRSには、同じTTLが必要です（DNS Clarifications Document [RFC2181]のセクション5.2で要求されます）。矛盾を回避するために、SRPはリクエスターが送信したTTLに制限を設定し、SRPレジストラが一貫性を実施することを要求します。
Requesters sending SRP Updates MUST use consistent TTLs in all RRs within each RRset contained within an SRP Update.
SRPアップデートを送信する要求者は、SRPアップデート内に含まれる各RRSet内のすべてのRRで一貫したTTLを使用する必要があります。
SRP registrars MUST check that the TTLs for all RRs within each RRset contained within an SRP Update are the same. If they are not, the SRP update MUST be rejected with a Refused RCODE.
SRPレジストラは、SRPアップデート内に含まれる各RRSet内のすべてのRRSのTTLが同じであることを確認する必要があります。そうでない場合、SRPアップデートは拒否されたRcodeで拒否されなければなりません。
Additionally, when adding RRs to an RRset (for example, when processing Service Discovery records), the SRP registrar MUST use the same TTL on all RRs in the RRset. How this consistency is enforced is up to the implementation.
さらに、RRSをRRSETに追加する場合（たとえば、サービスディスカバリーレコードを処理するとき）、SRPレジストラはRRSEのすべてのRRで同じTTLを使用する必要があります。この一貫性がどのように施行されるかは、実装によるものです。
TTLs sent in SRP Updates are advisory: they indicate the SRP requester's guess as to what a good TTL would be. SRP registrars may override these TTLs. SRP registrars SHOULD ensure that TTLs are reasonable: neither too long nor too short. The TTL SHOULD NOT ever be longer than the lease time (Section 5.1). Shorter TTLs will result in more frequent data refreshes; this increases latency on the DNS-SD client side, increases load on any caching resolvers and on the authoritative DNS server, and also increases network load, which may be an issue for CNNs. Longer TTLs will increase the likelihood that data in caches will be stale. TTL minimums and maximums SHOULD be configurable by the operator of the SRP registrar.
SRPアップデートで送信されたTTLSはアドバイザリーです。これらは、優れたTTLが何であるかについてのSRPリクエスト担当者の推測を示しています。SRPレジストラは、これらのTTLをオーバーライドする場合があります。SRPレジストラは、TTLが合理的であることを確認する必要があります。長すぎたり短すぎたりしません。TTLは、リース時間よりも長くはないはずです（セクション5.1）。TTLが短くなると、より頻繁にデータリフレッシュが発生します。これにより、DNS-SDクライアント側の遅延が増加し、キャッシュリゾルバーと権威あるDNSサーバーの負荷が増加し、CNNSの問題になる可能性のあるネットワーク負荷も増加します。TTLが長くなると、キャッシュのデータが古くなる可能性が高まります。TTLの最小値と最大値は、SRPレジストラのオペレーターが構成可能である必要があります。
Because the DNS-SD Service Registration Protocol is automatic and not managed by humans, some additional bookkeeping is required. When an update is constructed by the SRP requester, it MUST include an EDNS(0) Update Lease Option [RFC9664]. The Update Lease Option contains two lease times: the Lease Time and the KEY Lease Time.
DNS-SDサービス登録プロトコルは自動であり、人間によって管理されていないため、追加の簿記が必要です。SRPリクエスト担当者によって更新が作成された場合、EDNS（0）更新リースオプション[RFC9664]を含める必要があります。更新リースオプションには、リース時間とキーリース時間の2つのリース時間が含まれています。
Similar to DHCP leases [RFC2131], these leases are promises from the SRP requester that it will send a new update for the service registration before the lease time expires. The Lease time is chosen to represent the duration after the update during which the registered records other than the KEY record can be assumed to be valid. The KEY lease time represents the duration after the update during which the KEY record can be assumed to be valid. The reasoning behind the different lease times is discussed in Sections 3.2.4.1 and 3.2.5.3.
DHCPリース[RFC2131]と同様に、これらのリースは、リース時間が期限切れになる前にサービス登録の新しいアップデートを送信するというSRP要求者からの約束です。リース時間は、キーレコード以外の登録レコードが有効であると想定できる更新後の期間を表すために選択されます。キーリース時間は、更新後の期間を表し、その間にキーレコードが有効であると想定されると想定されます。さまざまなリース時間の背後にある理由については、セクション3.2.4.1および3.2.5.3で説明します。
SRP registrars may be configured with limits for these values. At the time of writing, a default limit of two hours for the Lease and 14 days for the SIG(0) KEY are thought to be good choices. Devices with limited battery that wake infrequently are likely to request longer leases; registrars that support such devices may need to set higher limits. SRP requesters that are going to continue to use names on which they hold leases SHOULD refresh them well before the lease ends in case the registrar is temporarily unavailable or under heavy load.
SRPレジストラは、これらの値の制限で構成される場合があります。執筆時点では、リースで2時間、SIG（0）キーの14日間のデフォルトの制限は、良い選択であると考えられています。まれに覚醒するバッテリーが限られているデバイスは、より長いリースを要求する可能性があります。そのようなデバイスをサポートするレジストラは、より高い制限を設定する必要がある場合があります。リースを保持している名前を引き続き使用しようとしているSRP要求者は、レジストラが一時的に利用できないか、重い負荷がかかっている場合にリースが終了する前にそれらを更新する必要があります。
The lease time applies specifically to the hostname. All service instances, and all service entries for such service instances, depend on the hostname. When the lease on a hostname expires, the hostname and all services that reference it MUST be removed at the same time: It is never valid for a service instance to remain when the hostname it references has been removed. If the KEY record for the hostname is to remain, the KEY record for any services that reference it MUST also remain. However, the Service Discovery PTR record MUST be removed since it has no key associated with it and since it is never valid to have a Service Discovery PTR record for which there is no service instance on the target of the PTR record.
リース時間は、ホスト名に特に適用されます。すべてのサービスインスタンス、およびそのようなサービスインスタンスのすべてのサービスエントリは、ホスト名によって異なります。ホスト名のリースが期限切れになると、ホスト名とそれを参照するすべてのサービスを同時に削除する必要があります。サービスインスタンスが削除されたときにサービスインスタンスが残ることは決して有効ではありません。ホスト名の重要なレコードが残る場合、それを参照するサービスのキーレコードも残る必要があります。ただし、Service Discovery PTRレコードは、それに関連するキーがなく、PTRレコードのターゲットにサービスインスタンスがないサービスディスカバリーPTRレコードを持つことは決して有効ではないため、削除する必要があります。
SRP registrars MUST also track a lease time per service instance. The reason being that a requester may re-register a hostname with a different set of services and not remember that some different service instance had previously been registered. In this case, when that service instance lease expires, the SRP registrar MUST remove the service instance, and any associated Service Discovery PTR records pointing to that service instance, (although the KEY record for the service instance SHOULD be retained until the KEY lease on that service expires). This is beneficial because it avoids stale services continuing to be advertised after the SRP requester has forgotten about them.
SRPレジストラは、サービスインスタンスごとのリース時間も追跡する必要があります。その理由は、リクエスターが異なるサービスセットでホスト名を再登録し、以前に異なるサービスインスタンスが登録されていたことを覚えていないためです。この場合、そのサービスインスタンスリースの有効期限が切れる場合、SRPレジストラはサービスインスタンスを削除する必要があり、そのサービスインスタンスを指す関連するサービスディスカバリーPTRレコードを削除する必要があります（ただし、サービスの主要なリースが期限切れになるまでサービスインスタンスの重要なレコードを保持する必要があります）。これは、SRP要求者がそれらを忘れた後も宣伝され続ける古いサービスを避けることを避けるため、有益です。
The SRP registrar MUST include an EDNS(0) Update Lease option in the response. The requester MUST check for the EDNS(0) Update Lease option in the response, and when deciding when to renew its registration the requester MUST use the lease times from the Update Lease option in the response in place of the lease times that it originally requested from the registrar. The times may be shorter or longer than those specified in the SRP Update. The SRP requester must honor them in either case.
SRPレジストラには、応答にEDNS（0）更新リースオプションを含める必要があります。要求者は、応答のEDNS（0）更新リースオプションを確認する必要があり、登録をいつ更新するかを決定する場合、リクエスタは、元々レジストラから要求されたリース時間の代わりに、更新リースオプションからリース時間を使用する必要があります。SRPアップデートで指定されている時代は、時間が短いか長い場合があります。SRP要求者は、どちらの場合もそれらを尊重する必要があります。
SRP requesters SHOULD assume that each lease ends N seconds after the update was first transmitted (where N is the granted lease duration). SRP registrars SHOULD assume that each lease ends N seconds after the update that was successfully processed was received. Because the registrar will always receive the update after the SRP requester sent it, this avoids the possibility of a race condition where the SRP registrar prematurely removes a service when the SRP requester thinks the lease has not yet expired. In addition, the SRP requester MUST begin attempting to renew its lease in advance of the expected expiration time, as required by the DNS Update Lease specification [RFC9664], to accommodate the situation where the clocks on the SRP requester and the SRP registrar do not run at precisely the same rate.
SRP要求者は、更新が最初に送信されてからn秒後に各リースが終了すると想定する必要があります（ここで、nは許可されたリース期間）。SRPレジストラは、正常に処理されたアップデートが受信されてからN秒後に各リースが終了すると想定する必要があります。SRP要求者が送信した後、レジストラは常にアップデートを受信するため、SRPリクエスト担当者がリースがまだ期限切れになっていないと考えると、SRPレジストラがサービスを早期に削除するレース条件の可能性が回避されます。さらに、SRPリクエスト担当者は、SRPリクエスト担当者とSRPレジストラのクロックが正確に同じ速度で実行されない状況に対応するために、DNSアップデートリース仕様[RFC9664]で要求される、予想される有効期限の前にリースを更新しようとする必要があります。
SRP registrars MUST reject updates that do not include an EDNS(0) Update Lease option. DNS authoritative servers that allow both SRP and non-SRP DNS updates MAY accept updates that don't include leases, but they SHOULD differentiate between SRP Updates and other updates and MUST reject updates that would otherwise be SRP Updates if they do not include leases.
SRPレジストラは、EDN（0）更新リースオプションを含まない更新を拒否する必要があります。SRPと非SRP DNSの両方の更新を許可するDNS権威あるサーバーは、リースを含まない更新を受け入れる場合がありますが、SRP更新と他の更新を区別する必要があり、リースが含まれない場合はSRP更新になる更新を拒否する必要があります。
The function of Lease times and the function of TTLs are completely different. On an authoritative DNS server, the TTL on a resource record is a constant. Whenever that RR is served in a DNS response, the TTL value sent in the answer is the same. The lease time is never sent as a TTL; its sole purpose is to determine when the authoritative DNS server will delete stale records. It is not an error to send a DNS response with a TTL of M when the remaining time on the lease is less than M.
リース時間の機能とTTLの機能は完全に異なります。権威あるDNSサーバーでは、リソースレコードのTTLは定数です。そのRRがDNS応答で提供されるたびに、回答で送信されたTTL値は同じです。リース時間はTTLとして送信されることはありません。その唯一の目的は、権威あるDNSサーバーが古くなったレコードをいつ削除するかを判断することです。リースの残りの時間がMより少ない場合、MのTTLでDNS応答を送信することはエラーではありません。
SRP Updates have no authorization semantics other than "First Come, First Served" (FCFS). Thus, if an attacker from outside the administrative domain of the SRP registrar knows the registrar's IP address, it can, in principle, send updates to the registrar that will be processed successfully. Therefore, SRP registrars SHOULD be configured to reject updates from source addresses outside of the administrative domain of the registrar.
SRPアップデートには、「First Come、First Sever」（FCFS）以外の承認セマンティクスはありません。したがって、SRPレジストラの管理ドメインの外側からの攻撃者がレジストラのIPアドレスを知っている場合、原則として、正常に処理されるレジストラに更新を送信できます。したがって、SRPレジストラは、レジストラの管理ドメイン以外のソースアドレスから更新を拒否するように構成する必要があります。
For TCP updates, the initial SYN-SYN+ACK handshake prevents updates being forged by an off-path attacker. In order to ensure that this handshake happens, SRP registrars relying on three-way-handshake validation MUST NOT accept TCP Fast Open payloads [RFC7413]. If the network infrastructure allows it, an SRP registrar MAY accept TCP Fast Open payloads if all such packets are validated along the path, and the network is able to reject this type of spoofing at all ingress points.
TCPの更新では、最初のSyn-Syn+ACKハンドシェイクにより、パスオフパスの攻撃者が更新が築かれるのを防ぎます。このハンドシェイクが発生するようにするために、SRPレジストラは3方向ハンドシェイク検証に依存しています。TCP高速オープンペイロード[RFC7413]を受け入れてはなりません。ネットワークインフラストラクチャが許可している場合、SRPレジストラは、そのようなパケットがすべてパスに沿って検証されている場合、TCP高速オープンペイロードを受け入れ、ネットワークはすべてのイングレスポイントでこのタイプのスプーフィングを拒否することができます。
For UDP updates from CNN devices, spoofing would have to be prevented with appropriate source address filtering on routers [RFC2827]. This would ordinarily be accomplished by measures such as those described in Section 4.5 of the IPv6 CE Router Requirements document [RFC7084]. For example, a stub router [SNAC-SIMPLE] for a CNN might only accept UDP updates from source addresses known to be on-link on that stub network and might further validate that the UDP update was actually received on the stub network interface and not the interface connected to the adjacent infrastructure link.
CNNデバイスからのUDP更新の場合、ルーターの適切なソースアドレスフィルタリングでスプーフィングを防ぐ必要があります[RFC2827]。これは通常、IPv6 CEルーター要件文書[RFC7084]のセクション4.5に記載されているような測定によって達成されます。たとえば、CNN用のスタブルーター[SNAC-Simple]は、そのスタブネットワーク上のリンクであることが知られているソースアドレスからのUDP更新のみを受け入れる可能性があり、UDPアップデートが実際にスタブネットワークインターフェイスで受信され、隣接するインフラストラクチャリンクに接続されたインターフェイスではなく、さらに検証される可能性があります。
Note that these rules only apply to the validation of SRP Updates. An authoritative DNS server that accepts updates from SRP requesters may also accept other DNS Update messages, and those DNS Update messages may be validated using different rules. However, in the case of an authoritative DNS server that accepts SRP updates, the intersection of the SRP Update rules and whatever other update rules are present must be considered very carefully.
これらのルールは、SRP更新の検証にのみ適用されることに注意してください。SRP要求者からの更新を受け入れる権威あるDNSサーバーも、他のDNS更新メッセージを受け入れる場合があり、これらのDNS更新メッセージは異なるルールを使用して検証される場合があります。ただし、SRP更新を受け入れる権威あるDNSサーバーの場合、SRP更新ルールの交差点と他の更新ルールの交差点は、非常に慎重に考慮する必要があります。
For example, a normal authenticated DNS update to any RR that was added using SRP, but is authenticated using a different key, could be used to override a promise made by the SRP registrar to an SRP requester by replacing all or part of the service registration information with information provided by an authenticated DNS update requester. An implementation that allows both kinds of updates SHOULD NOT allow DNS Update requesters that are using different authentication and authorization credentials to update records added by SRP requesters.
たとえば、SRPを使用して追加されたが別のキーを使用して認証された任意のRRに通常の認証されたDNSアップデートを使用して、SRPレジストラによるSRPリクエスト担当者に行われた約束をオーバーライドすることができます。両方の種類の更新を可能にする実装では、異なる認証と認証資格情報を使用しているDNS更新リクエスターを許可して、SRPリクエスト担当者が追加したレコードを更新することができません。
It is possible to set up SRP Updates for a zone that is also used for non-DNS-SD records. For example, imagine that you set up SRP service for "example.com". SRP requesters can now register names like "www" or "mail" or "smtp" in this domain. In addition, SRP Updates using FCFS Naming can insert names that are obscene or offensive into the zone. There is no simple solution to these problems. However, we have two recommendations to address this problem:
非DNS-SDレコードにも使用されるゾーンのSRP更新をセットアップすることができます。たとえば、「embles.com」のSRPサービスをセットアップすることを想像してください。SRP要求者は、このドメインで「www」、「mail」、「smtp」などの名前を登録できるようになりました。さらに、FCFSネーミングを使用したSRP更新では、わいせつまたは攻撃的な名前をゾーンに挿入できます。これらの問題に対する簡単な解決策はありません。ただし、この問題に対処するための2つの推奨事項があります。
* Do not provide SRP service in organization-level zones. Use subdomains of the organizational domain for DNS-SD. This does not prevent registering names as mentioned above but does ensure that genuinely important names are not accidentally claimed by SRP requesters. So, for example, the zone "dnssd.example.com." could be used instead of "example.com." for SRP Updates. Because of the way that DNS-browsing domains are discovered, there is no need for the DNS-SD discovery zone that is updated by SRP to have a user-friendly or important-sounding name.
* 組織レベルのゾーンでSRPサービスを提供しないでください。DNS-SDの組織ドメインのサブドメインを使用します。これは、上記のように名前の登録を妨げるものではありませんが、真に重要な名前がSRP要求者によって誤って請求されないことを保証します。したがって、たとえば、ゾーン「dnssd.example.com」。「Example.com」の代わりに使用できます。SRP更新用。DNS-Browsingドメインが発見される方法により、SRPによって更新されるDNS-SDディスカバリーゾーンは、ユーザーフレンドリーまたは重要なサウンドの名前を持つ必要はありません。
* Configure a dictionary of names that are prohibited. Dictionaries of common obscene and offensive names are no doubt available and can be augmented with a list of typical "special" names like "www", "mail", "smtp", and so on. Lists of names are generally available or can be constructed manually. Names rejected due to this should return a Refused RCODE, indicating to the SRP requester that it should not append or increment a number at the end of the name and then try again, since this would likely result in an infinite loop. If a name is considered unacceptable because it is obscene or offensive, adding a number on the end is unlikely to make the name acceptable.
* 禁止されている名前の辞書を構成します。一般的なわいせつや攻撃的な名前の辞書は間違いなく利用可能であり、「www」、「mail」、「smtp」などの典型的な「特別な」名前のリストで拡張できます。名前のリストは一般的に利用可能であるか、手動で構築できます。これにより拒否された名前は、拒否されたrcodeを返す必要があります。これは、名前の最後に数値を追加または増分してはならないことをSRPリクエスト担当者に示し、それが無限のループになる可能性が高いため、再試行することを示します。名前がわいせつであるか攻撃的であるため容認できないと見なされる場合、最後に数字を追加することは、名前を受け入れる可能性は低いです。
Local links can be protected by managed services such as RA Guard [RFC6105], but multicast services like DHCP [RFC2131], DHCPv6 [RFC8415], and IPv6 Neighbor Discovery [RFC4861] are, in most cases, not authenticated and can't be controlled on unmanaged networks, such as home networks and small office networks where no network management staff are present. In such situations, the SRP service has comparatively fewer potential security exposures and, hence, is not the weak link. This is discussed in more detail in Section 3.2.4.
ローカルリンクは、RA Guard [RFC6105]などのマネージドサービスによって保護できますが、DHCP [RFC2131]、DHCPV6 [RFC8415]、IPv6 Neighbor Discovery [RFC4861]などのマルチキャストサービスは、ほとんどの場合、ネットワークのネットワークなどのネットワークのネットワークなどのネットワークを管理することはできません。このような状況では、SRPサービスは潜在的なセキュリティエクスポージャーが比較的少ないため、弱いリンクではありません。これについては、セクション3.2.4で詳しく説明します。
The fundamental protection for networks of this type is the user's choice of what devices to add to the network. Work is being done in other working groups and standards bodies to improve the state of the art for network on-boarding and device isolation (e.g., Manufacturer Usage Descriptions [RFC8520] provide a means for constraining what behaviors are allowed for a device in an automatic way), but such work is out of scope for this document.
このタイプのネットワークの基本的な保護は、ネットワークに追加するデバイスをユーザーが選択することです。他のワーキンググループおよび標準団体で作業が行われています。ネットワークのオンボーディングおよびデバイス分離（メーカーの使用の説明[RFC8520]のアートを改善します。
This specification does not provide a mechanism for validating responses from SRP registrars to SRP requesters. In principle, a KEY RR could be used by a non-CNN SRP requester to validate responses from the registrar, but this is not required, nor do we specify a mechanism for determining which key to use.
この仕様では、SRPレジストラからSRPリクエスト担当者への応答を検証するメカニズムは提供されません。原則として、主要なRRを非CNN SRPリクエスト担当者がレジストラからの応答を検証するために使用できますが、これは必須ではなく、使用するキーを決定するメカニズムを指定しません。
In addition, for DNS-over-TLS connections, out-of-band key pinning as described in Section 4.2 of the DNS-over-TLS specification [RFC7858] could be used for authentication of the SRP registrar, e.g., to prevent man-in-the-middle attacks. However, the use of such keys is impractical for an unmanaged service registration protocol; hence, it is out of scope for this document.
さらに、DNS-over-TLS接続の場合、DNS-over-TLS仕様[RFC7858]のセクション4.2で説明されているように、帯域外のキーピン留めを使用して、SRPレジストラの認証、たとえば中間の攻撃を防ぐことができます。ただし、そのようなキーの使用は、管理されていないサービス登録プロトコルでは非現実的です。したがって、このドキュメントの範囲外です。
For validation, SRP registrars MUST implement the ECDSAP256SHA256 signature algorithm. SRP registrars SHOULD implement the algorithms that are listed in Section 3.1 of the DNSSEC Cryptographic Algorithms specification [RFC8624], in the validation column of the table, that are numbered 13 or higher and that have a "MUST", "RECOMMENDED", or "MAY" designation in the validation column of the table. SRP requesters MUST NOT assume that any algorithm numbered lower than 13 is available for use in validating SIG(0) signatures.
検証のために、SRPレジストラはECDSAP256SHA256署名アルゴリズムを実装する必要があります。SRPレジストラは、テーブルの検証列に番号が付けられ、「推奨」、「推奨」、または「5月」の検証列に「マスト」、「推奨」、または「5月」を持っているテーブルの検証列に、DNSSEC暗号化アルゴリズム仕様[RFC8624]にリストされているアルゴリズムを実装する必要があります。SRP要求者は、13未満のアルゴリズムがSIG（0）署名の検証に使用できると仮定してはなりません。
Because DNS-SD SRP Updates can be sent off-link, the privacy implications of SRP are different from those for mDNS responses. SRP Requester implementations that are using TCP SHOULD also use DNS-over-TLS [RFC7858] if available. SRP registrar implementations MUST offer TLS support. Because there is no mechanism for sharing keys, validation of DNS-over-TLS keys is not possible; DNS-over-TLS is used only for Opportunistic Privacy, as documented in Section 4.1 of the DNS-over-TLS specification [RFC7858].
DNS-SD SRPの更新はリンクをオフに送信できるため、SRPのプライバシーへの影響はMDNS応答の影響とは異なります。TCPを使用しているSRP要求者の実装は、利用可能な場合はDNS-Over-TLS [RFC7858]も使用する必要があります。SRPレジストラの実装は、TLSサポートを提供する必要があります。キーを共有するメカニズムがないため、DNS-over-TLSキーの検証は不可能です。DNS-TLSは、DNS-Over-TLS仕様[RFC7858]のセクション4.1に記載されているように、日和見的プライバシーにのみ使用されます。
SRP requesters that are able to use TLS SHOULD NOT fall back to TCP. Since all SRP registrars are required to support TLS, whether to use TLS is entirely the decision of the SRP requester.
TLSを使用できるSRP要求者は、TCPに戻ってはいけません。すべてのSRPレジストラはTLSをサポートする必要があるため、TLSを使用するかどうかは完全にSRP要求者の決定です。
Public keys can be used as identifiers to track hosts. SRP registrars MAY elect not to return KEY records for queries for SRP registrations. To avoid DNSSEC validation failures, an SRP registrar that signs the zone for DNSSEC but refuses to return a KEY record MUST NOT store the KEY record in the zone itself. Because the KEY record isn't in the zone, the nonexistence of the KEY record can be validated. If the zone is not signed, the authoritative DNS server MAY instead return a negative response (either NXDOMAIN or no data).
パブリックキーは、ホストを追跡する識別子として使用できます。SRPレジストラは、SRP登録のクエリのキーレコードを返しないことを選択する場合があります。DNSSEC検証障害を回避するために、DNSSECのゾーンに署名するが、キーレコードを返すことを拒否するSRPレジストラは、ゾーン自体にキーレコードを保存してはなりません。キーレコードはゾーンにないため、キーレコードの存在のないことを検証できます。ゾーンに署名されていない場合、権威あるDNSサーバーは代わりに否定的な応答を返すことができます（nxDomainまたはデータなし）。
This section specifies considerations for systems involved in domain name resolution when resolving queries for names ending with ".service.arpa.". Each item in this section addresses some aspect of the DNS or the process of resolving domain names that would be affected by this special-use allocation. Detailed explanations of these items can be found in Section 5 of the Special-Use Domain Names specification [RFC6761].
このセクションでは、「.service.arpa」で終わる名前のクエリを解決する際に、ドメイン名の解像度に関与するシステムの考慮事項を指定します。このセクションの各項目は、DNSのいくつかの側面またはこの特別な使用割り当ての影響を受けるドメイン名を解決するプロセスについて説明します。これらの項目の詳細な説明は、特別使用ドメイン名の仕様[RFC6761]のセクション5に記載されています。
The current proposed use for "service.arpa." does not require special knowledge on the part of the user. While the "default.service.arpa." subdomain is used as a generic name for registration, users are not expected to see this name in user interfaces. In the event that it does show up in a user interface, it is just a domain name and requires no special treatment by the user.
「service.arpa」の現在の提案されている使用。ユーザー側の特別な知識は必要ありません。「default.service.arpa」サブドメインは登録の汎用名として使用され、ユーザーはユーザーインターフェイスにこの名前を表示することは期待されていません。ユーザーインターフェイスに表示された場合、それは単なるドメイン名であり、ユーザーによる特別な扱いを必要としません。
Application software does not need to handle subdomains of "service.arpa." specially. "service.arpa." SHOULD NOT be treated as more trustworthy than any other insecure DNS domain, simply because it is locally served (or for any other reason). It is not possible to register a PKI certificate for a subdomain of "service.arpa." because it is a locally served domain name. So, no such subdomain can be considered to be uniquely identifying a particular host, as would be required for such a PKI certificate to be issued. If a subdomain of "service.arpa." is returned by an API or entered in an input field of an application, PKI authentication of the endpoint being identified by the name will not be possible. Alternative methods and practices for authenticating such endpoints are out of scope for this document.
アプリケーションソフトウェアは、「service.arpa」のサブドメインを処理する必要はありません。特に。「service.arpa。」地元で（または他の理由で）提供されているという理由だけで、他の不安定なDNSドメインよりも信頼できるものとして扱われるべきではありません。「service.arpa」のサブドメインについてPKI証明書を登録することはできません。地元で提供されるドメイン名だからです。したがって、そのようなPKI証明書を発行するために必要とされるように、そのようなサブドメインは特定のホストを一意に識別すると見なすことはできません。「service.arpa」のサブドメインの場合。APIによって返されるか、アプリケーションの入力フィールドに入力され、名前で識別されるエンドポイントのPKI認証は不可能です。このようなエンドポイントを認証するための代替方法と実践は、このドキュメントの範囲外です。
Name resolution APIs and libraries MUST NOT recognize names that end in "service.arpa." as special and MUST NOT treat them as having special significance, except that it may be necessary that such APIs not bypass the locally discovered recursive resolvers.
名前解像度APIとライブラリは、「service.arpa」で終わる名前を認識してはなりません。特別であり、それらを特別な重要性を持っていると扱ってはなりません。ただし、このようなAPIがローカルで発見された再帰リゾルバーをバイパスしないことが必要になる場合があります。
One or more IP addresses for recursive resolvers will usually be supplied to the SRP requester through router advertisements or DHCP. For an administrative domain that uses subdomains of "service.arpa.", the recursive resolvers provided by that domain will be able to answer queries for subdomains of "service.arpa.". Other (non-local) resolvers will not, or they will provide answers that are not correct within that administrative domain.
通常、再帰的なリゾルバーの1つ以上のIPアドレスは、ルーター広告またはDHCPを介してSRPリクエスト担当者に提供されます。「service.arpa」のサブドメインを使用する管理ドメインの場合、そのドメインが提供する再帰リゾルバーは、「service.arpa」のサブドメインのクエリに答えることができます。他の（非ローカル）リゾルバーはそうではありません。または、その管理ドメイン内で正しくない回答を提供します。
A host that is configured to use a resolver other than one that has been provided by the local network may not be able to resolve or may receive incorrect results for subdomains of "service.arpa.". In order to avoid this, hosts SHOULD use the resolvers that are locally provided for resolving "service.arpa." names, even when they are configured to use other resolvers for other names.
ローカルネットワークによって提供されたもの以外のリゾルバーを使用するように構成されているホストは、「service.arpa」のサブドメインの解決できないか、誤った結果を受け取る可能性があります。これを回避するために、ホストは「service.arpa」を解決するためにローカルに提供されているリゾルバーを使用する必要があります。名前、他の名前に他のリゾルバーを使用するように構成されている場合でも。
There are two considerations for recursive resolvers (also known as "caching DNS servers" or "recursive DNS servers") that follow this specification:
この仕様に従うには、再帰的なリゾルバー（「キャッシュDNSサーバー」または「再帰DNSサーバー」とも呼ばれる）には2つの考慮事項があります。
1. For correctness, recursive resolvers at sites using 'service.arpa.' must, in practice, transparently support DNSSEC queries: queries for DNSSEC records and queries with the DNSSEC OK (DO) bit set (Section 3.2.1 of the DNSSEC specification [RFC4035]). DNSSEC validation [RFC9364] is a best current practice: Although validation is not required, a caching recursive resolver that does not validate answers that can be validated may cache invalid data. In turn, this would prevent validating stub resolvers from successfully validating answers. Hence, as a practical matter, recursive resolvers at sites using "service.arpa." should do DNSSEC validation.
1. 正しさのために、「service.arpa」を使用してサイトで再帰的なリゾルバー。実際には、DNSSECクエリ：DNSSECレコードのクエリとDNSSEC OK（do）ビットセット（DNSSEC仕様[RFC4035]のセクション3.2.1）のクエリを透過的にサポートする必要があります。DNSSEC検証[RFC9364]は最良の現在のプラクティスです。検証は必要ありませんが、検証できる回答を検証しないキャッシュ再帰リゾルバーは、無効なデータをキャッシュする場合があります。次に、これにより、スタブリゾルバーの検証が回答を正常に検証することができなくなります。したがって、実際的な問題として、「service.arpa」を使用したサイトで再帰的なリゾルバー。DNSSEC検証を行う必要があります。
2. Unless configured otherwise, recursive resolvers and DNS proxies MUST behave following the rules prescribed for Iterative Resolvers in Section 3 of the IETF Locally Served DNS Zones document [RFC6303]. That is, queries for "service.arpa." and subdomains of "service.arpa." MUST NOT be forwarded, with one important exception: a query for a DS record with the DO bit set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent.
2. 特に構成されていない限り、再帰的なリゾルバーとDNSプロキシは、DNSゾーンドキュメント[RFC6303]にローカルに提供されるIETFのセクション3の反復リゾルバーに規定されているルールに従って動作する必要があります。つまり、「service.arpa」のクエリ。および「service.arpa」のサブドメイン。1つの重要な例外を除いて、転送してはなりません。DOビットセットを使用したDSレコードのクエリは、レコードが存在しないことを証明する権限セクションの正しい情報を含め、その質問の正しい答えを返す必要があります。
So, for example, a query for the NS record for "service.arpa." MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for ".arpa.". However, to provide accurate authority information, a query for the DS record MUST result in forwarding whatever queries are necessary. Typically, this will just be a query for the DS record since the necessary authority information will be included in the authority section of the response if the DO bit is set.
したがって、たとえば、「service.arpa」のNSレコードのクエリ。そのクエリが上流のキャッシュに転送されたり、「.ARPA」の権威あるDNSサーバーに転送されたりしないでください。ただし、正確な権限情報を提供するには、DSレコードのクエリは、必要なクエリを転送する必要があります。通常、これは、DOビットが設定されている場合、必要な権限情報が応答の権限セクションに含まれるため、DSレコードのクエリにすぎません。
No special processing of "service.arpa." is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative DNS servers for "service.arpa." for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance, there will be no such delegation in the "service.arpa." zone; therefore, the authoritative DNS server would refuse to answer authoritatively for such a zone. An authoritative DNS server that implements this sort of check MUST be configurable so that either it does not do this check for the "service.arpa." domain or it ignores the results of the check.
「service.arpa」の特別な処理はありません。権威あるDNSサーバーの実装には必要です。権威あるDNSサーバーが、「service.arpa」の権威あるDNSサーバーを確認しようとする可能性があります。そのような委任された名前のために権威ある回答に答える前に、その名前の下の代表団の場合。そのような場合、名前は常に局所的な重要性しかないため、「service.arpa」にはそのような委任はありません。ゾーン;したがって、権威あるDNSサーバーは、そのようなゾーンのために権威ある回答を拒否します。この種のチェックを実装する権威あるDNSサーバーは、「service.arpa」に対してこのチェックを行わないように構成可能でなければなりません。ドメインまたはそれは、チェックの結果を無視します。
DNS server operators MAY configure an authoritative DNS server for "service.arpa." for use with SRP. The operator for the DNS servers that are authoritative for "service.arpa." in the global DNS will configure any such DNS servers as described in Section 9.
DNSサーバーオペレーターは、「service.arpa」用の権威あるDNSサーバーを構成できます。SRPで使用します。「service.arpa」の権威あるDNSサーバーのオペレーター。グローバルDNSでは、セクション9で説明されているようなDNSサーバーを構成します。
"service.arpa." is a subdomain of the "arpa." top-level domain, which is operated by IANA under the authority of the Internet Architecture Board (IAB) [RFC3172]. There are no other DNS registrars for "arpa.".
「service.arpa。」「ARPA」のサブドメインです。インターネットアーキテクチャボード（IAB）[RFC3172]の権限の下でIANAによって運営されているトップレベルのドメイン。「ARPA」の他のDNSレジストラはありません。
The owner of the "arpa." zone, at the time of writing the IAB [IAB-ARPA], has added a delegation of "service.arpa." in the "arpa." zone [RFC3172], following the guidance provided in Section 7 of the "home.arpa." specification [RFC8375].
「ARPA」の所有者。ゾーンは、IAB [IAB-ARPA]の執筆時点で、「service.arpa」の代表団を追加しました。「ARPA」で。ゾーン[RFC3172]、「home.arpa」のセクション7で提供されているガイダンスに従います。仕様[RFC8375]。
IANA has recorded the domain name "service.arpa." in the "Special-Use Domain Names" registry [SUDN]. IANA has implemented the delegation requested in Section 9.
IANAはドメイン名「Service.Arpa」を記録しました。「特別使用ドメイン名」レジストリ[Sudn]。IANAは、セクション9で要求された代表団を実装しました。
IANA has also added a new entry to the "Transport-Independent Locally-Served Zones Registry" registry of the "Locally-Served DNS Zones" group [LSDZ]. The entry is for the domain "SERVICE.ARPA." with the description "DNS-SD Service Registration Protocol Special-Use Domain" and lists this document as the reference.
IANAはまた、「ローカルにサービスされたDNSゾーン」グループ[LSDZ]の「トランスポートに依存しないローカルにサービスされたゾーンレジストリ」レジストリに新しいエントリを追加しました。エントリはドメイン「service.arpa」用です。説明「DNS-SDサービス登録プロトコル特別使用ドメイン」と、このドキュメントを参照としてリストします。
This document only makes use of the "default.service.arpa." subdomain of "service.arpa." Other subdomains are reserved for future use by DNS-SD or related work. IANA has created the "service.arpa. Subdomain" registry [SUB]. The IETF has change control for this registry. New entries may be added either as a result of Standards Action (Section 4.9 of the IANA Guidelines) or with IESG Approval (Section 4.10 of the IANA Guidelines) [RFC8126], provided that the values and their meanings are documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible.
このドキュメントでは、「default.service.arpa」のみを使用しています。「service.arpa」のサブドメイン。他のサブドメインは、DNS-SDまたは関連する作業による将来の使用のために予約されています。IANAは「service.arpa。subdomain」レジストリ[sub]を作成しました。IETFには、このレジストリの変更制御があります。標準訴訟（IANAガイドラインのセクション4.9）またはIESGの承認（IANAガイドラインのセクション4.10）[RFC8126]の結果として、新しいエントリを追加できます。
IANA has grouped the "service.arpa. Subdomain" registry with the "Locally-Served DNS Zones" group. The registry is a table with three columns: the subdomain name (expressed as a fully qualified domain name), a brief description of how it is used, and a reference to the document that describes its use in detail.
IANAは、「service.arpa。subdomain」レジストリを「ローカルにサービスするDNSゾーン」グループとグループ化しました。レジストリは、サブドメイン名（完全に適格なドメイン名として表される）、使用方法の簡単な説明、およびその使用を詳細に説明するドキュメントへの参照の3つの列を持つテーブルです。
This initial contents of this registry are as follows:
このレジストリのこの最初の内容は次のとおりです。
+=======================+=================+===========+
| Subdomain Name | Description | Reference |
+=======================+=================+===========+
| default.service.arpa. | Default domain | RFC 9665 |
| | for SRP Updates | |
+-----------------------+-----------------+-----------+
Table 1
IANA has added two new entries to the "Service Name and Transport Protocol Port Number Registry" [PORT]. The following subsections contain tables with the fields required by Section 8.1.1 of IANA's Procedures for Service Name allocation [RFC6335].
IANAは、「サービス名と輸送プロトコルポート番号レジストリ」[ポート]に2つの新しいエントリを追加しました。次のサブセクションには、IANAのサービス名割り当て手順[RFC6335]のセクション8.1.1で必要なフィールドの表が含まれています。
+====================+=============================+
| Field Name | Value |
+====================+=============================+
| Service Name | dnssd-srp |
+--------------------+-----------------------------+
| Transport Protocol | tcp |
+--------------------+-----------------------------+
| Assignee | IESG <iesg@ietf.org> |
+--------------------+-----------------------------+
| Contact | IETF Chair <chair@ietf.org> |
+--------------------+-----------------------------+
| Description | DNS-SD Service Discovery |
+--------------------+-----------------------------+
| Reference | RFC 9665 |
+--------------------+-----------------------------+
| Port Number | None |
+--------------------+-----------------------------+
| Service Code | None |
+--------------------+-----------------------------+
Table 2
+====================+================================+
| Field Name | Value |
+====================+================================+
| Service Name | dnssd-srp-tls |
+--------------------+--------------------------------+
| Transport Protocol | tcp |
+--------------------+--------------------------------+
| Assignee | IESG <iesg@ietf.org> |
+--------------------+--------------------------------+
| Contact | IETF Chair <chair@ietf.org> |
+--------------------+--------------------------------+
| Description | DNS-SD Service Discovery (TLS) |
+--------------------+--------------------------------+
| Reference | RFC 9665 |
+--------------------+--------------------------------+
| Port Number | None |
+--------------------+--------------------------------+
| Service Code | None |
+--------------------+--------------------------------+
Table 3
IANA has allocated an IPv6 anycast address from the "IANA IPv6 Special-Purpose Address Registry" [IPv6], similar to the Port Control Protocol [RFC6887] anycast address [RFC7723]. The purpose of this allocation is to provide a fixed anycast address that can be commonly used as a destination for SRP Updates when no SRP registrar is explicitly configured. The initial values for the registry are as follows:
IANAは、ポートコントロールプロトコル[RFC6887]と同様の「IANA IPv6 Special-Purposeアドレスレジストリ」[IPv6] [IPv6] [IPv6]からIPv6 Anycastアドレスを割り当てました[RFC7723]。この割り当ての目的は、SRPレジストラが明示的に構成されていない場合、SRP更新の宛先として一般的に使用できる固定されたAnycastアドレスを提供することです。レジストリの初期値は次のとおりです。
+======================+=============================+
| Attribute | Value |
+======================+=============================+
| Address Block | 2001:1::3/128 |
+----------------------+-----------------------------+
| Name | DNS-SD Service Registration |
| | Protocol Anycast Address |
+----------------------+-----------------------------+
| RFC | RFC 9665 |
+----------------------+-----------------------------+
| Allocation Date | 2024-04 |
+----------------------+-----------------------------+
| Termination Date | N/A |
+----------------------+-----------------------------+
| Source | True |
+----------------------+-----------------------------+
| Destination | True |
+----------------------+-----------------------------+
| Forwardable | True |
+----------------------+-----------------------------+
| Globally Reachable | True |
+----------------------+-----------------------------+
| Reserved-by-Protocol | False |
+----------------------+-----------------------------+
Table 4
[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>.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
<https://www.rfc-editor.org/info/rfc1536>.
[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>.
[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>.
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, DOI 10.17487/RFC2539,
March 1999, <https://www.rfc-editor.org/info/rfc2539>.
[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>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/info/rfc6303>.
[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>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>.
[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
Requirements and Usage Guidance for DNSSEC", RFC 8624,
DOI 10.17487/RFC8624, June 2019,
<https://www.rfc-editor.org/info/rfc8624>.
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/info/rfc8765>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[RFC9664] Cheshire, S. and T. Lemon, "An EDNS(0) Option to Negotiate
Leases on DNS Updates", RFC 9664, DOI 10.17487/RFC9664,
June 2025, <https://www.rfc-editor.org/info/rfc9664>.
[IAB-ARPA] "Internet Architecture Board statement on the registration
of special use names in the ARPA domain", March 2017,
<https://www.iab.org/documents/correspondence-reports-
documents/2017-2/iab-statement-on-the-registration-of-
special-use-names-in-the-arpa-domain/>.
[IPv6] IANA, "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special-
registry>.
[LSDZ] IANA, "Locally-Served DNS Zones",
<https://www.iana.org/assignments/locally-served-dns-
zones>.
[PORT] IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service-
names-port-numbers>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[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>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)",
RFC 6760, DOI 10.17487/RFC6760, February 2013,
<https://www.rfc-editor.org/info/rfc6760>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[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>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[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>.
[RFC7723] Kiesel, S. and R. Penno, "Port Control Protocol (PCP)
Anycast Addresses", RFC 7723, DOI 10.17487/RFC7723,
January 2016, <https://www.rfc-editor.org/info/rfc7723>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[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>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[ROADMAP] Cheshire, S., "Service Discovery Road Map", Work in
Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,
23 October 2018, <https://datatracker.ietf.org/doc/html/
draft-cheshire-dnssd-roadmap-03>.
[SNAC-SIMPLE]
Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-06, 4 November
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
snac-simple-06>.
[SUB] IANA, "service.arpa Subdomain",
<https://www.iana.org/assignments/locally-served-dns-
zones/locally-served-dns-zones>.
[SUDN] IANA, "Special-Use Domain Names",
<https://www.iana.org/assignments/special-use-domain-
names>.
[ZC] Steinberg, D.H. and S. Cheshire, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc.,
ISBN 9780596101008, December 2005.
For testing, it may be useful to set up an authoritative DNS server that does not implement SRP. This can be done by configuring the authoritative DNS server to listen on the anycast address or by advertising it in the "_dnssd-srp._tcp.<zone>" and "_dnssd-srp-tls._tcp.<zone>" SRV records. It must be configured to be authoritative for "default.service.arpa." and to accept updates from hosts on local networks for names under "default.service.arpa." without authentication since such authoritative DNS servers will not have support for FCFS authentication (Section 3.2.4.1).
テストの場合、SRPを実装していない権威あるDNSサーバーをセットアップすると便利かもしれません。これは、権威あるDNSサーバーをAnycastアドレスでリッスンするように構成するか、「_DNSSD-SRP._TCP。<ZONE>」および「_DNSSD-SRP-TLS._TCP。「default.service.arpa」の権威あるように構成する必要があります。また、「default.service.arpa」に基づく名前のローカルネットワーク上のホストからの更新を受け入れる。そのような権威あるDNSサーバーはFCFS認証をサポートしないため、認証がなければ（セクション3.2.4.1）。
An authoritative DNS server configured in this way will be able to successfully accept and process SRP Updates from requesters that send SRP updates. However, no prerequisites will be applied; this means that the test authoritative DNS server will accept internally inconsistent SRP Updates and will not stop two SRP Updates sent by different services that claim the same name or names from overwriting each other.
この方法で構成された権威あるDNSサーバーは、SRPアップデートを送信するリクエスターからSRP更新を正常に受け入れて処理できます。ただし、前提条件は適用されません。これは、テスト権限のあるDNSサーバーが内部的に一貫性のないSRP更新を受け入れ、同じ名前または名前を互いに上書きすることを主張する異なるサービスから送信される2つのSRP更新を停止しないことを意味します。
Since SRP Updates are signed with keys, validation of the SIG(0) algorithm used by the requester can be done by manually installing the requester's public key on the authoritative DNS server that will be receiving the updates. The key can then be used to authenticate the SRP Update and can be used as a requirement for the update. An example configuration for testing SRP using BIND 9 is given in Appendix C.
SRP更新はキーで署名されているため、要求者が使用するSIG（0）アルゴリズムの検証は、更新を受信する権威あるDNSサーバーにリクエスターの公開キーを手動でインストールすることで実行できます。キーを使用してSRPアップデートを認証し、更新の要件として使用できます。Bind 9を使用してSRPをテストするための例の構成は、付録Cに示されています。
Ordinarily, CNN SRP Updates sent to an authoritative DNS server that implements standard DNS Update [RFC2136] but not SRP will fail because the zone being updated is "default.service.arpa." and because no authoritative DNS server that is not an SRP registrar would normally be configured to be authoritative for "default.service.arpa.". Therefore, a requester that sends an SRP Update can tell that the receiving authoritative DNS server does not support SRP but does support standard DNS Update [RFC2136] because the RCODE will either be NotZone, NotAuth, or Refused or because there is no response to the update request (when using the anycast address).
通常、CNN SRP更新は、標準のDNSアップデート[RFC2136]を実施する権威あるDNSサーバーに送信されますが、更新されるゾーンが「default.service.arpa」であるため、SRPは失敗しません。また、SRPレジストラではない権威あるDNSサーバーは、通常、「default.service.arpa」の権威あるように構成されていないためです。したがって、SRPアップデートを送信する要求者は、受信権のあるDNSサーバーがSRPをサポートしていないが、標準のDNSアップデート[RFC2136]をサポートしていることがわかります[RFC2136]。
In this case, a requester MAY attempt to register itself using normal DNS updates [RFC2136]. To do so, it must discover the default registration zone and the authoritative DNS server designated to receive updates for that zone, as described earlier, using the _dns-update._udp SRV record. It can then send the update to the port and host pointed to by the SRV record, and it is expected to use appropriate prerequisites to avoid overwriting competing records. Such updates are out of scope for SRP, and a requester that implements SRP MUST first attempt to use SRP to register itself and only attempt to use backwards capability with normal DNS Update [RFC2136] if that fails. Although the owner name of the SRV record for DNS Update (_dns-update._udp) specifies UDP, it is also possible to use TCP, and TCP SHOULD be required to prevent spoofing.
この場合、要求者は通常のDNS更新[RFC2136]を使用して自分自身を登録しようとする場合があります。そのためには、_DNS-update._udp SRVレコードを使用して、前述のように、そのゾーンの更新を受信するように指定されたデフォルトの登録ゾーンと権威あるDNSサーバーを発見する必要があります。その後、SRVレコードでポートとポートを指すホストに更新を送信でき、競合する記録を上書きすることを避けるために適切な前提条件を使用することが期待されています。このような更新はSRPの範囲外であり、SRPを実装する要求者は、最初にSRPを使用してそれ自体を登録し、それが失敗した場合に通常のDNSアップデート[RFC2136]で逆方向の機能を使用しようと試みなければなりません。DNSアップデートのSRVレコードの所有者名（_DNS-update._udp）はUDPを指定していますが、TCPを使用することも可能です。また、スプーフィングを防ぐためにTCPを必要とする必要があります。
zone "default.service.arpa." {
type primary;
file "/etc/bind/primary/service.db";
allow-update { key demo.default.service.arpa.; };
};
Figure 1: Zone Configuration in named.conf
図1：named.confのゾーン構成
$TTL 57600 ; 16 hours
@ IN SOA ns postmaster (
2951053287 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
NS ns
ns AAAA 2001:db8:0:2::1
$TTL 3600 ; 1 hour
; Autoconguration bootstrap records
_dnssd-srp._tcp SRV 0 0 53 ns
_dnssd-srp-tls._tcp SRV 0 0 853 ns
; Service Discovery Instruction
_ipps._tcp PTR demo._ipps._tcp
; Service Description Instruction
demo._ipps._tcp SRV 0 0 631 demohost
TXT ""
; Host Description Instruction
demohost AAAA 2001:db8:0:2::2
KEY 0 3 13 (
qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU
9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg==
); alg = ECDSAP256SHA256 ; key id = 14495
Figure 2: Example Zone File
図2：ゾーンファイルの例
Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping Dong, and Abtin Keshavarzian for their thorough technical reviews. Thanks to Kangping and Abtin as well for testing the document by doing an independent implementation. Thanks to Tamara Kemper for doing a nice developmental edit, Tim Wattenberg for doing an SRP requester proof-of-concept implementation at the Montreal Hackathon at IETF 102, and Tom Pusateri for reviewing during the hackathon and afterwards. Thanks to Esko for a really thorough second Last Call review. Thanks also to Nathan Dyck, Gabriel Montenegro, Kangping Dong, Martin Turon, and Michael Cowan for their detailed second last call reviews. Thanks to Patrik Fältström, Dhruv Dhody, David Dong, Joey Salazar, Jean-Michel Combes, and Joerg Ott for their respective directorate reviews. Thanks to Paul Wouters for a _really_ detailed IESG review! Thanks also to the other IESG members who provided comments or simply took the time to review the document.
TokeHøiland-Jørgensen、Jonathan Hui、Esko Dijk、Kangping Dong、およびAbtin Keshavarzianの徹底的な技術レビューに感謝します。独立した実装を行ってドキュメントをテストしてくれたKangpingとAbtinにも感謝します。素晴らしい発達編集をしてくれたTamara Kemper、IETF 102のMontreal HackathonでSRP Requester Proof-of Conceptの実装を行ってくれたTim Wattenbergは、ハッカソン中およびその後レビューしてくれたTom Pusateriに感謝します。Eskoに感謝します。Nathan Dyck、Gabriel Montenegro、Kangping Dong、Martin Turon、およびMichael Cowanに、詳細な2番目の最後のコールレビューに感謝します。PatrikFältström、Dhruv Dhody、David Dong、Joey Salazar、Jean-Michel Combes、およびJoerg Ottにそれぞれの監督レビューに感謝します。_ really_詳細なIESGレビューをしてくれたPaul Woutersに感謝します！また、コメントを提供するか、単にドキュメントを確認するために時間をかけてくれた他のIESGメンバーにも感謝します。
Ted Lemon
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: mellon@fugue.com
Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Phone: +1 408 974 3207
Email: cheshire@apple.com