[要約] RFC 7477は、DNSにおける子から親への同期に関する要約であり、DNS階層の同期を改善するためのガイドラインを提供します。目的は、DNS階層の同期を効率化し、データの整合性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 7477 Parsons, Inc.
Category: Standards Track March 2015
ISSN: 2070-1721
Child-to-Parent Synchronization in DNS
DNSでの子から親への同期
Abstract
概要
This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.
このドキュメントでは、DNSの子ゾーンがレコードを発行して、親エージェントが子ゾーンから特定のレコードをコピーして処理できることを親エージェントに示す方法を指定します。レコードの存在とその値の変更は、親エージェントによって監視され、ローカルポリシーに応じて対処できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7477.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7477で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology Used in This Document ..........................3
2. Definition of the CSYNC RRType ..................................3
2.1. The CSYNC Resource Record Format ...........................4
2.1.1. The CSYNC Resource Record Wire Format ...............4
2.1.2. The CSYNC Presentation Format .......................6
2.1.3. CSYNC RR Example ....................................6
3. CSYNC Data Processing ...........................................6
3.1. Processing Procedure .......................................7
3.2. CSYNC Record Types .........................................8
3.2.1. The NS type .........................................8
3.2.2. The A and AAAA Types ................................9
4. Operational Considerations ......................................9
4.1. Error Reporting ...........................................10
4.2. Child Nameserver Selection ................................10
4.3. Out-of-Bailiwick NS Records ...............................10
4.4. Documented Parental Agent Type Support ....................11
4.5. Removal of the CSYNC Records ..............................11
4.6. Parent/Child/Grandchild Glue Synchronization ..............12
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgments ...................................................15
Author's Address ..................................................15
This document specifies how a child zone in the DNS ([RFC1034] [RFC1035]) can publish a record to indicate to a parental agent (see Section 1.1 for a definition of "parental agent") that it can copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.
このドキュメントは、DNSの子ゾーン（[RFC1034] [RFC1035]）がレコードを発行して、親エージェント（「親エージェント」の定義についてはセクション1.1を参照）に特定のレコードをコピーおよび処理できることを示す方法を指定します子ゾーン。レコードの存在とその値の変更は、親エージェントによって監視され、ローカルポリシーに応じて対処できます。
Currently, some resource records (RRs) in a parent zone are typically expected to be in sync with the source data in the child's zone. The most common records that should match are the nameserver (NS) records and any necessary associated address records (A and AAAA), also known as "glue records". These records are referred to as "delegation records".
現在、親ゾーンの一部のリソースレコード（RR）は、通常、子ゾーンのソースデータと同期していると予想されます。一致する最も一般的なレコードは、ネームサーバー（NS）レコードと、必要な関連アドレスレコード（AおよびAAAA）であり、「接着レコード」とも呼ばれます。これらのレコードは「委任レコード」と呼ばれます。
It has been challenging for operators of child DNS zones to update their delegation records within the parent's set in a timely fashion. These difficulties may stem from operator laziness as well as from the complexities of maintaining a large number of DNS zones. Having an automated mechanism for signaling updates will greatly ease the child zone operator's maintenance burden and improve the robustness of the DNS as a whole.
子DNSゾーンのオペレーターが親のセット内の委任レコードをタイムリーに更新することは困難でした。これらの問題は、オペレーターの遅延と、多数のDNSゾーンを維持することの複雑さに起因する可能性があります。更新を通知するための自動化されたメカニズムがあると、子ゾーンオペレーターのメンテナンスの負担が大幅に軽減され、DNS全体の堅牢性が向上します。
This document introduces a new Resource Record Type (RRType) named "CSYNC" that indicates which delegation records published by a child DNS operator should be processed by a parental agent and used to update the parent zone's DNS data.
このドキュメントでは、「CSYNC」という名前の新しいリソースレコードタイプ（RRType）を紹介します。これは、子DNSオペレーターによって公開された委任レコードを親エージェントで処理し、親ゾーンのDNSデータの更新に使用する必要があることを示します。
This specification was not designed to synchronize DNSSEC security records, such as DS RRsets. For a solution to this problem, see the complementary solution [RFC7344], which is designed to maintain security delegation information. In addition, this specification does not address how to perform bootstrapping operations, including to get the required initial DNSSEC-secured operating environment in place.
この仕様は、DS RRsetなどのDNSSECセキュリティレコードを同期するようには設計されていません。この問題の解決策については、セキュリティ委任情報を維持するように設計された補足ソリューション[RFC7344]を参照してください。さらに、この仕様は、必要な初期DNSSECで保護されたオペレーティング環境を適切に配置することを含め、ブートストラップ操作を実行する方法については触れていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Terminology describing relationships between the interacting roles involved in this document are defined in the following list:
このドキュメントに含まれる相互作用する役割間の関係を説明する用語は、次のリストで定義されています。
Child: The entity on record that has the delegation of the domain from the parent
子：親からのドメインの委任を持つレコード上のエンティティ
Parent: The domain in which the child is registered
親：子が登録されているドメイン
Child DNS operator: The entity that maintains and publishes the zone information for the child DNS
子DNSオペレーター：子DNSのゾーン情報を維持および公開するエンティティ
Parental agent: The entity that the child has relationship with, to change its delegation information
保護者の代理人：委任情報を変更するために子供が関係しているエンティティ
The CSYNC RRType contains, in its RDATA component, these parts: an SOA serial number, a set of flags, and a simple bit-list indicating the DNS RRTypes in the child that should be processed by the parental agent in order to modify the DNS delegation records within the parent's zone for the child DNS operator. Child DNS operators wanting a parental agent to perform the synchronization steps outlined in this document MUST publish a CSYNC record at the apex of the child zone. Parental agent implementations MAY choose to query child zones for this record and process DNS record data as indicated by the Type Bit Map field in the RDATA of the CSYNC record. How the data is processed is described in Section 3.
CSYNC RRTypeのRDATAコンポーネントには、SOAシリアル番号、フラグのセット、およびDNSを変更するために親エージェントが処理する必要がある子のDNS RRTypeを示す単純なビットリストが含まれています。子DNSオペレーターの親のゾーン内の委任レコード。親エージェントにこのドキュメントで概説されている同期手順の実行を希望する子DNSオペレーターは、子ゾーンの頂点でCSYNCレコードを公開する必要があります。親エージェントの実装は、CSYNCレコードのRDATAのType Bit Mapフィールドで示されるように、このレコードの子ゾーンをクエリし、DNSレコードデータを処理することを選択できます。データの処理方法については、セクション3で説明します。
Parental agents MUST process the entire set of child data indicated by the Type Bit Map field (i.e., all record types indicated along with all of the necessary records to support processing of that type) or else parental agents MUST NOT make any changes to parental records at all. Errors due to unsupported Type Bit Map bits, or otherwise nonpunishable data, SHALL result in no change to the parent zone's delegation information for the child. Parental agents MUST ignore a child's CSYNC RDATA set if multiple CSYNC resource records are found; only a single CSYNC record should ever be present.
親エージェントは、タイプビットマップフィールドで示される子データのセット全体（つまり、そのタイプの処理をサポートするために必要なすべてのレコードとともに示されるすべてのレコードタイプ）を処理する必要があります。そうでない場合、親エージェントは親レコードを変更してはなりません。まったく。サポートされていないタイプビットマップビットまたはそれ以外の場合は罰せられないデータによるエラーは、子の親ゾーンの委任情報を変更しないものとします（SHALL）。親エージェントは、複数のCSYNCリソースレコードが見つかった場合、子のCSYNC RDATAセットを無視する必要があります。 CSYNCレコードは1つだけ存在する必要があります。
The parental agent MUST perform DNSSEC validation ([RFC4033] [RFC4034] [RFC4035]), of the CSYNC RRType data and MUST perform DNSSEC validation of any data to be copied from the child to the parent. Parents MUST NOT process any data from any of these records if any of the validation results indicate anything other than "Secure" [RFC4034] or if any the required data cannot be successfully retrieved.
親エージェントは、CSYNC RRTypeデータのDNSSEC検証（[RFC4033] [RFC4034] [RFC4035]）を実行する必要があり、子から親にコピーされるデータのDNSSEC検証を実行する必要があります。検証結果のいずれかが「セキュア」[RFC4034]以外の何かを示している場合、または必要なデータを正常に取得できない場合、親はこれらのレコードのデータを処理してはなりません。
The CSYNC RDATA consists of the following fields:
CSYNC RDATAは、以下のフィールドで構成されています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOA Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map (continued) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SOA Serial field contains a copy of the 32-bit SOA serial number from the child zone. If the soaminimum flag is set, parental agents querying children's authoritative servers MUST NOT act on data from zones advertising an SOA serial number less than this value. See [RFC1982] for properly implementing "less than" logic. If the soaminimum flag is not set, parental agents MUST ignore the value in the SOA Serial field. Clients can set the field to any value if the soaminimum flag is unset, such as the number zero.
SOAシリアルフィールドには、子ゾーンからの32ビットSOAシリアル番号のコピーが含まれます。 soaminimumフラグが設定されている場合、子の権限のあるサーバーにクエリを実行する親エージェントは、この値よりも小さいSOAシリアル番号をアドバタイズするゾーンからのデータを操作してはなりません（MUST NOT）。 「未満」ロジックの適切な実装については、[RFC1982]を参照してください。 soaminimumフラグが設定されていない場合、親エージェントはSOAシリアルフィールドの値を無視する必要があります。クライアントは、数値ゼロなどのsoaminimumフラグが設定されていない場合、フィールドを任意の値に設定できます。
Note that a child zone's current SOA serial number may be greater than the number indicated by the CSYNC record. A child SHOULD update the SOA Serial field in the CSYNC record every time the data being referenced by the CSYNC record is changed (e.g., an NS record or associated address record is changed). A child MAY choose to update the SOA Serial field to always match the current SOA Serial field.
子ゾーンの現在のSOAシリアル番号は、CSYNCレコードで示される番号より大きい場合があることに注意してください。子は、CSYNCレコードによって参照されているデータが変更される（たとえば、NSレコードまたは関連するアドレスレコードが変更される）たびに、CSYNCレコードのSOAシリアルフィールドを更新する必要があります（SHOULD）。子は、常に現在のSOAシリアルフィールドと一致するようにSOAシリアルフィールドを更新することを選択できます（MAY）。
Parental agents MAY cache SOA serial numbers from data they use and refuse to process data from zones older than the last instance from which they pulled data.
親エージェントは、使用するデータからSOAシリアル番号をキャッシュし、データをプルした最後のインスタンスより古いゾーンからのデータの処理を拒否する場合があります。
Although Section 3.2 of [RFC1982] describes how to properly implement a less-than comparison operation with SOA serial numbers that may wrap beyond the 32-bit value in both the SOA record and the CSYNC record, it is important that a child using the soaminimum flag must not increment its SOA serial number value more than 2^16 within the period of time that a parent might wait between polling the child for the CSYNC record.
[RFC1982]のセクション3.2は、SOAレコードとCSYNCレコードの両方で32ビット値を超えてラップする可能性があるSOAシリアル番号を使用した比較操作を適切に実装する方法を説明していますが、子供がこの最小値を使用することが重要ですフラグは、CSYNCレコードの子をポーリングする間に親が待機する可能性のある期間内に、SOAシリアル番号の値を2 ^ 16を超えて増加させてはなりません。
The Flags field contains 16 bits of boolean flags that define operations that affect the processing of the CSYNC record. The flags defined in this document are as follows:
フラグフィールドには、CSYNCレコードの処理に影響を与える操作を定義する16ビットのブールフラグが含まれています。このドキュメントで定義されているフラグは次のとおりです。
0x00 0x01: "immediate"
0x00 0x01：「即時」
0x00 0x02: "soaminimum"
0x00 0x02： "soaminimum"
The definitions for how the flags are to be used can be found in Section 3.
フラグの使用方法の定義については、セクション3を参照してください。
The remaining flags are reserved for use by future specifications. Undefined flags MUST be set to 0 by CSYNC publishers. Parental agents MUST NOT process a CSYNC record if it contains a 1 value for a flag that is unknown to or unsupported by the parental agent.
残りのフラグは、将来の仕様で使用するために予約されています。 CSYNCパブリッシャーは、未定義のフラグを0に設定する必要があります。親エージェントが知らないか、親エージェントによってサポートされていないフラグの1値が含まれている場合、親エージェントはCSYNCレコードを処理してはなりません（MUST NOT）。
The Type Bit Map field indicates the record types to be processed by the parental agent, according to the procedures in Section 3. The Type Bit Map field is encoded in the same way as the Type Bit Map field of the NSEC record, described in [RFC4034], Section 4.1.2. If a bit has been set that a parental agent implementation does not understand, the parental agent MUST NOT act upon the record. Specifically, a parental agent must not simply copy the data, and it must understand the semantics associated with a bit in the Type Bit Map field that has been set to 1.
タイプビットマップフィールドは、セクション3の手順に従って、親エージェントによって処理されるレコードタイプを示します。タイプビットマップフィールドは、[で説明されているNSECレコードのタイプビットマップフィールドと同じ方法でエンコードされます。 RFC4034]、セクション4.1.2。親エージェントの実装が理解できないビットが設定されている場合、親エージェントはレコードに基づいて動作してはなりません（MUST NOT）。具体的には、ペアレントエージェントはデータを単にコピーするだけでなく、1に設定されているType Bit Mapフィールドのビットに関連付けられたセマンティクスを理解する必要があります。
The CSYNC presentation format is as follows:
CSYNCの表示形式は次のとおりです。
The SOA Serial field is represented as an integer.
SOAシリアルフィールドは整数として表されます。
The Flags field is represented as an integer.
Flagsフィールドは整数として表されます。
The Type Bit Map field is represented as a sequence of RRType mnemonics. When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used. Implementations that support parsing of presentation format records SHOULD be able to read and understand these TYPE representations as well.
Type Bit Mapフィールドは、RRTypeニーモニックのシーケンスとして表されます。ニーモニックが不明な場合は、[RFC3597]のセクション5で説明されているTYPE表現を使用する必要があります。表示形式レコードの解析をサポートする実装は、これらのTYPE表現も読み取って理解できる必要があります（SHOULD）。
The following CSYNC RR shows an example entry for "example.com" that indicates the NS, A, and AAAA bits are set and should be processed by the parental agent for example.com. The parental agent should pull data only from a zone using a minimum SOA serial number of 66 (0x42 in hexadecimal).
次のCSYNC RRは、「example.com」のエントリの例を示しています。これは、NS、A、AAAAビットが設定されており、example.comの親エージェントによって処理される必要があることを示しています。親エージェントは、66（16進数で0x42）の最小SOAシリアル番号を使用するゾーンからのみデータをプルする必要があります。
example.com. 3600 IN CSYNC 66 3 A NS AAAA
example.com。 3600 IN CSYNC 66 3 A NS AAAA
The RDATA component of the example CSYNC RR would be encoded on the wire as follows:
例のCSYNC RRのRDATAコンポーネントは、次のようにネットワーク上でエンコードされます。
0x00 0x00 0x00 0x42 (SOA Serial) 0x00 0x03 (Flags = immediate | soaminimum) 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)
0x00 0x00 0x00 0x42（SOAシリアル）0x00 0x03（フラグ=即時| soaminimum）0x00 0x04 0x60 0x00 0x00 0x08（タイプビットマップ）
The CSYNC record and associated data must be processed as an "all or nothing" operation set. If a parental agent fails to successfully query for any of the required records, the whole operation MUST be aborted. (Note that a query resulting in "no records exist" as proven by NSEC or NSEC3 is to be considered successful).
CSYNCレコードと関連データは、「オールオアナッシング」操作セットとして処理する必要があります。ペアレントエージェントが必要なレコードのクエリに失敗した場合、操作全体を中止する必要があります。 （NSECまたはNSEC3によって証明された「レコードが存在しない」という結果になるクエリは、成功したと見なされます）。
Parental agents MAY:
保護者の代理人：
Process the CSYNC record immediately if the "immediate" flag is set. If the "immediate" flag is not set, the parental agent MUST NOT act until the zone administrator approves the operation through an out-of-band mechanism (such as through pushing a button via a web interface).
「即時」フラグが設定されている場合は、CSYNCレコードをすぐに処理します。 「即時」フラグが設定されていない場合、親エージェントは、ゾーン管理者がアウトオブバンドメカニズム（Webインターフェイスを介してボタンを押すなど）を通じて操作を承認するまで、動作してはなりません。
Choose not to process the CSYNC record immediately, even if the "immediate" flag is set. That is, a parental agent might require the child zone administrator approve the operation through an out-of-band mechanism (such as through pushing a button via a web interface).
「即時」フラグが設定されている場合でも、CSYNCレコードをすぐに処理しないことを選択します。つまり、親エージェントは、子ゾーン管理者がアウトオブバンドメカニズム（Webインターフェイスを介してボタンを押すなど）を介して操作を承認するように要求する場合があります。
Note: how the approval is done out of band is outside the scope of this document and is implementation specific to parental agents.
注：承認が帯域外で行われる方法はこのドキュメントの範囲外であり、保護者のエージェントに固有の実装です。
The following shows a sequence of steps that SHOULD be used when collecting and processing CSYNC records from a child zone. Because DNS queries are not allowed to contain more than one "question" at a time, a sequence of requests is needed. When processing a CSYNC transaction request, all DNS queries should be sent to a single authoritative name server for the child zone. To ensure a single host is being addressed, DNS over TCP SHOULD be used to avoid conversing with multiple nodes at an anycast address.
以下は、子ゾーンからCSYNCレコードを収集して処理するときに使用する必要がある一連のステップを示しています。 DNSクエリは一度に複数の「質問」を含むことができないため、一連のリクエストが必要です。 CSYNCトランザクション要求を処理するときは、すべてのDNSクエリを子ゾーンの単一の権威ネームサーバーに送信する必要があります。単一のホストがアドレス指定されていることを確認するには、DNS over TCPを使用して、エニーキャストアドレスで複数のノードとの会話を回避する必要があります（SHOULD）。
1. Query for the child zone's SOA record
1. 子ゾーンのSOAレコードのクエリ
2. Query for the child zone's CSYNC record
2. 子ゾーンのCSYNCレコードのクエリ
3. Query for the child zone's data records, as required by the CSYNC record's Type Bit Map field
3. CSYNCレコードのType Bit Mapフィールドの要求に応じて、子ゾーンのデータレコードをクエリします。
* Note: if any of the resulting records being queried are not authoritative within the child zone but rather in a grandchild or deeper, SOA record queries must be made for the grandchildren. This will require the parental agent to determine where the child/grandchild zone cuts occur. Because of the additional operational complexity, parental agents MAY choose not to support this protocol with children making use of records that are authoritative in the grandchildren.
* 注：クエリの結果のレコードのいずれかが子ゾーン内ではなく、孫以上の権限がある場合、孫に対してSOAレコードクエリを実行する必要があります。これには、親/エージェントが子/孫ゾーンカットが発生する場所を決定する必要があります。操作がさらに複雑になるため、親エージェントは、孫で信頼できるレコードを利用している子供がこのプロトコルをサポートしないことを選択する場合があります。
4. Query for the collected SOA records again, starting with the deepest and ending with the SOA of the child's.
4. 収集されたSOAレコードをもう一度クエリします。最も深いものから始まり、子供のSOAで終わります。
If the SOA records from the first, middle, and last steps for a given zone have different serial numbers (for example, because the zone was edited and republished during the interval between steps 1 and 4), then the CSYNC record obtained in the second set SHOULD NOT be processed (rapidly changing child zones may need special consideration or processing). The operation MAY be restarted or retried in the future.
特定のゾーンの最初、中間、最後のステップのSOAレコードのシリアル番号が異なる場合（たとえば、ステップ1と4の間の間にゾーンが編集および再発行されたため）、2番目に取得されたCSYNCレコードsetは処理されるべきではありません（子ゾーンを急速に変更する場合は、特別な考慮または処理が必要になる場合があります）。操作は再起動されるか、将来再試行される場合があります。
If the soaminimum flag is set and the SOA serial numbers are equal but less than the CSYNC record's SOA Serial field [RFC1982], the record MUST NOT be processed. If state is being kept by the parental agent and the SOA serial number is less than the last time a CSYNC record was processed, this CSYNC record SHOULD NOT be processed. Similarly, if state is being kept by the parental agent and the SOA Serial field of the CSYNC record is less than the SOA Serial field of the CSYNC record from last time, then this CSYNC record SHOULD NOT be processed.
soaminimumフラグが設定されていて、SOAシリアル番号がCSYNCレコードのSOAシリアルフィールド[RFC1982]と等しいが小さい場合は、レコードを処理してはなりません（MUST NOT）。親エージェントによって状態が保持されていて、SOAシリアル番号がCSYNCレコードが最後に処理された時刻よりも小さい場合、このCSYNCレコードは処理されるべきではありません（SHOULD NOT）。同様に、状態が親エージェントによって保持されており、CSYNCレコードのSOAシリアルフィールドが前回のCSYNCレコードのSOAシリアルフィールドより小さい場合、このCSYNCレコードは処理されるべきではありません（SHOULD NOT）。
If a failure of any kind occurs while trying to obtain any of the required data, or if DNSSEC fails to validate all of the data returned for these queries as "secure", then this CSYNC record MUST NOT be processed.
必要なデータを取得しようとしたときに何らかの障害が発生した場合、またはDNSSECがこれらのクエリに対して返されたすべてのデータを「安全」として検証できない場合、このCSYNCレコードは処理してはなりません（MUST NOT）。
See the "Operational Consideration" section (Section 4) for additional guidance about processing.
処理に関する追加のガイダンスについては、「運用上の考慮事項」セクション（セクション4）を参照してください。
This document defines how the following record types may be processed if the CSYNC Type Bit Map field indicates they are to be processed.
このドキュメントでは、CSYNCタイプのビットマップフィールドが処理対象であることを示している場合に、次のレコードタイプを処理する方法を定義します。
The NS type flag indicates that the NS records from the child zone should be copied into the parent's delegation information records for the child.
NSタイプフラグは、子ゾーンのNSレコードを親の子の委任情報レコードにコピーする必要があることを示します。
NS records found within the child's zone should be copied verbatim (with the exception of the Time to Live (TTL) field, for which the parent MAY want to select a different value) and the result published within the parent zone should be a set of NS records that match exactly. If the child has published a new NS record within their set, this record should be added to the parent zone. Similarly, if NS records in the parent's delegation records for the child contain records that have been removed in the child's NS set, then they should be removed in the parent's set as well.
子のゾーン内で見つかったNSレコードはそのままコピーする必要があり（Time to Live（TTL）フィールドを除き、親は別の値を選択する必要がある場合があります）、親ゾーン内で公開された結果は、完全に一致するNSレコード。子がセット内で新しいNSレコードを公開した場合、このレコードは親ゾーンに追加する必要があります。同様に、子の親の委任レコードのNSレコードに、子のNSセットで削除されたレコードが含まれている場合は、親のセットでも削除する必要があります。
Parental agents MAY refuse to perform NS updates if the replacement records fail to meet NS record policies required by the parent zone (e.g., "every child zone must have at least two NS records"). Parental agents MUST NOT perform NS updates if there are no NS records returned in a query, as verified by DNSSEC denial-of-existence protection. This situation should never happen unless the child nameservers are misconfigured.
親エージェントは、置換レコードが親ゾーンに必要なNSレコードポリシーを満たさない場合（たとえば、「すべての子ゾーンに少なくとも2つのNSレコードが必要」）、NS更新の実行を拒否することができます（MAY）。親エージェントは、DNSSECの存在拒否保護によって検証されるように、クエリでNSレコードが返されない場合、NS更新を実行してはなりません（MUST NOT）。この状況は、子ネームサーバーが正しく構成されていない限り発生しません。
Note that it is permissible for a child's nameserver to return a CSYNC record that removes the queried nameserver itself from the future NS or address set.
子のネームサーバーが、照会されたネームサーバー自体を将来のNSまたはアドレスセットから削除するCSYNCレコードを返すことが許可されていることに注意してください。
The A and AAAA type flags indicates that the A and AAAA address glue records for in-bailiwick NS records within the child zone should be copied verbatim (with the exception of the TTL field, for which the parent MAY want to select a different value) into the parent's delegation information.
AおよびAAAAタイプのフラグは、子ゾーン内のインバイリウィックNSレコードのAおよびAAAAアドレスグルーレコードをそのままコピーする必要があることを示します（TTLフィールドを除き、親は別の値を選択する場合があります）。親の委任情報に。
Queries should be sent by the parental agent to determine the A and AAAA record addresses for each NS record within a NS set for the child that are in bailiwick.
親エージェントがクエリを送信して、bailiwickにいる子のNSセット内の各NSレコードのAおよびAAAAレコードアドレスを決定する必要があります。
Note: only the matching types should be queried. For example, if the AAAA bit has not been set, then the AAAA records (if any) in the parent's delegation should remain as is. If a given address type is set and the child's zone contains no data for that type (as proven by appropriate NSEC or NSEC3 records), then the result in the parent's delegation records for the child should be an empty set. However, if the end result of processing would leave no glue records present in the parent zone for any of the of the in-bailiwick NS records, then the parent MUST NOT update the glue address records. That is, if the result of the processing would leave no in-bailiwick A or AAAA records when there are in-bailiwick NS records, then processing of the address records cannot happen as it would leave the parent/child relationship without any address linkage.
注：一致するタイプのみを照会する必要があります。たとえば、AAAAビットが設定されていない場合、親の委任内のAAAAレコード（存在する場合）はそのままにしておく必要があります。特定のアドレスタイプが設定され、子のゾーンにそのタイプのデータが含まれていない場合（適切なNSECまたはNSEC3レコードで証明されているように）、子の親の委任レコードの結果は空のセットになります。ただし、処理の最終結果によって、いずれかのin-bailiwick NSレコードの親ゾーンに接着レコードが残っていない場合、親は接着アドレスレコードを更新してはなりません（MUST NOT）。つまり、処理の結果、バイリウィック内のNSレコードがあるときにバイリウィックAまたはAAAAレコードが残っていない場合、アドレスリンクがないと親子関係がなくなるため、アドレスレコードの処理を実行できません。
The procedure for querying for A and AAAA records MUST occur after the procedure, if required, for querying for NS records as defined in Section 3.2.1. This ensures that the right set of NS records is used as provided by the current NS set of the child. That is, for CSYNC records that have the NS bit set, the NS set used should be the one pulled from the child while processing the CSYNC record. For CSYNC records without the NS bit set, the existing NS records within the parent should be used to determine which A and/or AAAA records to update.
AおよびAAAAレコードのクエリ手順は、必要に応じて、セクション3.2.1で定義されているNSレコードのクエリ手順の後に実行する必要があります。これにより、NSレコードの正しいセットが、子の現在のNSセットによって提供されるように使用されます。つまり、NSビットが設定されているCSYNCレコードの場合、使用されるNSセットは、CSYNCレコードの処理中に子からプルされたものでなければなりません。 NSビットが設定されていないCSYNCレコードの場合、親内の既存のNSレコードを使用して、更新するAレコードまたはAAAAレコード、あるいはその両方を決定する必要があります。
There are a number of important operational aspects to consider when deploying a CSYNC RRType.
CSYNC RRTypeをデプロイする際に考慮すべき運用上の重要な側面がいくつかあります。
There is no inline mechanism for a parental agent to report errors to operators of child zones. Thus, the only error reporting mechanisms must be out of band, such as through a web console or over email. Parental agents should, at a minimum, at least log errors encountered when processing CSYNC records. Child operators utilizing the "immediate" flag that fail to see an update within the parental agent's specified operational window should access the parental agent's error logging interface to determine why an update failed to be processed.
親エージェントが子ゾーンのオペレーターにエラーを報告するインラインメカニズムはありません。したがって、唯一のエラー報告メカニズムは、Webコンソールや電子メールなどの帯域外である必要があります。親エージェントは、少なくとも、CSYNCレコードの処理中に発生したエラーをログに記録する必要があります。親エージェントの指定された操作ウィンドウ内で更新を確認できない「即時」フラグを利用する子オペレーターは、親エージェントのエラーログインターフェイスにアクセスして、更新の処理に失敗した理由を特定する必要があります。
Parental agents will need to poll child nameservers in search of CSYNC records and related data records.
保護者のエージェントは、CSYNCレコードと関連データレコードを検索して、子ネームサーバーをポーリングする必要があります。
Parental agents MAY perform best-possible verification by querying all NS records for available data to determine which has the most recent SOA and CSYNC version (in an ideal world, they would all be equal, but this is not possible in practice due to synchronization delays and transfer failures).
保護者のエージェントは、すべてのNSレコードにクエリを実行して利用可能なデータを問い合わせ、最も新しいSOAとCSYNCのバージョンがどれであるかを確認することで、可能な限り最良の検証を実行できます（理想的な世界では、これらはすべて同じですが、同期の遅延により実際には不可能です）および転送の失敗）。
Parental agents may offer a configuration interface to allow child operators to specify which nameserver should be considered the master to send data queries, too. Note that this master could be a different nameserver than the publicly listed nameservers in the NS set (i.e., it may be a "hidden master").
ペアレントエージェントは、子オペレーターがデータクエリを送信するためにマスターと見なす必要があるネームサーバーを指定できるようにする構成インターフェースを提供する場合もあります。このマスターは、NSセットに公開されているネームサーバーとは異なるネームサーバーである可能性があることに注意してください（つまり、「非表示のマスター」である可能性があります）。
Parental agents with a large number of clients may choose to offer a programmatic interface to let their children indicate that new CSYNC records and data are available for polling rather than polling every child on a frequent basis.
多数のクライアントを持つ親エージェントは、すべての子を頻繁にポーリングするのではなく、新しいCSYNCレコードとデータがポーリングに利用可能であることを子に示すためのプログラムインターフェイスを提供することを選択できます。
Children that wish to phase out a nameserver will need to publish the CSYNC record to remove the nameserver and then wait for the parental agent to process the published record before turning off the service. This is required because the child cannot control which nameserver in the existing NS set the parental agent may choose to query when performing CSYNC processing.
ネームサーバーを段階的に廃止したい子供は、CSYNCレコードを公開してネームサーバーを削除し、親エージェントが公開されたレコードを処理するのを待ってからサービスをオフにする必要があります。子は、CSYNC処理を実行するときに親エージェントがクエリを選択できる既存のNSセット内のどのネームサーバーを制御できないため、これが必要です。
When a zone contains NS records where the domain name pointed at does not fall within the zone itself, there is no way for the parent to safely update the associated glue records. Thus, the child DNS operator MAY indicate that the NS records should be synchronized, and MAY set any glue record flags (A, AAAA) as well, but the parent will only update those glue records that are below the child's delegation point.
ゾーンにNSレコードが含まれており、そのドメイン名がゾーン自体に含まれていない場合、親が関連するグルーレコードを安全に更新する方法はありません。したがって、子DNSオペレーターはNSレコードを同期する必要があることを示し、任意のグルーレコードフラグ（A、AAAA）も設定できますが、親は子の委任ポイントの下にあるグルーレコードのみを更新します。
Children deploying NS records pointing to domain names within their own children (the "grandchildren") SHOULD ensure the grandchildren's associated glue records are properly set before publishing the CSYNC record. That is, it is imperative that proper communication and synchronization exist between the child and the grandchild.
自分の子（「孫」）内のドメイン名を指すNSレコードを展開する子は、CSYNCレコードを公開する前に、孫に関連付けられたグルーレコードが適切に設定されていることを確認する必要があります。つまり、子供と孫の間に適切なコミュニケーションと同期が存在することが不可欠です。
Parental agents that support processing CSYNC records SHOULD publicly document the following minimum processing characteristics:
CSYNCレコードの処理をサポートする親エージェントは、以下の最小処理特性を公に文書化する必要があります（SHOULD）。
The fact that they support CSYNC processing
CSYNC処理をサポートするという事実
The Type Bit Map bits they support
サポートするタイプビットマップビット
The frequency with which they poll clients (which may also be configurable by the client)
クライアントをポーリングする頻度（クライアントが設定することもできます）
If they support the "immediate" flag
「即時」フラグをサポートしている場合
If they poll a child's single nameserver, a configured list of nameservers, or all of the advertised nameservers when querying records
レコードのクエリ時に、子の単一のネームサーバー、構成済みのネームサーバーのリスト、またはアドバタイズされたすべてのネームサーバーをポーリングする場合
If they support SOA serial number caching to avoid issues with regression and/or replay
リグレッションやリプレイの問題を回避するためにSOAシリアル番号キャッシュをサポートしている場合
Where errors for CSYNC processing are published
CSYNC処理のエラーが公開される場所
If they support sending queries to a "hidden master"
「非表示のマスター」へのクエリの送信をサポートしている場合
Children MAY remove the CSYNC record upon noticing that the parent zone has published the required records, thus eliminating the need for the parent to continually query for the CSYNC record and all corresponding records. By removing the CSYNC record from the child zone, the parental agent will only need to perform the query for the CSYNC record and can stop processing when it finds it missing. This will reduce resource usage by both the child and the parental agent.
子は、親ゾーンが必要なレコードを公開したことに気付いたときにCSYNCレコードを削除できます。これにより、親がCSYNCレコードとすべての対応するレコードを継続的に照会する必要がなくなります。子ゾーンからCSYNCレコードを削除することにより、親エージェントはCSYNCレコードのクエリを実行するだけで済み、欠落していることがわかったときに処理を停止できます。これにより、子と親エージェントの両方によるリソース使用量が削減されます。
When a child needs to publish a CSYNC record that synchronizes NS and A/AAAA glue records and the NS record is actually pointing to a child of the child (a grandchild of the parent), then it is critical that the glue records in the child point to the proper real addresses records published by the grandchild. It is assumed that if a child is using a grandchild's nameserver that they must be in careful synchronization. Specifically, this specification requires this to be the case.
子がNSおよびA / AAAAグルーレコードを同期するCSYNCレコードを発行する必要があり、NSレコードが実際に子の子（親の孫）を指している場合、子のグルーレコードが重要です。孫が発行した適切な実際の住所レコードをポイントします。子供が孫のネームサーバーを使用している場合、注意深く同期する必要があると想定されています。具体的には、この仕様ではこれが当てはまる必要があります。
This specification requires the use of DNSSEC in order to determine that the data being updated was unmodified by third parties. Parental agents implementing CSYNC processing MUST ensure all DNS transactions are validated by DNSSEC as "secure". Clients deploying CSYNC MUST ensure their zones are signed, current and properly linked to the parent zone with a DS record that points to an appropriate DNSKEY of the child's zone.
この仕様では、更新されるデータが第三者によって変更されていないことを確認するためにDNSSECを使用する必要があります。 CSYNC処理を実装する親エージェントは、すべてのDNSトランザクションがDNSSECによって「安全」として検証されるようにする必要があります。 CSYNCを展開するクライアントは、ゾーンが署名され、最新で、子ゾーンの適切なDNSKEYを指すDSレコードで親ゾーンに適切にリンクされていることを確認する必要があります。
This specification does not address how to perform bootstrapping operations to get the required initial DNSSEC-secured operating environment in place. Additionally, this specification was not designed to synchronize DNSSEC security records, such as DS pointers, or the CSYNC record itself. Thus, implementations of this protocol MUST NOT use it to synchronize DS records, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records. Similarly, future documents extending this protocol MUST NOT offer the ability to synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records. For such a solution, please see the complimentary solution [RFC7344] for maintaining security delegation information.
この仕様は、必要な初期のDNSSECで保護された動作環境を整えるためにブートストラップ操作を実行する方法は扱いません。さらに、この仕様は、DSポインターなどのDNSSECセキュリティレコードやCSYNCレコード自体を同期するようには設計されていません。したがって、このプロトコルの実装は、DSレコード、DNSKEYマテリアル、CDSレコード、CDNSKEYレコード、またはCSYNCレコードを同期するためにそれを使用してはなりません（MUST NOT）。同様に、このプロトコルを拡張する将来のドキュメントは、DS、DNSKEYマテリアル、CDSレコード、CDNSKEYレコード、またはCSYNCレコードを同期する機能を提供してはなりません（MUST NOT）。このようなソリューションについては、セキュリティ委任情報を維持するための補足ソリューション[RFC7344]を参照してください。
To ensure that an older CSYNC record making use of the soaminimum flag cannot be replayed to revert values, the SOA serial number MUST NOT be incremented by more than 2^16 during the lifetime of the signature window of the associated RRSIGs signing the SOA and CSYNC records. Note that this is independent of whether or not the increment causes the 2^32 bit serial number field to wrap.
soaminimumフラグを使用する古いCSYNCレコードを再生して値を元に戻すことができないようにするには、SOAおよびCSYNCに署名する関連するRRSIGの署名ウィンドウの存続期間中に、SOAシリアル番号を2 ^ 16を超えてインクリメントしないでください記録。これは、インクリメントによって2 ^ 32ビットのシリアル番号フィールドが折り返されるかどうかには依存しないことに注意してください。
This document defines a new DNS Resource Record Type, named "CSYNC". The IANA has assigned a code point from the "Resource Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS) Parameters" registry (http://www.iana.org/assignments/dns-parameters) for this record.
このドキュメントでは、「CSYNC」という名前の新しいDNSリソースレコードタイプを定義しています。 IANAは、「ドメインネームシステム（DNS）パラメータ」レジストリ（http://www.iana.org/assignments/dns-parameters）の「Resource Record（RR）TYPEs」サブレジストリからコードポイントを割り当てました。このレコード。
TYPE Value Meaning Reference
----- ------ -------------------------- -----------
CSYNC 62 Child-to-Parent Synchronization [RFC7477]
The IANA has created and maintains a sub-registry (the "Child Synchronization (CSYNC) Flags" registry) of the "Domain Name System (DNS) Parameters" registry. The initial values for this registry are below.
IANAは、「ドメインネームシステム（DNS）パラメータ」レジストリのサブレジストリ（「子同期（CSYNC）フラグ」レジストリ）を作成して管理しています。このレジストリの初期値は次のとおりです。
A "Standards Action" [RFC5226] is required for the assignment of new flag value.
新しいフラグ値の割り当てには、「標準アクション」[RFC5226]が必要です。
This registry holds a set of single-bit "Flags" for use in the CSYNC record within the 16-bit Flags field. Thus, a maximum of 16 flags may be defined.
このレジストリは、16ビットのフラグフィールド内のCSYNCレコードで使用する単一ビットの「フラグ」のセットを保持します。したがって、最大16個のフラグを定義できます。
The initial assignments in this registry are:
このレジストリの初期割り当ては次のとおりです。
Bit Flag Description Reference
---- ------ ------------- -----------
Bit 0 immediate Immediately process this [RFC7477],
CSYNC record. Section 3
Bit 1 soaminimum Require a SOA serial [RFC7477], number greater than the Section 2.1.1.1 one specified.
ビット1 soaminimum SOAシリアル[RFC7477]が必要であり、指定されたセクション2.1.1.1より大きい番号。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996, <http://www.rfc-editor.org/info/rfc1982>.
[RFC1982] Elz、R. and R. Bush、 "Serial Number Arithmetic"、RFC 1982、August 1996、<http://www.rfc-editor.org/info/rfc1982>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003, <http://www.rfc-editor.org/info/rfc3597>.
[RFC3597] Gustafsson、A。、「Handling of Unknown DNS Resource Record（RR）Types」、RFC 3597、2003年9月、<http://www.rfc-editor.org/info/rfc3597>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月、<http：// www .rfc-editor.org / info / rfc4034>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月、<http：//www.rfc -editor.org/info/rfc4033>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月、<http：// www .rfc-editor.org / info / rfc4035>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, September 2014, <http://www.rfc-editor.org/info/rfc7344>.
[RFC7344] Kumari、W.、Gudmundsson、O。、およびG. Barwood、「Automating DNSSEC Delegation Trust Maintenance」、RFC 7344、2014年9月、<http://www.rfc-editor.org/info/rfc7344>。
Acknowledgments
謝辞
A thank you goes out to Warren Kumari and Olafur Gudmundsson, whose work on the CDS record type helped inspire the work in this document, as well as the definition for the "parental agent" definition and significant contributions to the text. A thank you also goes out to Ed Lewis, with whom the author held many conversations about the issues surrounding parent/child relationships and synchronization. Much of the work in this document is derived from the careful existing analysis of these three esteemed colleagues. Thank you to the following people who have contributed text or detailed reviews to the document (in no particular order): Matthijs Mekking, Petr Spacek, JINMEI Tatuya, Pete Resnick, Joel Jaeggli, Brian Haberman, Warren Kumari, Adrian Farrel, Alia Atlas, Barry Leiba, Richard Barnes, Stephen Farrell, and Ted Lemon. Lastly, the DNSOP WG chairs Tim Wicinski and Suzanne Woolf have been a tremendous help in getting this document moving forward to publication.
CDSレコードタイプに関する作業を行ったWarren KumariとOlafur Gudmundssonに感謝します。また、「親エージェント」の定義の定義と本文への重要な貢献に加えて、このドキュメントの作業に影響を与えました。また、著者と親子関係や同期に関する問題について多くの会話を交わしたエド・ルイスにも感謝します。このドキュメントの作業の多くは、これら3人の尊敬されている同僚の既存の注意深い分析に基づいています。ドキュメントにテキストまたは詳細なレビューを投稿した以下の人々に感謝します（順不同）：Matthijs Mekking、Petr Spacek、JINMEI Tatuya、Pete Resnick、Joel Jaeggli、Brian Haberman、Warren Kumari、Adrian Farrel、Alia Atlas、バリーレイバ、リチャードバーンズ、スティーブンファレル、テッドレモン。最後に、DNSOP WGの議長であるTim WicinskiとSuzanne Woolfは、このドキュメントを出版に向けて前進させる上で非常に役立ちました。
A special thanks goes to Roy Arends, for taking the "bite out of that hamburger" challenge while discussing this document.
このドキュメントについて議論している「ハンバーガーから一口」の挑戦を取り除いてくれたロイアーレンズに特に感謝します。
A similar project, independently designed and developed, was conducted by ep.net called "Child Activated DNS Refresh".
独立して設計および開発された同様のプロジェクトは、「Child Activated DNS Refresh」と呼ばれるep.netによって実施されました。
Author's Address
著者のアドレス
Wes Hardaker Parsons, Inc. P.O. Box 382 Davis, CA 95617 US
うぇｓ はｒだけｒ ぱｒそんｓ、 いんｃ。 Ｐ。お。 ぼｘ ３８２ だゔぃｓ、 か ９５６１７ うＳ
Phone: +1 530 792 1913
EMail: ietf@hardakers.net