Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 9874 W. Carroll
BCP: 244 Verisign Labs
Category: Best Current Practice G. Akiwate
ISSN: 2070-1721 Stanford University
September 2025
The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency.
拡張可能なプロビジョニングプロトコル（EPP）には、クライアントがドメインとホストオブジェクトを削除するコマンドが含まれます。どちらもドメイン名システム（DNS）で情報を公開するために使用されます。EPPには、DNS解像度の混乱を回避し、データの一貫性を維持することを目的とした削除のガイダンスも含まれています。ただし、オブジェクト間の運用上の関係により、そのガイダンスが実装が難しくなる可能性があります。一部のEPPクライアントは、DNS解像度とセキュリティに意図しない影響を与えるオブジェクトを削除するための運用プラクティスを開発しました。このドキュメントは、最良の現在のプラクティスについて説明し、DNS解像度の障害のリスクを減らし、クライアントサーバーのデータの一貫性を維持するドメインとホストオブジェクトを削除する新しい潜在的なプラクティスを提案します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、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/rfc9874.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9874で取得できます。
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 Used in This Document
3. Rationale for "SHOULD NOT be deleted"
3.1. DNS Considerations
3.2. Client-Server Consistency Considerations
3.3. Relational Consistency Considerations
4. Host Object Renaming Risk
5. Analysis of Practices for Domain and Host Object Deletion
5.1. Renaming to Sacrificial Hosts
5.1.1. Practice Benefits
5.1.2. Practice Detriments
5.1.3. Observed Practices for Renaming to Sacrificial Hosts
5.1.3.1. Renaming to External, Presumed Non-Existent Hosts
5.1.3.1.1. Practice Benefits
5.1.3.1.2. Practice Detriments
5.1.3.2. Renaming to "AS112.ARPA"
5.1.3.2.1. Practice Benefits
5.1.3.2.2. Practice Detriments
5.1.3.3. Renaming to Non-Authoritative Hosts
5.1.3.3.1. Practice Benefits
5.1.3.3.2. Practice Detriments
5.1.3.4. Renaming to Client-Maintained Dedicated Sacrificial
Name Server Host Objects
5.1.3.4.1. Practice Benefits
5.1.3.4.2. Practice Detriments
5.1.4. Potential Practices for Renaming to Sacrificial Hosts
5.1.4.1. Renaming to Pseudo-TLD
5.1.4.1.1. Practice Benefits
5.1.4.1.2. Practice Detriments
5.1.4.2. Renaming to Existing Special-Use TLD
5.1.4.2.1. Renaming to Reserved TLD
5.1.4.3. Renaming to a Special-Use Domain
5.1.4.3.1. Practice Benefits
5.1.4.3.2. Practice Detriments
5.1.4.4. Renaming to Community Sacrificial Name Server
Service
5.1.4.4.1. Practice Benefits
5.1.4.4.2. Practice Detriments
5.2. Deletion of Hosts
5.2.1. Observed Practices for Deletion of Hosts
5.2.1.1. Implicit Deletion of Affected Host Objects
5.2.1.1.1. Practice Benefits
5.2.1.1.2. Practice Detriments
5.2.1.2. Inform Affected Clients
5.2.1.2.1. Practice Benefits
5.2.1.2.2. Practice Detriments
5.2.2. Potential Practices for Deletion of Hosts
5.2.2.1. Request Explicit Deletion of Affected Host Objects
5.2.2.1.1. Practice Benefits
5.2.2.1.2. Practice Detriments
5.2.2.2. Provide Additional Deletion Details
5.2.2.2.1. Practice Benefits
5.2.2.2.2. Practice Detriments
5.2.2.3. Allow Explicit Deletion of a Domain with Restore
Capability
5.2.2.3.1. Practice Benefits
5.2.2.3.2. Practice Detriments
6. Recommendations
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
Section 3.2.2 of [RFC5731] contains text that has led some domain name registrars (acting as EPP clients) to adopt an operational practice of renaming name server host objects so that they can delete domain objects:
[RFC5731]のセクション3.2.2には、ドメイン名のホストオブジェクトを変更してドメインオブジェクトを削除できるように、いくつかのドメイン名レジストラ（EPPクライアントとして機能する）を導いたテキストが含まれています。
A domain object SHOULD NOT be deleted if subordinate host objects are associated with the domain object. For example, if domain "example.com" exists and host object "ns1.example.com" also exists, then domain "example.com" SHOULD NOT be deleted until host "ns1.example.com" has either been deleted or renamed to exist in a different superordinate domain.
下位ホストオブジェクトがドメインオブジェクトに関連付けられている場合、ドメインオブジェクトを削除しないでください。たとえば、domain "embler.com"が存在し、オブジェクトをホストする場合、ns1.example.com "も存在する場合、domain" example.com "は、ホスト「ns1.example.com」が削除されるか、異なる上位ドメインに存在するように変更されているまで削除する必要はありません。
Similarly, Section 3.2.2 of [RFC5732] contains this text regarding deletion of host objects:
同様に、[RFC5732]のセクション3.2.2には、ホストオブジェクトの削除に関するこのテキストが含まれています。
A host name object SHOULD NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object.
ホストオブジェクトが他のオブジェクトに関連付けられている場合、ホスト名オブジェクトを削除しないでください。たとえば、ホストオブジェクトがドメインオブジェクトに関連付けられている場合、既存の関連付けが壊れるまでホストオブジェクトを削除しないでください。最初に既存の関連性を破ることなくホストオブジェクトを削除すると、削除されたホストオブジェクトを参照するドメインオブジェクトのDNS解像度障害を引き起こす可能性があります。
These recommendations create a dilemma when the sponsoring client for "example.com" intends to delete "example.com" but its associated host object "ns1.example.com" is also associated with domain objects sponsored by another client. It is advised not to delete the host object due to its associated domain objects. However, the associated domain objects cannot be directly updated because they are sponsored by another client. This situation affects all EPP operators that have implemented support for host objects.
これらの推奨事項は、「Example.com」のスポンサークライアントが「Example.com」を削除することを意図している場合にジレンマを作成しますが、関連するホストオブジェクト「NS1.example.com」も別のクライアントがスポンサーになったドメインオブジェクトに関連付けられています。関連するドメインオブジェクトのため、ホストオブジェクトを削除しないことをお勧めします。ただし、関連するドメインオブジェクトは、別のクライアントがスポンサーになっているため、直接更新することはできません。この状況は、ホストオブジェクトのサポートを実装したすべてのEPPオペレーターに影響を与えます。
Section 3.2.5 of [RFC5732] describes host object renaming:
[RFC5732]のセクション3.2.5は、ホストオブジェクトの名前変更について説明します。
Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and any needed new attributes, and subsequently updating the other objects sponsored by the client.
ホスト名の変更は、ホストオブジェクトを参照する関連オブジェクトに影響を与える可能性があります。ホスト名の変更では、既存のアソシエーションを保持するために関連するオブジェクトの追加の更新を必要としないでください。1つの例外は、別のクライアントがスポンサーになっているオブジェクトとの関連を持つ外部ホストオブジェクトを変更します。このようなホストを直接更新する試みは、EPPエラーコード2305で失敗する必要があります。新しい名前と必要な新しい属性を持つ新しい外部ホストを作成し、その後クライアントがスポンサーになった他のオブジェクトを更新することにより、変更をプロビジョニングできます。
Section 1.1 of [RFC5732] includes a description of external hosts. Some EPP clients have developed operational practices that use host object renaming to break association between a domain object and host object. Note that the specific method used to rename the host object can create DNS delegation failures and introduce risks of loss of management control. If the new external host refers to an unregistered domain, then a malicious actor may register the domain and create the host object to gain control of DNS resolution for the domain previously associated with "ns1.example.com". If the new external host offers an authoritative DNS service but the domain is not assigned to an account, then a malicious actor may add the domain to a service account and gain control of (i.e., hijack) DNS resolution functionality. If the new external host offers recursive DNS service or no DNS service, then DNS requests for the domain will result in SERVFAIL messages or other errors. Aggressive requeries by DNS resolvers may then create large numbers of spurious DNS queries for an unresolvable domain. Note that renaming a host object to a name of an external host cannot be reversed by the EPP client.
[RFC5732]のセクション1.1には、外部ホストの説明が含まれています。一部のEPPクライアントは、ドメインオブジェクトとホストオブジェクト間の関連性を破るためにホストオブジェクトの名前変更を使用する運用プラクティスを開発しました。ホストオブジェクトの名前を変更するために使用される特定の方法は、DNS委任障害を作成し、管理制御の喪失のリスクを導入できることに注意してください。新しい外部ホストが未登録のドメインを参照する場合、悪意のあるアクターがドメインを登録し、ホストオブジェクトを作成して、以前に「NS1.example.com」に関連付けられたドメインのDNS解像度を制御することができます。新しい外部ホストが権威あるDNSサービスを提供しているが、ドメインがアカウントに割り当てられていない場合、悪意のあるアクターはドメインをサービスアカウントに追加し、DNS解像度の機能の制御を獲得することができます。新しい外部ホストが再帰的なDNSサービスまたはDNSサービスを提供している場合、ドメインのDNS要求はサーブファイルメッセージまたはその他のエラーになります。DNSリゾルバーによる積極的なリクエアは、分解できないドメインに対して多数の偽のDNSクエリを作成する場合があります。ホストオブジェクトを外部ホストの名前に変更することは、EPPクライアントが逆転させることはできないことに注意してください。
This document describes the rationale for the "SHOULD NOT be deleted" text in [RFC5731] and [RFC5732] as well as the risk associated with host object renaming. Section 5 includes a detailed analysis of the practices that have been and can be used to mitigate that risk. Section 6 includes specific recommendations for the best practices.
このドキュメントでは、[RFC5731]および[RFC5732]の「削除されてはならない」テキストの根拠と、ホストオブジェクトの名前変更に関連するリスクについて説明します。セクション5には、そのリスクを緩和するために使用された、および使用できるプラクティスの詳細な分析が含まれています。セクション6には、ベストプラクティスに関する具体的な推奨事項が含まれています。
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] で説明されているように解釈されます。
The primary consideration when deleting domain and host objects concerns the potential impact on DNS resolution. Deletion of a domain object will make all name servers associated with subordinate host objects unresolvable. Deletion of a host object will make any domain that has been delegated to the associated name server unresolvable. The text in [RFC5731] and [RFC5732] was written to encourage clients to take singular, discrete steps to delete objects in a way that avoids breaking DNS resolution functionality. Additionally, allowing host objects to exist after deletion of their superordinate domain object invites hijacking, as a malicious actor may reregister the domain object, potentially controlling resolution for the host objects and for their associated domain objects. It also creates orphan glue as described in [SAC048].
ドメインとホストオブジェクトを削除する場合の主な考慮事項は、DNS解像度への潜在的な影響に関するものです。ドメインオブジェクトの削除により、下位ホストオブジェクトに関連付けられたすべての名前サーバーが解決できません。ホストオブジェクトの削除は、関連する名前サーバーに委任されたドメインを解決できません。[RFC5731]および[RFC5732]のテキストは、DNS解像度の機能性を破らないようにオブジェクトを削除するための単数形で離散的な手順を実行するようクライアントが奨励するために書かれました。さらに、悪意のあるアクターがドメインオブジェクトを再登録し、ホストオブジェクトと関連するドメインオブジェクトの解像度を制御する可能性があるため、上位ドメインオブジェクトの削除後にホストオブジェクトが存在するようにすることがハイジャックを招待します。また、[SAC048]に記載されているように、孤児の接着剤を作成します。
A server that implicitly deletes subordinate host objects in response to a request to delete a domain object can create a data inconsistency condition in which the EPP client and the EPP server have different views of what remains registered after processing a <delete> command. The text in [RFC5731] and [RFC5732] was written to encourage clients to take singular, discrete steps to delete objects in a way that maintains client-server data consistency. Experience suggests that this inconsistency poses little operational risk.
ドメインオブジェクトを削除するリクエストに応じて下位ホストオブジェクトを暗黙的に削除するサーバーは、EPPクライアントとEPPサーバーが<delete>コマンドを処理した後に登録されているものの異なるビューを持つデータの不一致条件を作成できます。[RFC5731]および[RFC5732]のテキストは、クライアントサーバーのデータの一貫性を維持する方法でオブジェクトを削除するための単数形で離散的な手順を取ることをクライアントに奨励するために書かれました。経験は、この矛盾がほとんど運用上のリスクをもたらさないことを示唆しています。
Implementations of EPP can have dependencies on the hierarchical domain object / host object relationship, which can exist in a relational database. In such instances, deletion of a domain object without addressing the existing subordinate host objects can cause relational consistency and integrity issues. The text in [RFC5731] and [RFC5732] was written to reduce the risk of these issues arising as a result of implicit object deletion.
EPPの実装は、リレーショナルデータベースに存在する可能性のある階層ドメインオブジェクト /ホストオブジェクト関係に依存関係を持つことができます。そのような場合、既存の下位ホストオブジェクトに対処せずにドメインオブジェクトの削除は、関係の一貫性と整合性の問題を引き起こす可能性があります。[RFC5731]および[RFC5732]のテキストは、暗黙のオブジェクトの削除の結果として生じるこれらの問題のリスクを減らすために書かれました。
As described in [RFC5731], it is possible to delete a domain object that has associated host objects that are managed by other clients by renaming the host object to exist in a different superordinate domain. This is commonly required when the sponsoring client is unable to disassociate a host object from a domain object managed by another client because only the second client is authorized to make changes to their domain object and the EPP server requires host object disassociation to process a request to delete a domain object. For example:
[RFC5731]で説明されているように、別の上位ドメインに存在するようにホストオブジェクトを名前に変更することにより、他のクライアントが管理するホストオブジェクトを関連付けるドメインオブジェクトを削除することができます。これは、スポンサークライアントが別のクライアントが管理するドメインオブジェクトからホストオブジェクトを解離できない場合に一般的に必要です。これは、2番目のクライアントのみがドメインオブジェクトに変更を加えることを許可され、EPPサーバーはドメインオブジェクトを削除するリクエストを処理するためにホストオブジェクト分離を必要とするためです。例えば：
Domain object "domain1.example" is registered by ClientX.
ドメインオブジェクト "domain1.example"はclientxによって登録されています。
Domain object "domain2.example" is registered by ClientY.
ドメインオブジェクト "domain2.example"はclientyによって登録されています。
Subordinate host object "ns1.domain1.example" is registered and associated with domain object "domain1.example" by ClientX.
下位ホストオブジェクト "ns1.domain1.example"は登録され、domainオブジェクト「domain1.example」に関連付けられています。
Host object "ns1.domain1.example" is associated with domain object "domain2.example" by ClientY.
ホストオブジェクト "ns1.domain1.example"は、clientyによってドメインオブジェクト "domain2.example"に関連付けられています。
ClientX wishes to delete domain object "domain1.example". It can modify domain object "domain1.example" to remove the association of host object "ns1.domain1.example", but ClientX cannot remove the association of host object "ns1.domain1.example" from domain object "domain2.example" because "domain2.example" is sponsored by ClientY and ClientX is unable to determine that relationship. Only ClientY can modify domain object "domain2.example", and if they do not do so, ClientX will need to rename host object "ns1.domain1.example" so that "domain1.example" can be deleted.
ClientXは、ドメインオブジェクト「domain1.example」を削除したいと考えています。ドメインオブジェクト「ドメイン1.例」を変更して、ホストオブジェクトの関連付け「NS1.domain1.example」を削除できますが、clientx ns1.domain1.example "" domain2.example "からホストオブジェクトの関連付けを削除することはできません。クライアントのみがドメインオブジェクト「domain2.example」を変更でき、そうしない場合、clientxはホストオブジェクト「ns1.domain1.example」を変更する必要があります。
ClientX renames host object "ns1.domain1.example" to "ns1.example.org", creating an external host and meeting the EPP server's subordinate host object disassociation requirement. The renamed host object "ns1.example.org" is referred to as a "sacrificial" host [Risky-BIZness].
clientXはホストオブジェクト「ns1.domain1.example」を「ns1.example.org」に変更し、外部ホストを作成し、EPPサーバーの下位ホストオブジェクトの分離要件を満たします。名前を付けられたホストオブジェクト「NS1.example.org」は、「犠牲」ホスト[リスクバイズ性]と呼ばれます。
If domain "example.org" does not exist, this practice introduces a risk of DNS resolution hijacking if someone were to register the "example.org" domain and create a subordinate host object named "ns1.example.org". That name server would receive DNS queries for all domains delegated to it, allowing the operator of the name server to respond in potentially malicious ways.
domain "embler.org"が存在しない場合、このプラクティスは、誰かが「example.org」ドメインを登録し、「ns1.example.org」という名前の下位ホストオブジェクトを作成する場合、DNS解像度のハイジャックのリスクを導入します。その名前サーバーは、委任されたすべてのドメインのDNSクエリを受信し、名前サーバーのオペレーターが潜在的に悪意のある方法で応答できるようにします。
EPP servers can employ a range of practices for domain and host object deletion. Notably, the scope of any practice discussed here is the EPP server that adopts the practice, the domains managed by it, and the associated host objects where "associated" is described in [RFC5731] and [RFC5732]. The practices described in this document fall into two broad categories: renaming objects to use sacrificial hosts and allowing objects to be deleted even if there are existing data relationships. These practice categories are described in the following sections. For a broader consideration of practices and potential impacts on registries and registrars, [SAC125] offers some complementary insight.
EPPサーバーは、ドメインおよびホストオブジェクトの削除にさまざまなプラクティスを採用できます。特に、ここで説明する練習の範囲は、プラクティスを採用するEPPサーバー、それによって管理されたドメイン、および「関連する」が[RFC5731]および[RFC5732]で「関連する」という関連ホストオブジェクトです。このドキュメントで説明されているプラクティスは、2つの広範なカテゴリに分類されます。犠牲ホストを使用するオブジェクトの名前を変更し、既存のデータ関係がある場合でもオブジェクトを削除できるようにします。これらの実践カテゴリについては、次のセクションで説明します。レジストリとレジストラへの慣行と潜在的な影響をより広く検討するために、[SAC125]はいくつかの補完的な洞察を提供します。
Sacrificial hosts are hosts whose name is intended to remove an existing relationship between domain and host objects. To that end, sacrificial hosts are either renamed to an external host or associated with a different domain object in the EPP server. The first group of deletion practices use sacrificial hosts leveraging existing EPP server support for renaming host objects.
犠牲ホストは、その名前がドメインとホストオブジェクトの既存の関係を削除することを目的としたホストです。そのために、犠牲ホストは外部ホストに変更されるか、EPPサーバーの異なるドメインオブジェクトに関連付けられます。削除プラクティスの最初のグループは、ホストオブジェクトの名前を変更するための既存のEPPサーバーサポートを活用する犠牲ホストを使用します。
Affected domains remain delegated in the zone. Registrars and registrants of affected domains may be able to determine the intention of the change.
影響を受けるドメインはゾーン内に委任されたままです。影響を受けるドメインのレジストラと登録者は、変更の意図を決定できる場合があります。
Zones are crowded with irrelevant records. Registrars and registrants of affected domains are required to clean them up.
ゾーンには無関係な記録が混雑しています。影響を受けたドメインのレジストラと登録者は、それらをクリーンアップするために必要です。
As described above, this practice renames subordinate host objects to an external host in order to allow the deletion of the superordinate domain object. The external host is presumed to be non-existent by the deleting EPP client, but no check for existence is typically performed. This practice has been observed in use. This practice MUST NOT be used.
上記のように、このプラクティスは、上位ドメインオブジェクトの削除を可能にするために、下位ホストオブジェクトを外部ホストに変更します。外部ホストは、削除するEPPクライアントによって存在しないと推定されますが、通常、存在のチェックは実行されません。この慣行は使用されています。このプラクティスを使用してはなりません。
The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic.
主な利点は、削除するEPPクライアントにとって利便性です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。
Malicious actors have registered these parent domains and created child host objects to take control of DNS resolution for associated domains [Risky-BIZness].
悪意のある俳優は、これらの親ドメインを登録し、関連するドメインのDNS解像度を制御するために子どものホストオブジェクトを作成しました[リスクバイズ性]。
Sponsoring clients of the associated domains are not informed of the change. Associated domains may no longer resolve if all their hosts are renamed. Associated domains may still resolve if they continue to be associated with existent hosts; in which case, their partial vulnerability to hijacking is more difficult to detect.
関連するドメインのクライアントのスポンサーは、変更について知らされていません。関連するドメインは、すべてのホストの名前が変更された場合、もはや解決できない場合があります。関連するドメインは、既存のホストに関連付けられ続けている場合でも解決する場合があります。その場合、ハイジャックに対する部分的な脆弱性を検出するのはより困難です。
Some domain registrars, acting as EPP clients, have renamed host objects to subdomains of "AS112.ARPA" or "EMPTY.AS112.ARPA" [Risky-BIZness-IRTF]. This practice has been observed in use.
EPPクライアントとして機能する一部のドメインレジストラは、ホストオブジェクトを「AS112.ARPA」または「empty.As112.Arpa」のサブドメインに変更しました[Risky-Bizness-Artf]。この慣行は使用されています。
The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic.
主な利点は、削除するEPPクライアントにとって利便性です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。
This is a misuse of AS112, which is for reverse lookups on non-unique IPs, primarily so local admins can sinkhole non-global traffic [RFC7535]. "EMPTY.AS112.ARPA" is designed to be used with DNAME aliasing, not as a parent domain for sacrificial name servers (see Section 3 of [RFC7535]). Unexpected AS112 traffic has previously caused problems with intrusion detection systems and firewalls [RFC6305]. Local administrators can potentially hijack requests. AS112 infrastructure must be maintained.
これはAS112の誤用です。これは、非ユニークIPSの逆検索用であり、主にローカル管理者が非グロールトラフィックを陥没させることができます[RFC7535]。「empty.as112.arpa」は、犠牲名サーバーの親ドメインとしてではなく、dnameエイリアシングで使用するように設計されています（[RFC7535]のセクション3を参照）。予期しないAS112トラフィックは、以前に侵入検知システムとファイアウォールに問題を引き起こしました[RFC6305]。ローカル管理者は、潜在的にリクエストをハイジャックできます。AS112インフラストラクチャを維持する必要があります。
Some domain registrars, acting as EPP clients, have maintained host objects with glue records pointing to prominent public recursive DNS services. This practice has been observed in use. This practice MUST NOT be used.
EPPクライアントとして機能する一部のドメインレジストラは、著名な公共の再帰DNSサービスを指す接着剤レコードでホストオブジェクトを維持しています。この慣行は使用されています。このプラクティスを使用してはなりません。
The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic.
主な利点は、削除するEPPクライアントにとって利便性です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。
Queries for the associated domains result in SERVFAIL or other failure responses. Some recursive name server implementations may aggressively requery for these responses, potentially resulting in large numbers of queries for unresolvable domains [RFC9520].
関連するドメインのクエリは、サーブファイルまたはその他の障害応答をもたらします。いくつかの再帰名サーバーの実装は、これらの応答を積極的に補充する可能性があり、潜在的に解決不可能なドメイン[RFC9520]の多くのクエリが生じる可能性があります。
EPP clients MAY rename the host object to be deleted to a sacrificial name server host object maintained by the client. This requires that the client maintain the registration of the sacrificial name server's superordinate domain. The client may consider long registration periods and the use of registrar and registry lock services to maintain and protect the superordinate domain and the host object. Failures to maintain these registrations have allowed domain hijacks [Risky-BIZness].
EPPクライアントは、クライアントが管理する犠牲名サーバーホストオブジェクトに削除されるようにホストオブジェクトの名前を変更する場合があります。これには、クライアントがSacrificial Name Serverの上位ドメインの登録を維持する必要があります。クライアントは、長い登録期間と、上位ドメインとホストオブジェクトを維持および保護するためのレジストラおよびレジストリロックサービスの使用を検討する場合があります。これらの登録の維持に失敗すると、ドメインハイジャック[リスクのある状態]が可能になりました。
The client-maintained dedicated sacrificial name server MUST resolve to one or more IP addresses, and the client MUST operate an authoritative DNS name server on those addresses. The name server MAY provide any valid response.
クライアントにメンテナンスされた専用の犠牲名サーバーは、1つ以上のIPアドレスに解決する必要があり、クライアントはそれらのアドレスで権威あるDNSネームサーバーを操作する必要があります。名前サーバーは、有効な応答を提供できます。
This practice has been observed in use.
この慣行は使用されています。
Associated domains are not able to be hijacked, remain in the zone, and have valid DNS records and a responsive DNS service. The service may provide responses that indicate problems with a domain's delegation, such as non-existence or including controlled interruption IP addresses [RFC8023].
関連ドメインは、ハイジャックされたり、ゾーンにとどまり、有効なDNSレコードとレスポンシブDNSサービスを持っていることができません。このサービスは、非存在や制御された中断IPアドレス[RFC8023]など、ドメインの代表団の問題を示す回答を提供する場合があります。
This requires that the client maintain the registration of the sacrificial name server's superordinate domain. The client may consider long registration periods and the use of registrar and registry lock services to maintain and protect the superordinate domain and the host object. Failures to maintain these registrations have allowed domain hijacks [Risky-BIZness].
これには、クライアントがSacrificial Name Serverの上位ドメインの登録を維持する必要があります。クライアントは、長い登録期間と、上位ドメインとホストオブジェクトを維持および保護するためのレジストラおよびレジストリロックサービスの使用を検討する場合があります。これらの登録の維持に失敗すると、ドメインハイジャック[リスクのある状態]が可能になりました。
Failure responses may cause aggressive requerying (see Section 5.1.3.3.2).
障害応答は、積極的な補充を引き起こす可能性があります（セクション5.1.3.3.2を参照）。
Clients may rename host objects to use ".alt" or another non-DNS pseudo-TLD (Top-Level Domain), as suggested in [Risky-BIZness-IRTF]. This practice has not been observed in use. This practice MUST NOT be used.
クライアントは、[Risky-Bizness-artf]で示唆されているように、「.Alt」または別の非DNS擬似TLD（トップレベルドメイン）を使用するホストオブジェクトの名前を変更する場合があります。この慣行は使用されていません。このプラクティスを使用してはなりません。
The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked through the registration of these identifiers and delegation in the DNS.
主な利点は、削除するEPPクライアントにとって利便性です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。従属ドメインは、これらの識別子の登録とDNSの委任を介してハイジャックすることはできません。
The ".alt" pseudo-TLD is to be used "to signify that this is an alternative (non-DNS) namespace and should not be looked up in a DNS context" [RFC9476]. Some EPP servers may restrict TLDs to valid IANA-delegated TLDs. These entries would mix DNS and non-DNS protocols, risk name collisions, create confusion, and potentially result in unpredictable resolver behaviors. These identifiers may be registered in non-DNS namespaces, potentially leading to hijacking vulnerabilities based in other systems.
「.alt」pseudo-tldは、これが代替（非DNS）名前空間であり、DNSコンテキストで調べてはならないことを示すために使用されます」[RFC9476]。一部のEPPサーバーは、TLDを有効なIANA解除されたTLDに制限する場合があります。これらのエントリは、DNSと非DNSプロトコル、リスク名の衝突、混乱を引き起こし、予測不可能なリゾルバーの動作をもたらす可能性があります。これらの識別子は、非DNSネームスペースに登録され、他のシステムに基づいた脆弱性のハイジャックにつながる可能性があります。
Clients may rename host objects to a special-use TLD that cannot resolve in the DNS. Several variations have been suggested. This practice has not been observed in use.
クライアントは、DNSで解決できない特別なTLDにホストオブジェクトの名前を変更する場合があります。いくつかのバリエーションが提案されています。この慣行は使用されていません。
Clients may rename host objects to use a reserved special-use [RFC6761] TLD, as suggested in [Risky-BIZness].
クライアントは、[Risky-Bizness]で示唆されているように、ホストオブジェクトの名前を変更して、予約された特殊用途[RFC6761] TLDを使用できます。
The primary benefit is convenience for the deleting EPP client. These TLDs are already reserved and will not resolve. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked.
主な利点は、削除するEPPクライアントにとって利便性です。これらのTLDはすでに予約されており、解決しません。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。依存ドメインをハイジャックすることはできません。
The use of TLDs reserved for special purposes [RFC6761] may be confusing without a domain designated by the community for this purpose (see "sacrificial.invalid" in Sections 5.1.4.3 and 6). In addition, their use may be prevented by EPP server policy.
特別な目的のために予約されているTLDSの使用[RFC6761]は、この目的のためにコミュニティによって指定されたドメインなしで混乱する可能性があります（セクション5.1.4.3および6の「sacrificial.invalid」を参照）。さらに、EPPサーバーポリシーによってそれらの使用が防止される場合があります。
Clients would rename hosts to a special-use domain or subdomain thereof. The domain may be a special-use SLD (Second-Level Domain) (e.g., sacrificial.invalid) or a new reserved TLD (e.g., .sacrificial). Use of this domain would communicate the client's intention to create a sacrificial host. IANA would add this domain to the "Special-Use Domain Name" registry if such a new TLD is created using either IETF or ICANN processes. This practice has not been observed in use. In terms of the questions from [RFC6761]:
クライアントは、ホストを特別な使用ドメインまたはそのサブドメインに変更します。ドメインは、特別な使用SLD（第2レベルのドメイン）（例：Sacrificial.invalid）または新しい予約されたTLD（例えば、.sacrificial）である場合があります。このドメインの使用は、犠牲ホストを作成するというクライアントの意図を伝えます。IANAは、IETFまたはICANNプロセスのいずれかを使用してこのような新しいTLDが作成される場合、このドメインを「特別使用ドメイン名」レジストリに追加します。この慣行は使用されていません。[RFC6761]からの質問に関して：
1. These names are not expected to be visible to human users. However, the purpose of these domains is expected to be semantically recognizable to human users.
1. これらの名前は、人間のユーザーに表示されることは期待されていません。ただし、これらのドメインの目的は、人間のユーザーが意味的に認識できることが期待されています。
2. Application software is not expected to recognize these names as special or treat them differently than other allowed domain names.
2. アプリケーションソフトウェアは、これらの名前を特別なものとして認識したり、他の許可されているドメイン名とは異なる方法で扱うことは期待されていません。
3. Name resolution APIs and libraries are not expected to recognize these names as special or treat them differently than other allowed domain names.
3. 名前解像度APIとライブラリは、これらの名前を特別なものとして認識したり、他の許可されているドメイン名とは異なる方法で扱うことは期待されていません。
4. Caching name servers are not expected to recognize these names as special or treat them differently than other allowed domain names.
4. キャッシング名サーバーは、これらの名前を特別なものとして認識したり、他の許可されたドメイン名とは異なる方法で扱うことは期待されていません。
5. Authoritative name servers are not expected to recognize these names as special or treat them differently than other allowed domain names. Requests to the root for this domain would result in an NXDOMAIN response [RFC9499].
5. 権威ある名前サーバーは、これらの名前を特別なものとして認識したり、他の許可されているドメイン名とは異なる方法で扱うことは期待されていません。このドメインのルートへのリクエストは、NxDomain応答[RFC9499]になります。
6. DNS server operators will treat this domain and its subdomains as they would any other allowed names in the DNS.
6. DNSサーバーオペレーターは、このドメインとそのサブドメインを、DNSの他の許可された名前と同様に扱います。
7. DNS registries/registrars will not be able to register this domain and must deny requests to register it or its subdomains.
7. DNSレジストリ/レジストラはこのドメインを登録することができず、それまたはそのサブドメインを登録するためのリクエストを拒否する必要があります。
This option would offer clarity concerning the intentions of registrars that rename hosts. It would also enable registrars of affected domains ease of detection of renamed hosts. This option is also convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked through the registration of these identifiers and delegation in the DNS.
このオプションは、ホストの名前を変更するレジストラの意図に関する明確さを提供します。また、影響を受けるドメインのレジストラが変更されたホストの検出のしやすさを可能にします。このオプションは、EPPクライアントの削除にも便利です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。従属ドメインは、これらの識別子の登録とDNSの委任を介してハイジャックすることはできません。
This would require cooperation and policy changes for registrars and registries.
これには、レジストラとレジストリの協力とポリシーの変更が必要になります。
A new community-wide service could be created explicitly intended for use for renaming host records. This would require maintenance of name servers capable of authoritatively responding with NXDOMAIN or a controlled interruption IP addresses [RFC8023] for all queries without delegating domains or records. This service could use a new special-use TLD created through ICANN or IETF processes (e.g., ".sacrificial"), as an IAB request that IANA delegate an SLD for ".arpa" (e.g., "sacrificial-nameserver.arpa"), or as a contracted sinkhole service by ICANN or other DNS ecosystem actors. This practice has not been observed in use.
ホストレコードの名前を変更するために使用することを明示的に意図した新しいコミュニティ全体のサービスを作成できます。これには、ドメインやレコードを委任せずに、すべてのクエリに対して、NXDomainまたは制御された中断IPアドレス[RFC8023]で権威ある対応を可能にすることができる名前サーバーのメンテナンスが必要です。このサービスは、ICANNまたはIETFプロセスを介して作成された新しい特殊使用TLD（例：「.sacrificial」）を使用して、IABの要求として、IANAは「.ARPA」（例えば、「Sacrificial-Nameserver.arpa」）、またはICANNまたはその他のdnsエコプロテクなアクターによる契約されたシンクホールサービスとして使用することを要求します。この慣行は使用されていません。
This is convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking. This would provide a well-understood, industry-standard solution, allowing registrars and registrants to easily identify associated domains that have been affected. Infrastructure operators could monitor traffic to identify affected associated domains that result in significant traffic and attempt to contact registrars and registrants. Economies of scale would allow reduced overall costs to the industry (in contrast to each client running an independent service).
これは、EPPクライアントの削除に便利です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。関連するドメインは、ハイジャックに対して脆弱ではありません。これにより、よく理解された業界標準のソリューションが提供され、レジストラと登録者が影響を受けた関連ドメインを簡単に識別できるようになります。インフラストラクチャオペレーターは、トラフィックを監視して、かなりのトラフィックをもたらす影響を受ける関連ドメインを特定し、レジストラと登録者に連絡しようとすることができます。規模の経済により、業界への全体的なコストの削減が可能になります（独立したサービスを実行している各クライアントとは対照的に）。
Some entity must maintain the infrastructure for the service.
一部のエンティティは、サービスのインフラストラクチャを維持する必要があります。
The second group of practices is based on EPP server support for allowing objects to be deleted even if there are existing data relationships. The recommendations in [RFC5731] are intended to maintain consistency. However, they are not requirements.
プラクティスの2番目のグループは、既存のデータ関係がある場合でもオブジェクトを削除できるようにするためのEPPサーバーサポートに基づいています。[RFC5731]の推奨事項は、一貫性を維持することを目的としています。ただし、それらは要件ではありません。
EPP servers may relax their constraints and allow sponsoring clients to delete host objects without consideration of associations with domain objects sponsored by other clients. The registry automatically disassociates the deleted host objects from domain objects sponsored by other clients. This practice has been observed in use.
EPPサーバーは、制約を緩和し、スポンサークライアントが他のクライアントがスポンサーになったドメインオブジェクトとの関連を考慮せずにホストオブジェクトを削除できるようにすることができます。レジストリは、他のクライアントが後援するドメインオブジェクトから削除されたホストオブジェクトを自動的に分離します。この慣行は使用されています。
This is convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking.
これは、EPPクライアントの削除に便利です。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。関連するドメインは、ハイジャックに対して脆弱ではありません。
This could result in domains with no name servers being removed from the zone or domains with only one name server remaining in the zone. Deletions could potentially affect large numbers of associated domains, placing strain on domain registries.
これにより、名前サーバーがゾーンまたはドメインから削除されていないドメインがゾーンに残っているドメインやドメインから削除される可能性があります。削除は、多数の関連ドメインに潜在的に影響を及ぼし、ドメインレジストリに負担をかける可能性があります。
The sponsoring clients of affected domain objects may also be informed of the change (e.g., through the EPP Change Poll extension [RFC8590]). This practice has been observed in use.
影響を受けるドメインオブジェクトのスポンサークライアントは、変更についても通知される場合があります（たとえば、EPP変更ポール拡張[RFC8590]）。この慣行は使用されています。
Updates help achieve the goals of client-server data consistency and minimal interruptions to resolution. The sponsoring clients of affected domain objects are able to update their database to reflect the change and would be able to inform the domain's registrant. The sponsoring clients can automatically update the affected domains to use another authoritative host.
更新は、クライアントサーバーのデータの一貫性の目標を達成し、解決に対する最小限の中断を達成するのに役立ちます。影響を受けたドメインオブジェクトのスポンサークライアントは、データベースを更新して変更を反映することができ、ドメインの登録者に通知することができます。スポンサークライアントは、影響を受けるドメインを自動的に更新して、別の権威あるホストを使用できます。
This change requires additional development on the part of EPP servers and clients. There may be scalability concerns if large numbers of domain objects are updated in a single transaction.
この変更には、EPPサーバーとクライアントの側で追加の開発が必要です。単一のトランザクションで多数のドメインオブジェクトが更新されている場合、スケーラビリティの懸念がある場合があります。
Sponsoring clients requesting the deletion of host objects would explicitly request their disassociation from domain objects sponsored by other clients. This practice has not been observed in use.
ホストオブジェクトの削除を要求するクライアントのスポンサーは、他のクライアントが後援するドメインオブジェクトからの分離を明示的に要求します。この慣行は使用されていません。
Registries would not be required to unilaterally take responsibility for deletion. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking.
レジストリは、削除に対して一方的に責任を負う必要はありません。削除するEPPクライアントは、権威あるDNSサービスを維持したり、トラフィックを受け取ったりする必要はありません。関連するドメインは、ハイジャックに対して脆弱ではありません。
This could result in domains with no name servers being removed from the zone or domains with only one name server remaining in the zone. Deletions could potentially affect large numbers of associated domains, placing strain on domain registries.
これにより、名前サーバーがゾーンまたはドメインから削除されていないドメインがゾーンに残っているドメインやドメインから削除される可能性があります。削除は、多数の関連ドメインに潜在的に影響を及ぼし、ドメインレジストリに負担をかける可能性があります。
The EPP server may provide the deleting EPP client with additional details of the affected objects. The deleting EPP client may receive a response (e.g., using msg, reason, or msgQ elements of the EPP response [RFC5730]) that deletion of the host object would affect domain objects sponsored by another client and may receive details about those objects (e.g., using the EPP poll command). This practice has not been observed in use.
EPPサーバーは、削除するEPPクライアントに影響を受けるオブジェクトの追加の詳細を提供する場合があります。削除するEPPクライアントは、ホストオブジェクトの削除が別のクライアントがスポンサーになったドメインオブジェクトに影響を与える可能性があるという応答を受信する場合があります（EPP応答のMSG、理由、またはMSGQ要素[RFC5730]）。この慣行は使用されていません。
The deleting EPP client would be able to better understand and assess the potential harms of host object deletion. Depending on the content of the message, the deleting EPP client might choose additional actions, such as delaying the deletion until manual approval can be obtained, renaming the host objects, or informing affected EPP clients. This would give EPP clients greater flexibility with respect to deletion. For example, they may choose only to exercise deletions that have no impact on other clients.
削除するEPPクライアントは、ホストオブジェクトの削除の潜在的な害をよりよく理解し、評価することができます。メッセージの内容に応じて、削除するEPPクライアントは、手動承認を取得するまで削除を遅らせる、ホストオブジェクトの名前を変更したり、影響を受けたEPPクライアントに通知するなど、追加のアクションを選択する場合があります。これにより、EPPクライアントは削除に関してより柔軟になります。たとえば、他のクライアントに影響を与えない削除を行使することのみを選択できます。
This change would require additional development on the part of EPP servers and clients. There may be scalability concerns if large numbers of domain objects are updated in a single transaction. The EPP server must determine the relevant information to provide for the EPP client's assessment.
この変更には、EPPサーバーおよびクライアントの側で追加の開発が必要です。単一のトランザクションで多数のドメインオブジェクトが更新されている場合、スケーラビリティの懸念がある場合があります。EPPサーバーは、EPPクライアントの評価を提供するために関連情報を決定する必要があります。
Explicit deletion of a domain name with a cascade purge of subordinate host objects and associations with other domains may be an unrecoverable operation, increasing the potential negative effects of malicious or accidental actions.
下位ホストオブジェクトのカスケードパージを使用したドメイン名の明示的な削除および他のドメインとの関連は、回復不可能な操作であり、悪意のあるまたは偶発的な行動の潜在的な悪影響を増加させる可能性があります。
To mitigate this risk, EPP servers can allow for the explicit deletion of a domain with subordinate host objects associated with other domains only when the associations can be restored by the <restore> operation described in [RFC3915].
このリスクを軽減するために、EPPサーバーは、[RFC3915]で説明されている<復元>操作によって関連性を復元できる場合にのみ、他のドメインに関連付けられた下位ホストオブジェクトを持つドメインの明示的な削除を可能にします。
In order to allow restore, EPP servers may keep the subordinate host objects with a "pendingDelete" status and keep associations with other domains. This makes the objects unavailable in the DNS and provides a preview of the deletion.
復元を許可するために、EPPサーバーは、下位ホストオブジェクトに「保留中」ステータスを維持し、他のドメインとの関連を保持する場合があります。これにより、オブジェクトがDNSで利用できなくなり、削除のプレビューが提供されます。
If the action was malicious, accidental, or had negative side effects, the domain, its subordinate host objects, and the associations with other domains can be restored with the <restore> operation [RFC3915] during the redemption period. The purge of the domain will correspond with the purging of the subordinate hosts objects and the associations at the end of the pending delete period [RFC3915].
アクションが悪意があり、偶発的で、または負の副作用があった場合、ドメイン、その下位ホストオブジェクト、および他のドメインとの関連は、償還期間中<復元>操作[RFC3915]で復元できます。ドメインのパージは、下位ホストオブジェクトのパージと、保留中の削除期間の終わりにある関連付けに対応します[RFC3915]。
Due to the potentially large number of associations, the server can asynchronously update (e.g., add and remove from DNS) and purge the associations.
潜在的に多数の関連性があるため、サーバーは非同期的に更新し（DNSから追加および削除）、関連付けをパージできます。
This practice has not been observed in use.
この慣行は使用されていません。
This practice enables the clients to directly delete the domains that they need since the server will fully support restoration of the associations during the redemption period. The management of the domain and the subordinate hosts will be simplified for the client by supporting the explicit deletion of the domain with the capability of mitigating a destructive malicious or accidental action.
このプラクティスにより、クライアントは、サーバーが償還期間中に関連性の復元を完全にサポートするため、必要なドメインを直接削除できます。ドメインと下位ホストの管理は、破壊的な悪意のあるまたは偶発的なアクションを緩和する能力とドメインの明示的な削除をサポートすることにより、クライアントのために簡素化されます。
By making it easier for a client to explicitly delete a domain having subordinate hosts with associations, there is higher risk of inadvertent side effects in a single delete command. There is existing risk in EPP of inadvertent side effects, such as adding the "clientHold" status to the domain that will impact the DNS resolution of the subordinate hosts and the associated delegations. The ability to easily roll back the command is key to minimize the impact of the side effects. Another issue is the potential size of the database transaction to disable, re-enable, or purge the subordinate host associations, since there is no limit to the number of associations to delegated domains. Servers can break up the disable, re-enable, or purge of the subordinate host associations into smaller transactions by implementing it asynchronously.
クライアントが関連性のある下位ホストを持つドメインを明示的に削除できるようにすることにより、単一の削除コマンドで不注意な副作用のリスクが高くなります。EPPの既存のリスクは、下位ホストと関連する委任のDNS解像度に影響を与える「クライアントホールド」ステータスをドメインに追加するなど、不注意な副作用のリスクがあります。コマンドを簡単にロールバックする機能は、副作用の影響を最小限に抑えるための鍵です。別の問題は、委任されたドメインへの関連付けの数に制限がないため、下位ホストアソシエーションを無効にしたり、再度負担したり、パージしたりするデータベーストランザクションの潜在的なサイズです。サーバーは、非同期に実装することにより、下位ホストの関連付けを無効にすることにより、下位ホストの関連付けを小規模なトランザクションに分割することができます。
EPP servers and clients MUST implement one of the following practices to delete domain and host objects with minimal undesired side effects:
EPPサーバーとクライアントは、最小限の望ましくない副作用でドメインとホストオブジェクトを削除するには、以下のプラクティスのいずれかを実装する必要があります。
* Rename host objects to a sacrificial name server host object maintained by the client (see Section 5.1.3.4).
* ホストオブジェクトの名前を、クライアントが維持している犠牲名サーバーホストオブジェクトに変更します（セクション5.1.3.4を参照）。
* Delete host objects and associations with the restore option (see Section 5.2.2.3) based on explicit client requests (see Section 5.2.2.1). Provide requesting clients additional deletion details (see Section 5.2.2.2), and inform affected clients of changes (see Section 5.2.1.2).
* 明示的なクライアント要求に基づいて、ホストオブジェクトと復元オプションとの関連を削除します（セクション5.2.2.3を参照）（セクション5.2.2.1を参照）。クライアントに追加の削除の詳細（セクション5.2.2.2を参照）を提供し、影響を受けるクライアントに変更を通知します（セクション5.2.1.2を参照）。
* Rename host objects to a sacrificial name server host object that uses a special-use domain (see Section 5.1.4.3) that avoids the special-use domain issues described in [RFC8244]. Use of "sacrificial.invalid" (see Section 5.1.4.3) as the parent domain for the host objects is RECOMMENDED to avoid the overhead of creating a new TLD using either IETF or ICANN processes that offers no additional operational benefit.
* [RFC8244]で説明されている特別な使用ドメインの問題を回避する特別な使用ドメイン（セクション5.1.4.3を参照）を使用する犠牲名サーバーホストオブジェクトにホストオブジェクトを変更します。ホストオブジェクトの親ドメインとしての「sacrificial.invalid」（セクション5.1.4.3を参照）の使用は、追加の運用上の利点を提供しないIETFまたはICANNプロセスを使用して新しいTLDを作成するオーバーヘッドを避けるために推奨されます。
All other practices described in Section 5 are NOT RECOMMENDED due to undesired side effects.
セクション5で説明されている他のすべてのプラクティスは、望ましくない副作用のために推奨されません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document describes guidance found in [RFC5731] and [RFC5732] regarding the deletion of domain and host objects by EPP clients. That guidance sometimes requires that host objects be renamed such that they become "external" hosts (see Section 1.1 of [RFC5731]) in order to meet an EPP server's requirements for host object disassociation prior to domain object deletion. Host object renaming can introduce a risk of DNS resolution hijack under certain operational conditions. This document provides guidance that is intended to reduce the risk of DNS resolution failure or hijacking as part of the process of deleting EPP domain or host objects.
このドキュメントは、EPPクライアントによるドメインとホストオブジェクトの削除に関する[RFC5731]および[RFC5732]にあるガイダンスについて説明しています。そのガイダンスでは、ドメインオブジェクトの削除前にホストオブジェクトの分離に関するEPPサーバーの要件を満たすために、ホストオブジェクトが「外部」ホスト（[RFC5731]のセクション1.1を参照）になるように名前が変更されることが必要です。ホストオブジェクトの名前変更は、特定の運用条件下でDNS解像度のハイジャックのリスクを導入できます。このドキュメントは、EPPドメインまたはホストオブジェクトを削除するプロセスの一部として、DNS解像度の障害またはハイジャックのリスクを減らすことを目的としたガイダンスを提供します。
Child domains that depend on host objects associated with domain objects sponsored by another EPP client for DNS resolution may be protected from hijacking through the use of DNSSEC. Their resolution may be protected from the effects of deletion by using host objects associated with multiple domain objects. DNSSEC and multiple host objects may interfere with the use of controlled interruption IP addresses to alert registrants to DNS changes. EPP clients can periodically scan sponsored domains for association with sacrificial name servers and alert end users concerning those domains.
DNS解像度のために別のEPPクライアントが後援するドメインオブジェクトに関連付けられたホストオブジェクトに依存する子ドメインは、DNSSECの使用を通じてハイジャックから保護される場合があります。それらの解像度は、複数のドメインオブジェクトに関連付けられたホストオブジェクトを使用することにより、削除の影響から保護される場合があります。DNSSECおよび複数のホストオブジェクトは、DNSの変更を登録者に警告するために、制御された割り込みIPアドレスの使用を妨げる場合があります。EPPクライアントは、犠牲名サーバーとの関連性を定期的にスキャンし、それらのドメインに関するエンドユーザーを警告することができます。
In absence of DNSSEC use by the victim, an attacker who gains control of a single name server can use DNSSEC to instead take over the victim domain completely if the registry operator and registrar process for automated DS maintenance neglects to check all name servers for consistency in CDS/CDNSKEY records. In this scenario, the domain will end up with DS records derived from the attacker CDS/ CDNSKEY records if, by chance, the queries happen to hit the attacker-controlled name server. Subsequently, validating resolvers will no longer accept responses from the legitimate name servers. Moreover, with the use of CSYNC, an attacker may update the domain NS records, removing the legitimate name servers entirely.
被害者によるDNSSECの使用がない場合、単一の名前サーバーの制御を獲得する攻撃者は、DNSSECを使用して、自動化されたDSメンテナンスのレジストリオペレーターとレジストラプロセスがCDS/CDNSKEYレコードの一貫性についてすべての名前サーバーをチェックすることを無視している場合、犠牲者ドメインを完全に引き継ぐことができます。このシナリオでは、ドメインは攻撃者CDS/ CDNSKEYレコードから派生したDSレコードで終了します。その後、リゾルバーの検証は、正当な名前サーバーからの応答を受け入れなくなります。さらに、CSYNCの使用により、攻撃者はドメインNSレコードを更新し、正当な名前サーバーを完全に削除することができます。
[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>.
[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
the Extensible Provisioning Protocol (EPP)", RFC 3915,
DOI 10.17487/RFC3915, September 2004,
<https://www.rfc-editor.org/info/rfc3915>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
August 2009, <https://www.rfc-editor.org/info/rfc5732>.
[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>.
[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>.
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
October 2017, <https://www.rfc-editor.org/info/rfc8244>.
[RFC9476] Kumari, W. and P. Hoffman, "The .alt Special-Use Top-Level
Domain", RFC 9476, DOI 10.17487/RFC9476, September 2023,
<https://www.rfc-editor.org/info/rfc9476>.
[RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by
PRISONER.IANA.ORG!", RFC 6305, DOI 10.17487/RFC6305, July
2011, <https://www.rfc-editor.org/info/rfc6305>.
[RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
"AS112 Redirection Using DNAME", RFC 7535,
DOI 10.17487/RFC7535, May 2015,
<https://www.rfc-editor.org/info/rfc7535>.
[RFC8023] Thomas, M., Mankin, A., and L. Zhang, "Report from the
Workshop and Prize on Root Causes and Mitigation of Name
Collisions", RFC 8023, DOI 10.17487/RFC8023, November
2016, <https://www.rfc-editor.org/info/rfc8023>.
[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
Extensible Provisioning Protocol (EPP)", RFC 8590,
DOI 10.17487/RFC8590, May 2019,
<https://www.rfc-editor.org/info/rfc8590>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9520] Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
of DNS Resolution Failures", RFC 9520,
DOI 10.17487/RFC9520, December 2023,
<https://www.rfc-editor.org/info/rfc9520>.
[Risky-BIZness]
Akiwate, G., Savage, S., Voelker, G., and K. Claffy,
"Risky BIZness: Risks Derived from Registrar Name
Management", IMC '21: Proceedings of the 21st ACM Internet
Measurement Conference, DOI 10.1145/3487552.3487816,
November 2021, <https://doi.org/10.1145/3487552.3487816>.
[Risky-BIZness-IRTF]
Akiwate, G., Savage, S., Voelker, G., and K. Claffy,
"Risky BIZness: Risks Derived from Registrar Name
Management", IETF 115 Proceedings, November 2022,
<https://datatracker.ietf.org/doc/slides-115-irtfopen-
risky-bizness-risks-derived-from-registrar-name-
management/>.
[SAC048] ICANN Security and Stability Advisory Committee, "SSAC
Comment on Orphan Glue Records in the Draft Applicant
Guidebook", SAC 048, 12 May 2011,
<https://itp.cdn.icann.org/en/files/security-and-
stability-advisory-committee-ssac-reports/sac-048-en.pdf>.
[SAC125] ICANN Security and Stability Advisory Committee, "SSAC
Report on Registrar Nameserver Management", SAC 125, 9 May
2024, <https://itp.cdn.icann.org/en/files/security-and-
stability-advisory-committee-ssac-reports/sac-
125-09-05-2024-en.pdf>.
The authors would like to thank the following people for their contributions to this document: David Blacka, Brian Dickson, James Gould, Pawel Kowalik, Mario Loffredo, James Mitchell, Matthew Thomas, Peter Thomassen, and Duane Wessels.
著者は、この文書への貢献について、次の人々に感謝したいと思います：デビッド・ブラッカ、ブライアン・ディクソン、ジェームズ・グールド、パウェル・コワリック、マリオ・ロフレド、ジェームズ・ミッチェル、マシュー・トーマス、ピーター・トーマス、デュアン・ウェッセルズ。
Scott Hollenbeck
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/
William Carroll
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Phone: +1 703 948-3200
Email: wicarroll@verisign.com
URI: https://verisign.com
Gautam Akiwate
Stanford University
450 Jane Stanford Way
Stanford, CA 94305
United States of America
Phone: +1 650 723-2300
Email: gakiwate@cs.stanford.edu
URI: https://cs.stanford.edu/~gakiwate/