RFC 7745 - XML Schemas for Reverse DNS Management 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7745
タイトル : RFC 7745 - リバースDNS管理のXMLスキーマ
翻訳編集 : 自動生成

[要約] RFC 7745は、逆DNS管理のためのXMLスキーマを定義しています。このRFCの目的は、逆DNSデータの標準化と相互運用性の向上です。

Independent Submission                                      T. Manderson
Request for Comments: 7745                                         ICANN
Category: Informational                                     January 2016
ISSN: 2070-1721

XML Schemas for Reverse DNS Management

リバースDNS管理のXMLスキーマ

Abstract

概要

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.

このドキュメントでは、厳密に制御された表現状態転送（REST）環境での逆DNS管理用のExtensible Markup Language（XML）スキーマを定義します。このドキュメントでは、2011年からICANNによって「RESTful」システムで開発および展開されており、HTTPSトランザクションを通じてIN-ADDR.ARPAおよびIP6.ARPAの下の逆引きDNS（rDNS）委任を担当するレジストリによって使用されているスキーマについて説明しますX.509証明書によって仲介されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7745.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7745で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Schema Definition for rDNS Updates . . . . . . . . .   7
   Appendix B.  Schema Definition for rDNS Queue Entries . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) [REST] environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA [RFC1034] and IP6.ARPA [RFC3596] through an HTTPS [RFC2818] transaction that is mediated by an X.509 [RFC5280] certificate.

このドキュメントでは、厳密に制御された表現状態転送（REST）[REST]環境での逆DNS管理用の拡張マークアップ言語（XML）スキーマを定義します。このドキュメントは、2011年以降ICANNによって「RESTful」システムで開発および展開され、IN-ADDR.ARPA [RFC1034]およびIP6.ARPAの下のリバースDNS（rDNS）委任を担当するレジストリによって使用されているスキーマについて説明しています。 RFC3596] X.509 [RFC5280]証明書によって仲介されるHTTPS [RFC2818]トランザクションを介して。

As DNSSEC [RFC4033] adoption progresses, the necessity to interact with a delegation in the IN-ADDR.ARPA and IP6.APRA zones becomes more frequent given that updates to DS records in the parent zone for child delegations follow the key rollover and expiry of the child zone. The modification of such critical areas at a relative high frequency requires a system that allows the administrative holders of such delegations to make such changes in a secure and trustworthy manner where the chain of trust for submitting the necessary information remains unbroken between the IN-ADDR.ARPA and IP6.APRA zone maintainers and the zone customers.

DNSSEC [RFC4033]の採用が進むにつれて、子委任の親ゾーンのDSレコードの更新がキーロールオーバーと子ゾーン。このような重要な領域を比較的高い頻度で変更するには、そのような委任の管理者が、必要な情報を送信するための信頼の連鎖がIN-ADDR間で途切れないままであるような、安全で信頼できる方法でそのような変更を行うことができるシステムが必要です。 ARPAおよびIP6.APRAゾーンのメンテナーとゾーンの顧客。

At the request of the Regional Internet Registries (RIRs) to automate reverse DNS updates with ICANN, a REST-based HTTPS service was deployed that:

ICANNを使用してDNSの逆更新を自動化するための地域インターネットレジストリ（RIR）の要求に応じて、RESTベースのHTTPSサービスが展開されました。

o Provides for a secure, authenticated mechanism to update zone data (NS and DS records)

o ゾーンデータ（NSおよびDSレコード）を更新するための安全で認証されたメカニズムを提供します

o Provides a well-formed data structure for both the IN-ADDR.ARPA and IP6.ARPA zones

o IN-ADDR.ARPAゾーンとIP6.ARPAゾーンの両方に整形式のデータ構造を提供します

o Allows for "out-of-band" acknowledgement and notification of updates

o 「アウトオブバンド」の確認応答と更新の通知が可能

2. Requirements Language

2. 要件言語

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Implementation

3. 実装

The implemented system allows the entity responsible for its rDNS delegations to effect changes in the reverse DNS zones IN-ADDR.ARPA and IP6.ARPA by submitting an XML document to an atomic RESTful service via an HTTPS [RFC2818] connection. In this service, the HTTPS layer provides the end-to-end security of the transaction, and it further provides authentication by use of mandatory X.509 [RFC5280] client certificates with a known server certificate issued by a Certification Authority administered by the service operator.

実装されたシステムにより、rDNS委任を担当するエンティティは、HTTPS [RFC2818]接続を介してXMLドキュメントをアトミックRESTfulサービスに送信することにより、逆DNSゾーンIN-ADDR.ARPAおよびIP6.ARPAに変更を加えることができます。このサービスでは、HTTPSレイヤーがトランザクションのエンドツーエンドのセキュリティを提供し、さらに、サービスが管理する認証局が発行した既知のサーバー証明書による必須のX.509 [RFC5280]クライアント証明書を使用した認証を提供しますオペレーター。

Certificates for use in this system, issued by the system operator, are specific to the entity responsible for the delegations in the zone.

このシステムで使用するための証明書は、システムオペレーターによって発行され、ゾーン内の委任を担当するエンティティに固有です。

Updates are made to the system by using the HTTP GET, PUT, and DELETE operations over HTTP 1.1 [RFC7231] via HTTPS [RFC2818] only. These operations are sent to a resource Uniform Resource Identifier (URI) in the form of:

更新は、HTTPS [RFC2818]を介したHTTP 1.1 [RFC7231]を介したHTTP GET、PUT、およびDELETE操作のみを使用してシステムに対して行われます。これらの操作は、次の形式でリソースのURI（Uniform Resource Identifier）に送信されます。

           https://host.example.org/<ipversion>/<zone>

A synthetic example of an XML document submitted to the deployed system might take the following form (including all optional attributes) as per the schema in Appendix A.

展開されたシステムに送信されたXMLドキュメントの合成例は、付録Aのスキーマに従って、次の形式（すべてのオプション属性を含む）になる場合があります。

   <zone xmlns="http://download.research.icann.org/rdns/1.1"
     name="10.in-addr.arpa" cust="IANA" ipversion="ipv4"
     version="1.1" modified="2012-01-18T01:00:06"
     state="active" href="https://host.example.org/ipv4/10">
     <nserver>
       <fqdn>BLACKHOLE-1.IANA.ORG.</fqdn>
     </nserver>
     <nserver>
       <fqdn>BLACKHOLE-2.IANA.ORG.</fqdn>
     </nserver>
     <ds>
       <rdata>33682 5 1 ea8afb5fce7caf381ab101039</rdata>
     </ds>
     <ds>
       <rdata>33682 5 2 7d44874f1d93aaceb793a88001739a</rdata>
     </ds>
   </zone>

When PUT and DELETE operations are used, the well-formed XML is required to be sent with the appropriate content-length headers. The GET operation requires only the URI.

PUTおよびDELETE操作が使用される場合、整形式のXMLは、適切なcontent-lengthヘッダーとともに送信される必要があります。 GET操作にはURIのみが必要です。

One requirement of the system was to allow the separation of update and approval with an out-of-band notification mechanism. When such options are configured for a customer of the service, submitted updates may be queued for later approval. When a customer has queued updates pending approval, the customer may submit a GET request to retrieve either an individual entry or a full listing of all queued entries.

このシステムの要件の1つは、帯域外通知メカニズムを使用して更新と承認を分離できるようにすることでした。そのようなオプションがサービスの顧客に対して構成されている場合、送信された更新は後で承認するためにキューに入れられることがあります。顧客が承認待ちの更新をキューに入れている場合、顧客はGET要求を送信して、個々のエントリまたはキューに入れられたすべてのエントリの完全なリストを取得できます。

To fetch a listing of the customer's queue, the customer would GET a URI in the form of:

顧客のキューのリストを取得するには、顧客は次の形式でURIを取得します。

           https://host.example.org/queuelist

To fetch an individual queue entry, the customer would GET the canonical URL (as per the schema) for this queue record:

個々のキューエントリをフェッチするには、お客様はこのキューレコードの（スキーマごとに）正規URLを取得します。

           https://host.example.org/queue/<identifier>

Where <identifier> is a system-generated and system-specific value that identifies this particular queue entry. All XML returned from queue-based operations ('queue' and 'queuelist') would return an XML document following the specification in Appendix B. A synthetic example from a GET of 'queuelist' would be:

<identifier>は、この特定のキューエントリを識別するシステム生成のシステム固有の値です。キューベースの操作（「queue」および「queuelist」）から返されるすべてのXMLは、付録Bの仕様に従ってXMLドキュメントを返します。「queuelist」のGETからの合成例は次のようになります。

   <queuelist xmlns="http://download.research.icann.org/rq/1.0"
    version="1.0">
    <queue xmlns="http://download.research.icann.org/rq/1.0"
     name="10.in-addr.arpa" cust="IANA" ipversion="ipv4"
     version="1.0" submitted="2013-01-11T05:22:15"
     state="pending" method="PUT"
     ack="https://host.example.org/ack/25a531f50e5ba45"
     href="https://host.example.org/queue/25a531f50e5ba45">
     <nserver>
       <fqdn>BLACKHOLE-1.IANA.ORG.</fqdn>
     </nserver>
     <nserver>
       <fqdn>BLACKHOLE-2.IANA.ORG.</fqdn>
     </nserver>
     <ds>
       <rdata>33682 5 1 ea8afb5fce7caf381ab101039</rdata>
     </ds>
     <ds>
       <rdata>33682 5 2 7d44874f1d93aaceb793a88001739a</rdata>
     </ds>
    </queue>
   </queuelist>

4. Security Considerations

4. セキュリティに関する考慮事項

This document provides an XML schema for facilitating the management of reverse DNS delegations in the IN-ADDR.ARPA and IP6.APRA zones. The schema itself contains no authentication data, and all other information contained is considered public data as it is either published in DNS or propagated to other public information sources like WHOIS.

このドキュメントは、IN-ADDR.ARPAおよびIP6.APRAゾーンでの逆DNS委任の管理を容易にするためのXMLスキーマを提供します。スキーマ自体には認証データは含まれず、含まれる他のすべての情報はDNSで公開されるか、WHOISなどの他の公開情報ソースに伝達されるため、公開データと見なされます。

The system that implements this XML schema requires HTTPS to be used and also uses known server and client X.509 certificates for authentication to protect against message modification, message insertion/deletion, man-in-the-middle, and replay attacks. Any DoS-type attack vectors and the authorisation of which delegations the X.509 certificate authentication sessions can affect are out of scope for this document.

このXMLスキーマを実装するシステムでは、HTTPSを使用する必要があり、メッセージの変更、メッセージの挿入/削除、中間者、およびリプレイ攻撃から保護するために、認証に既知のサーバーおよびクライアントX.509証明書を使用します。 DoSタイプの攻撃ベクトルと、X.509証明書認証セッションが影響を与える委任の承認は、このドキュメントの範囲外です。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.

[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<http：// www .rfc-editor.org / info / rfc3596>。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。

5.2. Informative References

5.2. 参考引用

[RELAXNG] The Organization for the Advancement of Structured Information Standards (OASIS), "RELAX NG Compact Syntax", November 2002, <https://www.oasis-open.org/committees/ relax-ng/compact-20021121.html>.

[RELAXNG]組織化情報標準化機構（OASIS）、「RELAX NG Compact Syntax」、2002年11月、<https://www.oasis-open.org/committees/ relax-ng / compact-20021121.html >。

[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", PhD Dissertation, University of California, Irvine, ISBN 0-599-87118-0, 2000.

[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、PhD Dissertation、University of California、Irvine、ISBN 0-599-87118-0、2000。

Appendix A. Schema Definition for rDNS Updates

付録A. rDNS更新のスキーマ定義

The following Schema, used for PUT, GET, and DELETE operations, is an XML document using the RelaxNG Compact [RELAXNG] specification.

次のスキーマは、PUT、GET、およびDELETE操作に使用され、RelaxNG Compact [RELAXNG]仕様を使用したXMLドキュメントです。

   default namespace = "http://download.research.icann.org/rdns/1.1"

# A document may either be a single zone (update) or # a collection of zones (view) start = zone | zonelist | zonereflist

＃ドキュメントは単一のゾーン（更新）または＃ゾーンのコレクション（ビュー）のいずれかです。start = zone |ゾーンリスト| zonereflist

   # A list of zone names for view only.
   zonereflist = element zonereflist {
     attribute version {
       xsd:decimal { minInclusive="1.1" fractionDigits="1" }
     },
     zoneref*
   }

   # A bulk list of zones for view only.
   zonelist = element zonelist {
     attribute version {
       xsd:decimal { minInclusive="1.1" fractionDigits="1" }
     },
     zone*
   }

   # A zone reference (accepted by REST engine for query)
   zoneref = element zoneref {
     attribute name { text },
     attribute href { xsd:anyURI }
   }

   # A single zone record
   zone = element zone {
     # The zone record's name, e.g., 10.in-addr.arpa
     attribute name { text },
     # The customer (optional); derived from known state.
     attribute cust { text }?,
     # The canonical URL for this zone record (optional)
     attribute href { xsd:anyURI }?,
     # The IP version of the address for the zone record (optional)
     attribute ipversion { "ipv4" | "ipv6" }?,
     # The administrative state of the zone (optional)
     attribute state { "active" | "pending" | "error" }?,
     # The last modified timestamp in UTC (optional)
     attribute modified  { xsd:dateTime }?,
     # The schema version (optional)
     attribute version {
       xsd:decimal { minInclusive="1.1" fractionDigits="1" }
     }?,
     # A zone NS RRset MUST have at least two NS records
     nserver,
     nserver+,
     # It MAY contain some DS records
     ds*
   }

   # DNS-SEC records
   ds = element ds {
     # rdata MUST contain
     #  <Keytag> | <Algorithm> | <Digest type> | <Digest>
     # as per RFC 4034
     #
     element rdata { text }
   }

   # A single name server
   nserver = element nserver {
     # An nserver entry MUST contain a DNS FQDN
     # for a NS RR (RFC 1035)
     element fqdn { text }
   }

Appendix B. Schema Definition for rDNS Queue Entries

付録B. rDNSキューエントリのスキーマ定義

The XML schema definition below, in RelaxNG Compact [RELAXNG] form is used for queue interaction operations.

以下のXMLスキーマ定義は、RelaxNG Compact [RELAXNG]形式で、キューの相互作用操作に使用されます。

   default namespace = "http://download.research.icann.org/rq/1.0"

# A document MAY either be a single queue entry # or a collection of queued entries start = queue | queuelist

＃ドキュメントは、単一のキューエントリ＃またはキューに入れられたエントリのコレクションのいずれかである場合があります。キューリスト

   # A list of zone names for view only.
   queuelist = element queuelist {
     attribute version {
       xsd:decimal { minInclusive="1.0" fractionDigits="0" }
     },
     queue*
   }

   # A single queued zone record
   queue = element queue {
     # The zone record's name, e.g., 10.in-addr.arpa
     attribute name { text },
     # The customer (optional); derived from known state.
     attribute cust { text }?,
     # The canonical URL for this queue record (optional)
     attribute href { xsd:anyURI }?,
     # The acknowledgement URL for this queue record (optional)
     attribute ack { xsd:anyURI }?,
     # The IP version of the address for the zone record (optional)
     attribute ipversion { "ipv4" | "ipv6" }?,
     # The state of the zone (optional); for a queue, it
     # SHOULD always be pending
     attribute state { "pending" }?,
     # The submitted timestamp (optional)
     attribute submitted  { xsd:dateTime }?,
     # The HTTP method used to update
     attribute method { "PUT" | "DELETE" },
     # The schema version (1.0) (optional)
     attribute version {
       xsd:decimal { minInclusive="1.0" fractionDigits="1" }
     }?,
     # A zone NS RRset must have at least two NS records
     nserver,
     nserver+,
     # It MAY contain some DS records
     ds*
   }

   # DNS-SEC records
   ds = element ds {
     # rdata MUST contain Flags | Protocol | Algorithm | Public Key
     # as per RFC 4034
     #
     element rdata { text }
   }

   # A single name server
   nserver = element nserver {
     # An nserver entry MUST contain a DNS FQDN
     # for a NS RR (RFC 1035)
     element fqdn { text }
   }

Acknowledgements

謝辞

An XML schema was initially provided by APNIC; however, necessity required a branch, and as such a new namespace and schema have been created. Recognition goes to APNIC for prior efforts in this area.

XMLスキーマは当初APNICによって提供されました。ただし、そのためにはブランチが必要であり、新しい名前空間とスキーマが作成されました。この分野でのこれまでの取り組みは、APNICに認められます。

The author acknowledges feedback from a collective made up of various RIR technical folk; however, heartfelt thanks goes to Anand Buddhdev of the RIPE-NCC and Robert Loomans of APNIC for being both alpha and beta testers and providing valuable feedback.

著者は、さまざまなRIR技術者で構成される集団からのフィードバックを認めます。しかし、アルファとベータの両方のテスターであり、貴重なフィードバックを提供してくれたRIPE-NCCのAnand BuddhdevとAPNICのRobert Loomansに心から感謝します。

Author's Address

著者のアドレス

Terry Manderson ICANN

テリーマンダーソンICANN

   Email: terry.manderson@icann.org