Internet Engineering Task Force (IETF) G. Brown
Request for Comments: 9803 ICANN
Category: Standards Track June 2025
ISSN: 2070-1721
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-to-Live (TTL) value for domain name delegation records.
このドキュメントでは、EPPクライアントがドメイン名委任レコードの時間（TTL）値を管理できるようにする拡張可能なプロビジョニングプロトコル（EPP）の拡張について説明します。
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/rfc9803.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9803で取得できます。
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
1.1. Conventions Used in This Document
1.2. Extension Elements
1.2.1. The <ttl:ttl> Element
1.2.1.1. Element Content
1.2.1.2. Supported DNS Record Types
1.2.1.3. The <ttl:info> Element
1.2.2. Examples
1.2.2.1. Explicit TTL Value (<create> or <update> Command)
1.2.2.2. Explicit TTL Value (<info> Policy Mode)
1.2.2.3. Empty Value Indicating Default TTL (<create> or
<update> Command, <info> Default Mode)
1.2.2.4. Custom Record Type (<create> or <update> Command,
<info> Default Mode)
2. EPP Command Mapping
2.1. EPP Query Commands
2.1.1. EPP <info> Command
2.1.1.1. Default Mode
2.1.1.2. Policy Mode
2.2. EPP Transform Commands
2.2.1. EPP <create> Command
2.2.2. EPP <update> Command
3. Server Processing of TTL Values
3.1. Permitted Record Types
3.2. Use of TTL Values in Delegation Records
4. Out-of-Band Changes to TTL Values
5. Operational Considerations
5.1. Operational Impact of TTL Values
5.2. When TTL Values Should Be Changed
5.3. Changes to Server Policy
6. Security Considerations
6.1. Fast Flux DNS
6.2. Compromised User Accounts
7. IANA Considerations
7.1. XML Namespace
7.2. EPP Extension Registry
8. Formal Syntax
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Author's Address
The principal output of any domain name registry system is a DNS zone file, which contains the delegation record(s) for names registered within a zone (such as a top-level domain). These records typically include one or more NS records, but may also include DS records for domains secured with DNSSEC [RFC9364], and DNAME records for Internationalized Domain Name (IDN) variants [RFC6927]. A and/or AAAA records may also be published for nameservers where they are required by DNS resolvers to avoid an infinite loop.
ドメイン名レジストリシステムの主要な出力は、ゾーン内（トップレベルドメインなど）内に登録されている名前の委任レコードを含むDNSゾーンファイルです。これらのレコードには通常、1つ以上のNSレコードが含まれますが、DNSSEC [RFC9364]で保護されたドメインのDSレコード、および国際化ドメイン名（IDN）バリアントのDNAMEレコード[RFC6927]も含まれる場合があります。Aおよび/またはAAAAレコードは、無限のループを避けるためにDNSリゾルバーが必要とする名前サーバー向けに公開される場合があります。
Typically, the Time-to-Live (TTL) value (see Section 5 of [RFC9499]) of these records is determined by the registry operator. However, in some circumstances it may be desirable to allow the sponsoring client of a domain name to change the TTL values used for that domain's delegation: for example, to reduce the amount of time required to complete a change of DNS servers, DNSSEC deployment or key rollover, or to allow for fast rollback of such changes.
通常、これらのレコードの時間（TTL）値（[RFC9499]のセクション5を参照）は、レジストリ演算子によって決定されます。ただし、状況によっては、ドメイン名のスポンサークライアントがそのドメインの代表団に使用されるTTL値を変更できるようにすることが望ましい場合があります。たとえば、DNSサーバー、DNSEC展開またはキーロールオーバーの変更を完了するために必要な時間を短縮するか、そのような変更の高速ロールバックを許可することです。
This document describes an EPP extension to the domain name and host object mappings (described in [RFC5731] and [RFC5732], respectively) that allows the sponsor of a domain name or host object to change the TTL values of the resource record(s) associated with that object. It also describes how EPP servers should handle TTLs specified by EPP clients and how both parties coordinate to manage TTL values in response to changes in operational or security requirements.
このドキュメントでは、ドメイン名とホストオブジェクトのマッピング（それぞれ[RFC5731]と[RFC5732]で説明されている）へのEPP拡張機能について説明します。また、EPPサーバーがEPPクライアントによって指定されたTTLをどのように処理するか、および運用またはセキュリティ要件の変更に応じてTTL値を管理するために両方の当事者がどのように調整するかについても説明します。
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] で説明されているように解釈されます。
In this document's examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in these examples are provided only to illustrate element relationships and are not required features of this protocol.
このドキュメントの例では、「C：」はプロトコルクライアントによって送信された行と「S：」を表し、プロトコルサーバーによって返される行を表します。これらの例のインデンテーションと空白は、要素の関係を説明するためにのみ提供され、このプロトコルの必要な機能ではありません。
A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout this document.
既存のオブジェクトを管理する権限があるプロトコルクライアントは、このドキュメント全体で「スポンサー」クライアントとして説明されます。
XML is case sensitive. Unless stated otherwise, the XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
XMLはケースに敏感です。特に明記しない限り、このドキュメントで提供されているXML仕様と例は、適合実装を開発するために提示されたキャラクターケースで解釈する必要があります。
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.
EPPはXML名空間を使用して、拡張可能なオブジェクト管理フレームワークを提供し、XMLインスタンスの解析と検証に必要なスキーマを特定します。これらの名前空間とスキーマ定義は、管理されたオブジェクトのベースプロトコルスキーマとスキーマの両方を識別するために使用されます。
The XML namespace prefixes used in these examples (such as the string ttl in ttl:create) are solely for illustrative purposes. A conforming implementation MUST NOT require the use of these or any other specific namespace prefixes.
これらの例で使用されているXMLネームスペースプレフィックス（TTL：作成の文字列TTLなど）は、単に実証的な目的のためです。適合実装では、これらまたは他の特定の名前空間プレフィックスを使用する必要はありません。
In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes [XSD-DATATYPES], the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'. Implementations MUST support both styles of lexical representation.
XMLスキーマパート2のセクション3.2.2.1：データ型[XSD-DATATYPES]に従って、XS：Boolean Datatypeの許容される語彙表現は、概念「False」の文字列「0」と「False」と「1」と「True」の「True」の「True」です。実装は、両方のスタイルの語彙表現をサポートする必要があります。
This extension adds additional elements to the EPP domain and host mappings.
この拡張機能は、EPPドメインとホストマッピングに追加の要素を追加します。
The <ttl:ttl> element is used to define TTL values for the DNS resource records associated with domain and host objects.
<TTL：TTL>要素は、ドメインおよびホストオブジェクトに関連付けられたDNSリソースレコードのTTL値を定義するために使用されます。
<ttl:ttl> elements have the optional following attributes, depending on whether they appear in an EPP command or response:
<TTL：TTL>要素には、EPPコマンドまたは応答に表示されるかどうかに応じて、オプションの次の属性があります。
"for"
"のために"
REQUIRED in both commands and responses, and specifies the DNS record type to which the TTL value pertains. This attribute MUST have one of the following values: "NS", "DS", "DNAME", "A", "AAAA" or "custom".
コマンドと応答の両方で必要であり、TTL値が関係するDNSレコードタイプを指定します。この属性には、「ns」、「ds」、「dname」、 "a"、 "aaaa"または "custom"のいずれかの値のいずれかが必要です。
"custom"
"カスタム"
If the value of the "for" attribute is "custom", then the <ttl:ttl> element MUST also have a "custom" attribute containing a DNS record type conforming with the regular expression in Section 3.1 of [RFC6895]. Additionally, the record type MUST be registered with IANA in [IANA-RRTYPES].
「for」属性の値が「カスタム」である場合、<ttl：ttl>要素には、[RFC6895]のセクション3.1の正規式に準拠したDNSレコードタイプを含む「カスタム」属性も必要です。さらに、レコードタイプは[IANA-rrtypes]でIANAに登録する必要があります。
"min"
「分」
MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is used by the server to indicate the lowest value that may be set.
EPPコマンドに存在してはなりませんが、EPP応答に存在する場合があります（セクション2.1.1を参照）。サーバーは、設定される可能性のある最低値を示すために使用されます。
"default"
"デフォルト"
MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is used by the server to indicate the default value.
EPPコマンドに存在してはなりませんが、EPP応答に存在する場合があります（セクション2.1.1を参照）。デフォルト値を示すためにサーバーによって使用されます。
"max"
「マックス」
MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is used by the server to indicate the highest value that may be set.
EPPコマンドに存在してはなりませんが、EPP応答に存在する場合があります（セクション2.1.1を参照）。サーバーは、設定される可能性のある最高の値を示すために使用されます。
When present, the value of the "min" attribute MUST be lower than the value of the "max" attribute. The "default" attribute MUST be between the "min" and "max" values, inclusively.
存在する場合、「min」属性の値は「max」属性の値よりも低くなければなりません。「デフォルト」属性は、「最小」値と「最大」値の間で包括的に必要です。
The XML schema found in Section 8 of this document restricts the content of <ttl:ttl> elements to be either:
このドキュメントのセクション8にあるXMLスキーマは、<TTL：TTL>要素の内容を次のように制限しています。
1. a non-negative integer, indicating the value of the TTL in seconds, or
1. 秒単位でTTLの値を示す非陰性整数、または
2. empty, in which case the server's default TTL for the given record type is to be applied.
2. 空です。その場合、指定されたレコードタイプのサーバーのデフォルトTTLが適用されます。
To facilitate forward compatibility with future changes to the DNS protocol, this document does not enumerate or restrict the DNS record types that can be included in the "custom" attribute of the <ttl:ttl> element.
DNSプロトコルの将来の変更との転送互換性を促進するために、このドキュメントは、<TTL：TTL>要素の「カスタム」属性に含めることができるDNSレコードタイプを列挙または制限しません。
The regular expression that is used to validate the values of the "custom" attribute is based on the expression found in Section 3.1 of [RFC6895], and it is intended to match both existing and future RRTYPE mnemonics. This eliminates the need to update this document in the event that new DNS records that exist above a zone cut (Section 7 of [RFC9499]) are specified.
「カスタム」属性の値を検証するために使用される正規表現は、[RFC6895]のセクション3.1にある式に基づいており、既存と将来のRRTYPEニーモニックの両方に一致することを目的としています。これにより、ゾーンカット（[RFC9499]のセクション7）の上に存在する新しいDNSレコードが指定されている場合、このドキュメントを更新する必要性がなくなります。
Nevertheless, EPP servers that implement this extension MUST restrict the DNS record types that are accepted in <create> and <update> commands, and included in <info> responses, allowing only those types that are (a) registered in [IANA-RRTYPES] and (b) appropriate for use above a zone cut.
それにもかかわらず、この拡張機能を実装するEPPサーバーは、<create>および<update>コマンドで受け入れられ、<情報>応答に含まれるDNSレコードタイプを制限する必要があります。
A server that receives a <create> or <update> command that attempts to set TTL values for inapplicable DNS record types MUST respond with a 2306 "Parameter value policy" error.
Applable DNSレコードタイプのTTL値を設定しようとする<create>または<update>コマンドを受信するサーバーは、2306の「パラメーター値ポリシー」エラーで応答する必要があります。
As an illustrative example, a server MAY allow clients to specify TTL values for the following record types for domain objects:
例として、サーバーは、クライアントがドメインオブジェクトの次のレコードタイプのTTL値を指定できるようにする場合があります。
1. NS;
1. ns;
2. DS (if the server also implements [RFC5910]);
2. DS（サーバーも[RFC5910]を実装している場合）;
3. DNAME (if the server implements IDN variants using DNAME records).
3. DNAME（サーバーがDNAMEレコードを使用してIDNバリアントを実装する場合）。
Glue records are described in Section 7 of [RFC9499].
接着剤の記録は、[RFC9499]のセクション7で説明されています。
Servers that implement host objects [RFC5732] MAY allow clients to specify TTL values for A and AAAA records for host objects.
ホストオブジェクトを実装するサーバー[RFC5732]により、クライアントはホストオブジェクトのAおよびAAAAレコードのTTL値を指定できる場合があります。
A server supporting host objects that receives a command that attempts to set TTL values for A and AAAA records on a domain object MUST respond with a 2306 "Parameter value policy" error.
ドメインオブジェクト上のAおよびAAAAレコードのTTL値を設定しようとするコマンドを受信するホストオブジェクトをサポートするサーバーは、2306「パラメーター値ポリシー」エラーで応答する必要があります。
EPP servers that use the host attribute model (described in Section 1.1 of [RFC5731]) MAY allow clients to specify TTL values for A and AAAA records for domain objects.
ホスト属性モデル（[RFC5731]のセクション1.1で説明）を使用するEPPサーバーは、クライアントがドメインオブジェクトのAおよびAAAAレコードのTTL値を指定できるようにすることができます。
The <ttl:info> element is used by clients to request that the server include additional information in <info> responses for domain and host objects.
<ttl：info>要素は、クライアントがサーバーにドメインおよびホストオブジェクトの応答に追加情報を含めることを要求するために使用されます。
It has a single OPTIONAL "policy" attribute, which takes a boolean value with a default value of "false".
単一のオプションの「ポリシー」属性があり、「false」のデフォルト値でブール値を取得します。
The semantics of this element are described in Section 2.1.1.
この要素のセマンティクスは、セクション2.1.1で説明されています。
Below is an example of a <ttl:info> element with an explicit "policy" attribute:
以下は、明示的な「ポリシー」属性を持つ<ttl：info>要素の例です。
<ttl:info policy="true"/>
<ttl:ttl for="NS">3600</ttl:ttl>
<ttl:ttl
for="NS"
min="60"
default="86400"
max="172800">3600</ttl:ttl>
<ttl:ttl for="NS"/>
<ttl:ttl
for="custom"
custom="NEWRRTYPE">3600</ttl:ttl>
This extension defines an additional element for EPP <info> commands and responses for domain and host objects.
この拡張機能は、epp <情報>コマンドの追加要素とドメインおよびホストオブジェクトの応答を定義します。
The EPP <info> command is extended to support two different modes:
EPP <info>コマンドは、2つの異なるモードをサポートするために拡張されます。
1. The Default Mode (Section 2.1.1.1), which requests the inclusion of all non-default TTL values in the response; and
1. デフォルトモード（セクション2.1.1.1）は、応答にすべての非デフォルトTTL値を含めることを要求します。そして
2. The Policy Mode (Section 2.1.1.2), which requests the inclusion of TTL information for all supported DNS record types in the response, along with the minimum, default, and maximum values for those records.
2. ポリシーモード（セクション2.1.1.2）は、これらのレコードの最小値、デフォルト、および最大値とともに、応答でサポートされているすべてのDNSレコードタイプにTTL情報を含めることを要求します。
If a server receives an <info> command for a domain or host object that includes a <ttl:info> element with a "policy" attribute that is "0" or "false", then the EPP response MUST contain <ttl:ttl> records for all DNS record types that have non-default TTL values. These elements MUST NOT have the "min", "default", and "max" attributes.
サーバーが、「0」または「false」である「ポリシー」属性を持つ<ttl：info>要素を含むドメインまたはホストオブジェクトの<情報>コマンドを受信する場合、EPP応答には、非デフォルトTTL値を持つすべてのDNSレコードタイプの<TTL：TTL>レコードを含める必要があります。これらの要素には、「最小」、「デフォルト」、および「最大」属性を備えてはなりません。
Below is an example domain <info> command with a <ttl:info> element with a "policy" attribute that is "false":
以下は、「false」の「ポリシー」属性を持つ<ttl：info>要素を持つドメイン<情報>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:info>
C: </info>
C: <extension>
C: <ttl:info
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
C: policy="false"/>
C: </extension>
C: </command>
C: </epp>
Below is an example domain <info> response to a command with a <ttl:info> element with a "policy" attribute that is "false":
以下は、「false」である「ポリシー」属性を持つ<ttl：info>要素を使用してコマンドに対するドメイン<情報>の応答の例です。
S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns1.example.net</domain:hostObj>
S: </domain:ns>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientX</domain:crID>
S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>
S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>
S: </domain:infData>
S: </resData>
S: <extension>
S: <ttl:infData
S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
S: <ttl:ttl for="NS">172800</ttl:ttl>
S: <ttl:ttl for="DS">300</ttl:ttl>
S: </ttl:infData>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>13</secDNS:alg>
S: <secDNS:digestType>2</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
Below is an example host <info> command with a <ttl:info> element with a "policy" attribute that is "false":
以下は、「false」の「ポリシー」属性を持つ<ttl：info>要素を持つホスト<情報>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <host:info
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:info>
C: </info>
C: <extension>
C: <ttl:info
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
C: policy="false"/>
C: </extension>
C: </command>
C: </epp>
Below is an example host <info> response to a command with a <ttl:info> element with a "policy" attribute that is "false":
以下は、「false」である「ポリシー」属性を持つ<ttl：info>要素を使用して、コマンドへのホスト<情報>応答の例です。
S: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:infData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
S: <host:status s="ok"/>
S: <host:addr ip="v4">192.0.2.2</host:addr>
S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
S: <host:clID>ClientX</host:clID>
S: <host:crID>ClientX</host:crID>
S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>
S: </host:infData>
S: </resData>
S: <extension>
S: <ttl:infData
S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
S: <ttl:ttl for="A">172800</ttl:ttl>
S: <ttl:ttl for="AAAA">86400</ttl:ttl>
S: </ttl:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
If a server receives an <info> command for a domain or host object that includes a <ttl:info> element with a "policy" attribute that is "1" or "true", then the EPP response MUST contain <ttl:ttl> records for all supported DNS record types, irrespective of whether those record types are actually in use by the object in question. These elements MUST have the "min", "default", and "max" attributes.
サーバーが、「1」または「true」である「ポリシー」属性を持つ<ttl：info>要素を含むドメインまたはホストオブジェクトの<情報>コマンドを受信した場合、EPP応答には、これらのレコードタイプが実際に問題に使用されているかどうかに関係なく、サポートされているすべてのDNSレコードタイプの<TTL：TTL>レコードを含める必要があります。これらの要素には、「最小」、「デフォルト」、および「最大」属性が必要です。
Below is an example domain <info> command requesting the server policies:
以下は、サーバーポリシーを要求するドメイン<情報>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:info>
C: </info>
C: <extension>
C: <ttl:info
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
C: policy="true"/>
C: </extension>
C: </command>
C: </epp>
Below is an example domain <info> response providing the server policies:
以下は、サーバーポリシーを提供するドメイン<情報>応答の例です。
S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns1.example.net</domain:hostObj>
S: </domain:ns>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientX</domain:crID>
S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>
S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>
S: </domain:infData>
S: </resData>
S: <extension>
S: <ttl:infData
S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
S: <ttl:ttl for="NS"
S: min="3600"
S: default="86400"
S: max="172800">172800</ttl:ttl>
S: <ttl:ttl for="DS"
S: min="60"
S: default="86400"
S: max="172800">300</ttl:ttl>
S: </ttl:infData>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>13</secDNS:alg>
S: <secDNS:digestType>2</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
Below is an example host <info> command requesting the server policies:
以下は、サーバーポリシーを要求するホスト<情報>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <host:info
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:info>
C: </info>
C: <extension>
C: <ttl:info
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
C: policy="true"/>
C: </extension>
C: </command>
C: </epp>
Below is an example host <info> response providing the server policies:
以下は、サーバーポリシーを提供するホスト<情報>応答の例です。
S: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:infData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
S: <host:status s="ok"/>
S: <host:addr ip="v4">192.0.2.2</host:addr>
S: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
S: <host:clID>ClientX</host:clID>
S: <host:crID>ClientX</host:crID>
S: <host:crDate>2023-11-08T10:14:55.0Z</host:crDate>
S: </host:infData>
S: </resData>
S: <extension>
S: <ttl:infData
S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
S: <ttl:ttl for="A"
S: min="3600"
S: default="86400"
S: max="172800">172800</ttl:ttl>
S: <ttl:ttl for="AAAA"
S: min="3600"
S: default="86400"
S: max="172800">86400</ttl:ttl>
S: </ttl:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
This extension defines an additional element for EPP <create> commands for domain and host objects.
この拡張機能は、ドメインおよびホストオブジェクトのEPP <Create>コマンドの追加要素を定義します。
The <command> element of the <create> command MAY contain an <extension> element that MAY contain a <ttl:create> element. This element MUST contain one or more <ttl:ttl> records as described in Section 1.2.
<create>コマンドの<command>要素には、<ttl：create>要素を含む可能性のある<extension>要素を含めることができます。この要素には、セクション1.2で説明されているように、1つ以上の<TTL：TTL>レコードを含める必要があります。
If an EPP server receives a <create> command containing a TTL value that is outside the server's permitted range, it MUST reject the command with a 2004 "Parameter value range error" response.
EPPサーバーが、サーバーの許可範囲の外側にあるTTL値を含む<Create>コマンドを受信した場合、2004年の「パラメーター値範囲エラー」応答でコマンドを拒否する必要があります。
Below is an example domain <create> command:
以下は、ドメイン<create>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">1</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns1.example.net</domain:hostObj>
C: </domain:ns>
C: <domain:authInfo>
C: <domain:pw/>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <ttl:create
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
C: <ttl:ttl for="NS">172800</ttl:ttl>
C: <ttl:ttl for="DS">300</ttl:ttl>
C: </ttl:create>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>13</secDNS:alg>
C: <secDNS:digestType>2</secDNS:digestType>
C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C: </epp>
Below is an example host <create> command:
以下はhost <create>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <host:create
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:addr ip="v4">192.0.2.2</host:addr>
C: <host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr>
C: </host:create>
C: </create>
C: <extension>
C: <ttl:create
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
C: <ttl:ttl for="A"/>
C: <ttl:ttl for="AAAA">86400</ttl:ttl>
C: </ttl:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C: </epp>
This extension defines an additional element for EPP <update> commands for domain and host objects.
この拡張機能は、ドメインおよびホストオブジェクトのEPP <update>コマンドの追加要素を定義します。
The <command> element of the <update> command MAY contain an <extension> element that MAY contain a <ttl:update> element. This element MUST contain one or more <ttl:ttl> records as described in Section 1.2.
<patdent>コマンドの<command>要素には、<ttl：update>要素を含む可能性のある<extension>要素を含めることができます。この要素には、セクション1.2で説明されているように、1つ以上の<TTL：TTL>レコードを含める必要があります。
If an EPP server receives an <update> command containing a TTL value that is outside the server's permitted range, it MUST reject the command with a 2004 "Parameter value range error" response.
EPPサーバーが、サーバーの許可範囲外のTTL値を含む<update>コマンドを受信した場合、2004年の「パラメーター値範囲エラー」応答でコマンドを拒否する必要があります。
Below is an example domain <update> command:
以下は、domain <update>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <ttl:update
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
C: <ttl:ttl for="NS"/>
C: <ttl:ttl for="custom"
C: custom="DELEG"/>
C: <ttl:ttl for="DS">86400</ttl:ttl>
C: </ttl:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C: </epp>
Below is an example host <update> command:
以下は、host <update>コマンドの例です。
C: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <host:update
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:update>
C: </update>
C: <extension>
C: <ttl:update
C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
C: <ttl:ttl for="A">86400</ttl:ttl>
C: <ttl:ttl for="AAAA">3600</ttl:ttl>
C: </ttl:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C: </epp>
EPP servers MAY restrict the supported DNS record types. For example, a server MAY allow clients to specify TTL values for DS records only.
EPPサーバーは、サポートされているDNSレコードタイプを制限する場合があります。たとえば、サーバーは、クライアントがDSレコードのTTL値のみを指定できるようにする場合があります。
A server that receives a <create> or <update> command that includes a restricted record type MUST respond with a 2306 "Parameter value policy" error.
制限付きレコードタイプを含む<create>または<update>コマンドを受信するサーバーは、2306の「パラメーター値ポリシー」エラーで応答する必要があります。
Clients can discover the DNS record types for which an EPP server permits TTL values to be changed by performing a Policy Mode <info> command, as outlined in Section 2.1.1.2.
クライアントは、セクション2.1.1.2で概説されているように、ポリシーモード<情報>コマンドを実行することにより、EPPサーバーがTTL値を変更することを許可するDNSレコードタイプを発見できます。
EPP servers that implement this extension SHOULD use the values provided by EPP clients for the TTL values of records published in the DNS for domain and (if supported) host objects. Server operators MAY disregard these values in order to address security and stability issues, as described in Section 5 and Section 6.
この拡張機能を実装するEPPサーバーは、DNS for Domainおよび（サポートされている場合）ホストオブジェクトに公開されたレコードのTTL値に対して、EPPクライアントが提供する値を使用する必要があります。セクション5およびセクション6で説明されているように、サーバーオペレーターは、セキュリティと安定性の問題に対処するためにこれらの値を無視する場合があります。
EPP servers that use the host attribute model SHOULD use any NS, A, and/or AAAA TTL values specified for the domain object when publishing NS, A, and/or AAAA records derived from host attributes.
ホスト属性モデルを使用するEPPサーバーは、ホスト属性から派生したNS、A、および/またはAAAAレコードを公開するときに、ドメインオブジェクトに指定されたNS、A、および/またはAAAA TTL値を使用する必要があります。
In order to address operational or security issues, EPP server operators MAY make changes to TTL values out-of-band (that is, not in response to an <update> command received from the sponsoring client).
運用上またはセキュリティの問題に対処するために、EPPサーバーオペレーターは、TTL値に変更を加えることができます（つまり、スポンサークライアントから受信した<update>コマンドに応じてではありません）。
Server operators MAY also implement automatic reset of TTL values, so that they revert to the default value a certain amount of time after an update has been made.
サーバーオペレーターは、TTL値の自動リセットを実装する場合があります。そのため、更新が行われた後、一定の時間にデフォルト値に戻ることができます。
If a TTL value is changed out-of-band, EPP server operators MAY notify the sponsoring client using the EPP Change Poll Extension [RFC8590], which provides a generalized method for EPP servers to notify clients of changes to objects under their sponsorship.
TTL値がバンド外で変更された場合、EPPサーバーオペレーターは、EPP変更ポーリング拡張[RFC8590]を使用してスポンサークライアントに通知する場合があります。
Registry operators must consider the balance between registrants' desire for changes to domains to be visible in the DNS quickly, and the increased DNS query traffic that short TTLs can bring.
レジストリオペレーターは、DNSでドメインへの変更に対する登録者の要望と、短いTTLがもたらす可能性のあるトラフィックをクエリクエリクエリすることのバランスを考慮する必要があります。
Registry operators SHOULD implement limits on the maximum and minimum accepted TTL values that are narrower than the values permitted in the XML schema in Section 8 (which were chosen to allow any TTL permitted in DNS records). This is in order to prevent scenarios where an excessively high or low TTL causes operational issues on either side of the zone cut.
レジストリオペレーターは、セクション8のXMLスキーマで許可されている値（DNSレコードで許可されるように選択された）よりも狭い最大および最小の受容されるTTL値に制限を実装する必要があります。これは、ゾーンカットの両側にTTLが過度に高いまたは低いものが運用上の問題を引き起こすシナリオを防ぐためです。
Section 4 describes how server operators MAY unilaterally change TTL values in order to address operational or security issues, or only permit changes for limited time periods (after which TTLs revert to the default).
セクション4では、サーバーオペレーターが運用上またはセキュリティの問題に対処するためにTTL値を一方的に変更する方法、または限られた期間の変更のみを許可する方法について説明します（TTLがデフォルトに戻る後）。
A common operational mistake is changing the DNS record TTLs during or after the planned change to the records themselves. This arises due to a misunderstanding about how TTLs work.
一般的な運用上の間違いは、レコード自体に計画された変更中または変更後にDNSレコードTTLを変更することです。これは、TTLがどのように機能するかについての誤解のために発生します。
It is RECOMMENDED that guidance be provided to users so they are aware that changes to a TTL are only effective in shortening transition periods if implemented a period of time (at least equal to the current TTL) _before_ the planned change. The latency between receipt of the <update> command and the actual publication of the changes in the DNS should also be taken into consideration in this calculation.
ユーザーにガイダンスを提供することをお勧めします。これにより、TTLの変更は、期間（少なくとも現在のTTLに等しい）_BeFore_計画変更を実装した場合にのみ遷移期間を短縮するのに効果的であることを認識することをお勧めします。<update>コマンドの受領とDNSの変更の実際の公開の間の遅延も、この計算で考慮する必要があります。
Registry operators may change their policies relating to TTL values from time to time. Previously configured TTL values may consequently fall outside a newly applied policy. This document places no obligation on EPP server operators in respect of these values, and server operators may, as part of a policy change, change the TTL values specified by clients for domain and host objects. Section 4 describes how such out-of-band changes should be carried out.
レジストリオペレーターは、TTL値に関連するポリシーを随時変更する場合があります。したがって、以前に構成されていたTTL値は、新たに適用されたポリシーの外に収まる可能性があります。このドキュメントは、これらの値に関してEPPサーバーオペレーターに義務を負わず、サーバーオペレーターは、ポリシーの変更の一部として、ドメインおよびホストオブジェクトに対してクライアントが指定したTTL値を変更する場合があります。セクション4では、このような帯域外の変更を実行する方法について説明します。
Some malicious actors use a technique called "fast flux DNS" [SAC-025] to rapidly change the DNS configuration for a zone in order to evade takedown and law enforcement activity. Server operators should take this into consideration when setting the lower limit on TTL values, since a short TTL on delegations may enhance the effectiveness of fast flux techniques on evasion.
一部の悪意のある俳優は、「Fast Flux DNS」[SAC-025]と呼ばれる手法を使用して、テイクダウンと法執行活動を回避するためにゾーンのDNS構成を迅速に変更します。TTL値に下限を設定するときは、サーバーオペレーターがこれを考慮に入れる必要があります。なぜなら、代表団の短いTTLは回避に対する高速フラックス技術の有効性を高める可能性があるためです。
Client implementations that provide an interface for customers to configure TTL values for domain names should consider implementing controls to deter and mitigate abusive behavior, such as those outlined in the "Current and Possible Mitigation Alternatives" section of [SAC-025].
顧客がドメイン名のTTL値を構成するためのインターフェイスを提供するクライアントの実装は、[SAC-025]の「現在および可能な緩和の代替」セクションに概説されているような、虐待的な動作を阻止および緩和するためのコントロールの実装を検討する必要があります。
An attacker who obtains access to a customer account at a domain registrar that supports this extension could make unauthorized changes to the NS and/or glue records for a domain, and then increase the associated TTLs so that the changes persist in caches for a long time after the attack has been detected.
この拡張機能をサポートするドメインレジストラで顧客アカウントへのアクセスを取得した攻撃者は、ドメインのNSおよび/または接着剤レコードに不正な変更を加え、関連するTTLを増やして、攻撃が検出されてから長時間キャッシュの変化が持続するようにする可能性があります。
Client implementations that provide an interface for customers to configure TTL values for domain names should consider implementing upper limits in order to reduce the impact of account compromise, in addition to best practices relating to credential management, multi-factor authentication, risk-based access control, and so on.
ドメイン名のTTL値を構成するためのインターフェイスを提供するクライアントの実装は、資格管理、多要素認証、リスクベースのアクセス制御などに関連するベストプラクティスに加えて、アカウントの妥協の影響を減らすために上限の実装を検討する必要があります。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. The following URI assignments have been made by IANA:
このドキュメントでは、URNSを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠したXMLネームスペースとXMLスキーマを記述します。次のURI割り当てはIANAによって行われました。
Registration for the TTL namespace:
TTLネームスペースの登録：
URI:
URI:
urn:ietf:params:xml:ns:epp:ttl-1.0
urn：ietf：params：xml：ns：epp：ttl-1.0
Registrant Contact:
登録者の連絡先：
IESG
iesg
XML:
XML:
None. Namespace URIs do not represent an XML specification.
なし。名前空間URIはXML仕様を表していません。
Registration for the TTL XML schema:
TTL XMLスキーマの登録：
URI:
URI:
urn:ietf:params:xml:schema:epp:ttl-1.0
urn：ietf：params：xml：schema：epp：ttl-1.0
Registrant Contact:
登録者の連絡先：
IESG
iesg
XML:
XML:
See Section 8 of this document.
このドキュメントのセクション8を参照してください。
The EPP extension described in this document has been registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows:
このドキュメントで説明されているEPP拡張機能は、[RFC7451]で説明されている「拡張可能なプロビジョニングプロトコル（EPP）の拡張（EPP）」レジストリにIANAによって登録されています。登録の詳細は次のとおりです。
Name of Extension:
拡張機能の名前：
Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values
拡張可能なプロビジョニングプロトコル（EPP）DNSの時間式（TTL）値のマッピング
Document Status:
ドキュメントステータス：
Standards Track
標準追跡
Reference:
参照：
RFC 9803
RFC 9803
Registrant:
登録者：
IESG
iesg
TLDs:
TLDS：
Any
どれでも
IPR Disclosure:
IPR開示：
None
なし
Status:
状態：
Active
アクティブ
Notes:
注：
None
なし
The formal syntax presented here is a complete schema representation of the extension suitable for automated validation of EPP XML instances.
ここに示されている正式な構文は、EPP XMLインスタンスの自動検証に適した拡張機能の完全なスキーマ表現です。
<?xml version="1.0" encoding="UTF-8"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:epp:ttl-1.0"
xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0 extension
schema for Time-to-Live (TTL) Values for domain
and host objects.
</documentation>
</annotation>
<element name="info">
<complexType>
<attribute name="policy" type="boolean" default="false"/>
</complexType>
</element>
<!--
<ttl> elements can appear in <create> and
<update> commands, and <info> responses
-->
<element name="create" type="ttl:commandContainer">
<unique name="uniqueRRTypeForCreate">
<selector xpath="ttl:ttl"/>
<field xpath="@for"/>
</unique>
</element>
<element name="update" type="ttl:commandContainer">
<unique name="uniqueRRTypeForUpdate">
<selector xpath="ttl:ttl"/>
<field xpath="@for"/>
</unique>
</element>
<element name="infData" type="ttl:responseContainer">
<unique name="uniqueRRTypeForInfo">
<selector xpath="ttl:ttl"/>
<field xpath="@for"/>
</unique>
</element>
<complexType name="commandContainer">
<sequence>
<element
name="ttl"
type="ttl:commandTTLType"
minOccurs="1"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="responseContainer">
<sequence>
<element
name="ttl"
type="ttl:responseTTLType"
minOccurs="1"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="commandTTLType">
<simpleContent>
<extension base="ttl:ttlOrNull">
<attribute
name="for"
type="ttl:rrType"
use="required"/>
<attribute
name="custom"
type="ttl:customRRType"/>
</extension>
</simpleContent>
</complexType>
<complexType name="responseTTLType">
<simpleContent>
<extension base="ttl:ttlOrNull">
<attribute
name="for"
type="ttl:rrType"
use="required"/>
<attribute
name="custom"
type="ttl:customRRType"/>
<attribute
name="min"
type="ttl:ttlValue"/>
<attribute
name="default"
type="ttl:ttlValue"/>
<attribute
name="max"
type="ttl:ttlValue"/>
</extension>
</simpleContent>
</complexType>
<!--
union type allowing the element to either contain
nothing or a TTL value
-->
<simpleType name="ttlOrNull">
<union
memberTypes="ttl:emptyValue ttl:ttlValue"/>
</simpleType>
<!-- empty value type -->
<simpleType name="emptyValue">
<restriction base="token">
<length value="0"/>
</restriction>
</simpleType>
<!-- TTL value type -->
<simpleType name="ttlValue">
<restriction base="nonNegativeInteger">
<minInclusive value="0"/>
<maxInclusive value="2147483647"/>
</restriction>
</simpleType>
<!-- resource record mnemonic type -->
<simpleType name="rrType">
<restriction base="token">
<enumeration value="NS" />
<enumeration value="DS" />
<enumeration value="DNAME" />
<enumeration value="A" />
<enumeration value="AAAA" />
<enumeration value="custom" />
</restriction>
</simpleType>
<!-- custom resource record type -->
<simpleType name="customRRType">
<restriction base="token">
<pattern value="A|[A-Z][A-Z0-9\-]*[A-Z0-9]"/>
</restriction>
</simpleType>
</schema>
[IANA-RRTYPES]
IANA, "Resource Record (RR) TYPEs",
<https://www.iana.org/assignments/dns-parameters>.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910,
DOI 10.17487/RFC5910, May 2010,
<https://www.rfc-editor.org/info/rfc5910>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[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>.
[XSD-DATATYPES]
Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2:
Datatypes Second Edition", W3C Recommendation, October
2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
Latest version available at
<https://www.w3.org/TR/xmlschema-2/>.
[RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names
Registered in Top-Level Domains", RFC 6927,
DOI 10.17487/RFC6927, May 2013,
<https://www.rfc-editor.org/info/rfc6927>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[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>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[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>.
[SAC-025] ICANN Security and Stability Advisory Committee (SSAC),
"SSAC Advisory on Fast Flux Hosting and DNS", SAC 025,
January 2008,
<https://www.icann.org/en/system/files/files/sac-
025-en.pdf>.
The author wishes to thank the following people for their advice and feedback during the development of this document:
著者は、このドキュメントの開発中に、次の人々にアドバイスとフィードバックに感謝したいと考えています。
* James Gould
* ジェームズ・グールド
* Hugo Salgado
* ヒューゴ・サルガド
* Patrick Mevzek
* パトリック・メフェク
* Rick Wilhelm
* リック・ウィルヘルム
* Marc Groeneweg
* Marc GroEneweg
* Ties de Kock
* デ・コックを結びつける
* Tim Wicinski
* ティム・ウィシンスキー
* Jasdip Singh
* Jasdip Singh
Gavin Brown
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90292
United States of America
Email: gavin.brown@icann.org
URI: https://www.icann.org/