Independent Submission T. Manderson
Request for Comments: 7745 ICANN
Category: Informational January 2016
ISSN: 2070-1721
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.
本文档定义了一个可扩展标记语言（XML）模式，用于在严格控制的表示性状态传输（REST）环境中进行反向DNS管理。本文档描述了ICANN自2011年以来在“RESTful”系统中开发和部署的模式，并由负责in-ADDR.ARPA和IP6.ARPA下反向DNS（RDN）授权的注册中心通过一个由X.509证书介导的HTTPS事务使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
本文档定义了一个可扩展标记语言（XML）模式，用于在严格控制的表示性状态传输（REST）[REST]环境中进行反向DNS管理。本文档描述了ICANN自2011年以来在“RESTful”系统中开发和部署的一个模式，该模式由负责在in-ADDR.ARPA[RFC1034]和IP6.ARPA[RFC3596]下通过HTTPS[RFC2818]事务（由X.509[RFC5280]证书介导）进行反向DNS（RDN）委托的注册中心使用。
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区域中的委托进行交互的必要性变得更加频繁。在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:
应区域互联网注册中心（RIR）的请求，通过ICANN自动进行反向DNS更新，部署了基于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 允许“带外”确认和更新通知
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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.
实现的系统允许负责其RDN委托的实体通过HTTPS[RFC2818]连接向原子RESTful服务提交XML文档，从而在-ADDR.ARPA和IP6.ARPA中的反向DNS区域中进行更改。在该服务中，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）：
https://host.example.org/<ipversion>/<zone>
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.
根据附录A中的模式，提交给部署系统的XML文档的合成示例可能采用以下形式（包括所有可选属性）。
<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>
<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需要与适当的内容长度头一起发送。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.
该系统的一个要求是允许使用带外通知机制分离更新和批准。当为服务客户配置此类选项时，提交的更新可能会排队等待稍后的批准。当客户排队等待批准更新时，客户可以提交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
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>
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>是系统生成的、系统特定的值，用于标识此特定队列条目。从基于队列的操作（“队列”和“队列列表”）返回的所有XML都将按照附录B中的规范返回一个XML文档。获取“队列列表”的合成示例如下：
<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>
<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>
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.
本文档提供了一个XML模式，用于帮助管理in-ADDR.ARPA和IP6.APRA区域中的反向DNS委派。模式本身不包含身份验证数据，并且所包含的所有其他信息都被视为公共数据，因为它们要么在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证书进行身份验证，以防止消息修改、消息插入/删除、中间人攻击和重播攻击。X.509证书身份验证会话可能影响的任何DoS类型攻击向量和授权不在本文档范围内。
[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.，“TLS上的HTTP”，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，“支持IP版本6的DNS扩展”，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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[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），“RELAXNG紧凑语法”，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.
“Architectural Styles”和“基于网络的软件体系结构的设计”，博士论文，加利福尼亚大学，尔湾，ISBN 05998118-0，2000。
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"
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
#文档可以是单个区域（更新）或#区域集合（视图）开始=区域|区域列表|区域列表
# A list of zone names for view only.
zonereflist = element zonereflist {
attribute version {
xsd:decimal { minInclusive="1.1" fractionDigits="1" }
},
zoneref*
}
# 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 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 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)
# 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*
}
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 }
}
# 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 }
}
# A single name server
nserver = element nserver {
# An nserver entry MUST contain a DNS FQDN
# for a NS RR (RFC 1035)
element fqdn { text }
}
The XML schema definition below, in RelaxNG Compact [RELAXNG] form is used for queue interaction operations.
下面以RelaxNG Compact[RelaxNG]形式给出的XML模式定义用于队列交互操作。
default namespace = "http://download.research.icann.org/rq/1.0"
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
#文档可以是单个队列条目#或队列条目的集合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 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*
}
# 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 }
}
# 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 }
}
# 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技术人员组成的集体的反馈；然而，衷心感谢RIME-NCC的阿南德·布德德夫和APNIC的罗伯特·卢曼斯，感谢他们既是阿尔法和贝塔测试人员，又提供了宝贵的反馈。
Author's Address
作者地址
Terry Manderson ICANN
特里·曼德森
Email: terry.manderson@icann.org
Email: terry.manderson@icann.org