Request for Comments: 3982 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
IRIS: A Domain Registry (dreg) Type for the
Internet Registry Information Service (IRIS)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an Internet Registry Information Service
(IRIS) registry schema for registered DNS information. The schema
extends the necessary query and result operations of IRIS to provide
the functional information service needs for syntaxes and results
used by domain registries and registrars.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Query Derivatives . . . . . . . . . . . . . . . . . . . 3
3.1.1. <findRegistrarsByName> Query . . . . . . . . . . 3
3.1.2. <findDomainsByContact> Query . . . . . . . . . . 4
3.1.3. <findDomainsByName> Query . . . . . . . . . . . 4
3.1.4. <findDomainsByIDN> Query . . . . . . . . . . . . 4
3.1.5. <findContacts> Query . . . . . . . . . . . . . . 5
3.1.6. <findDomainsByHost> Query . . . . . . . . . . . 5
3.1.7. Contact Search Group . . . . . . . . . . . . . . 5
3.2. Result Derivatives . . . . . . . . . . . . . . . . . . . 6
3.2.1. Privacy Labels . . . . . . . . . . . . . . . . . 6
3.2.2. <domain> Result . . . . . . . . . . . . . . . . 7
3.2.3. <host> Result . . . . . . . . . . . . . . . . . 10
3.2.4. <contact> Result . . . . . . . . . . . . . . . . 11
3.2.5. <registrationAuthority> . . . . . . . . . . . . 13
3.3. Generic Code Derivatives . . . . . . . . . . . . . . . . 13
3.3.1. <searchTooWide> . . . . . . . . . . . . . . . . 13
3.3.2. <languageNotSupported> . . . . . . . . . . . . . 14
3.4. Support for <iris:lookupEntity> . . . . . . . . . . . . 14
4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 15
5. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 36
5.1. Message Pattern . . . . . . . . . . . . . . . . . . . . 36
5.2. Server Authentication . . . . . . . . . . . . . . . . . 36
6. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Application Service Label . . . . . . . . . . . . . . . 36
6.2. Bottom-Up Resolution . . . . . . . . . . . . . . . . . . 37
6.3. Top-Down Resolution . . . . . . . . . . . . . . . . . . 37
7. Internationalization Considerations . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8.1. XML Namespace URN Registration . . . . . . . . . . . . . 38
8.2. S-NAPTR Registration . . . . . . . . . . . . . . . . . . 39
8.3. BEEP Registration . . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 40
A. Examples of Requests and Responses . . . . . . . . . . . . . . 41
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 42
A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 43
B. An Example of Database Serialization . . . . . . . . . . . . . 47
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction
This document describes an IRIS registry schema for Internet domain
registries using an XML Schema [4] derived from and using the IRIS
[5] schema. The query and result types outlined in this document are
based on the functional requirements described in CRISP [17].
The schema given is this document is specified by using the
Extensible Markup Language (XML) 1.0, as described in XML [1]; XML
Schema notation, as described in XML_SD [3] and XML_SS [4]; and XML
Namespaces, as described in XML_NS [2].
Examples of client/server XML exchanges with this registry type are
available in Appendix A.
2. Document Terminology
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 BCP 14, RFC 2119 [10].
3. Schema Description
IRIS requires the derivation of both query and result elements by a
registry schema. These descriptions follow.
References to XML elements without a namespace qualifier are from the
schema defined in Section 4. References to elements and attributes
with the "iris" XML namespace qualifier are from the schema defined
in IRIS [5].
The descriptions contained within this section refer to XML elements
and attributes and their relation to the exchange of data within the
protocol. These descriptions also contain specifications outside the
scope of the formal XML syntax. This section will use terms defined
by RFC 2119 [10] to describe these. While reading this section,
please reference Section 4 for needed details on the formal XML
syntax.
3.1. Query Derivatives
3.1.1. <findRegistrarsByName> Query
<findRegistrarsByName> searches for a registration authority
designated as a registrar for the registry of the server.
If present, the <baseDomain> element MUST restrict the results of the
search to registrars capable of registering subdomains in the domain
signified by the content of this element.
The <namePart> element restricts the scope of the query with its
child elements. The <beginsWith> element specifies the beginning of
the registrar’s name. The <endsWith> element specifies the end of
the registrar’s name. The <exactMatch> element specifies equivalence
to the registrar’s name.
If the <namePart> element is not present, the query MUST return all
registrars applicable (i.e., in consideration of <baseDomain>).
This query MUST return a result set of zero or more
<registrationAuthority> elements. See Section 3.2.5.
3.1.2. <findDomainsByContact> Query
<findDomainsByContact> finds domains by searches on fields associated
with a domain’s contact. A search constraint of <baseDomain> MUST
restrict the results to domains underneath the domain specified by
its content, if it is present.
The allowable search fields are handled with either the
<contactHandle> element or one of the elements in the
"contactSearchGroup" (see Section 3.1.7). The <contactHandle>
element allows the domains to be selected based on the contact having
the specified contact handle.
The query MAY also be constrained further by using the optional
<role> element. The contents of this element signify the role the
contact has with the domain.
This query also provides optional <language> elements containing
language tags. Clients MAY use these elements to hint about the
natural language(s) of the affected element. Servers MAY use this
information in processing the query, such as in tailoring
normalization routines to aid in more effective searches.
3.1.3. <findDomainsByName> Query
The <findDomainsByName> query finds domains by the name of a domain
as it is known in DNS. The <namePart> element restricts the scope of
the query with its child elements. The <beginsWith> element
specifies the beginning of the domain name. The <endsWith> element
specifies the end of the domain name.
3.1.4. <findDomainsByIDN> Query
This query differs from the <findDomainsByName> query by allowing the
scope of the query to take internationalized domain names into
consideration. This query will return the union of the desired
domain and any associated variants, therefore differing from a lookup
in the "idn" entity class (Section 3.4) (which only returns the
domain or no results).
The <namePart> element restricts the scope of the query with its
child element. Its child, the <exactMatch> element, is designed to
contain IDNs and not ACE labels, and thus MUST match only against
equivalent IDNs, according to the notion of equivalence defined in
RFC 3490 [14].
This query also provides optional <language> elements containing
language tags. Clients MAY use these elements to hint about the
natural language(s) of the affected element. Servers MAY use this
information in processing the query, such as in tailoring
normalization routines to aid in more effective searches.
3.1.5. <findContacts> Query
<findContacts> searches for contacts given search constraints. The
allowable search fields are handled by one of the elements in the
"contactSearchGroup" (see Section 3.1.7).
This query also provides optional <language> elements containing
language tags. Clients MAY use these elements to hint about the
natural language(s) of the affected element. Servers MAY use this
information in processing the query, such as in tailoring
normalization routines to aid in more effective searches.
3.1.6. <findDomainsByHost> Query
This query does a simple search for the domains being hosted by a
name server. The search is constrained by using either the host name
[12], host handle, IPv4 address, or IPv6 address of the name server.
3.1.7. Contact Search Group
Some of the queries above have similar query constraints for
searching on contacts. This section describes those common
parameters.
<commonName> allows the query to be constrained based on the common
name of the contact. The constraint can constrain the query either
by an exact match using the <exactMatch> element, or by a subset of
the common name using the <beginsWith> and <endsWith> elements.
<organization> allows the query to be constrained based on the
organization name of the contact. It has the same semantics as the
<commonName> element.
<eMail> constrains the query based on the e-mail address of the
contact. This may be done by an exact e-mail address using the
<exactMatch> element or by any e-mail address in a domain using the
<inDomain> element. The <inDomain> element MUST only contain a valid
domain name (i.e., without an ’@’ symbol), and the matching SHOULD
take place only on the domain given (i.e., no partial matches with
respect to substrings or parent domains). If either the contents of
the <inDomain> element or the domain part of the contents of the
<exactMatch> element contain a name with non-ASCII characters, they
MUST be normalized according to the processes of RFC 3491 [15].
The <city>, <region>, and <postalCode> elements restrict the scope of
the query based on the city, region, or postal code of the contact,
respectively. Each must only contain an <exactMatch> element
containing the exact city, region, or postal code (i.e., no substring
searches).
3.2. Result Derivatives
3.2.1. Privacy Labels
Several of the results in this registry type have values that cannot
be given but must be specified as present or must be flagged so that
clients do not divulge them. In order to achieve this, some of the
results use the following element types:
o "dateTimePrivacyType" -- contains the XML Schema [3] data type
"dateTime". The contents of this element MUST be specified by
using the ’Z’ indicator for Coordinated Universal Time (UTC).
o "stringPrivacyType" -- contains the XML Schema [3] data type
"string".
o "normalizedStringPrivacyType" -- contains the XML Schema [3] data
type "normalizedString".
o "tokenPrivacyType" -- contains the XML Schema [3] data type
"token".
o "domainStatusType" -- contains the optional element of
<appliedDate>, indicating the date and time when the status was
applied, and the optional element of <description> with the
required attribute ’language’, indicating a description of the
status. This element also has the optional attribute ’scope’,
indicating the scope or origin of the status value.
o "contactTypeType" -- contains optional <description> child
elements. Each <description> child element requires a ’language’
attribute.
As specified, these elements can have nil values and therefore may be
present with empty content or present with their specified content.
The use of these elements is also optional.
If present without content, each of these element types MUST have one
or more of the following boolean attributes:
o ’private’ -- If true, this specifies that the content is absent
because it may never be published.
o ’denied’ -- If true, this specifies that the content is absent
because policy does not allow it to be given at the current level
of access.
If present with content, each of these element types MAY have one or
more of the following boolean attributes:
o ’doNotRedistribute’ -- If true, this specifies that the content is
not to be redistributed.
o ’specialAccess’ -- If true, this specifies that the content has
been provided due to special access rights.
These boolean attributes SHOULD be used in accordance with the level
of access granted to the recipient of the data. For example, marking
data as ’private’ or ’denied’ is to be expected if the user is
anonymous or has some other low level of access that does not warrant
viewing that particular data. Likewise, data marked with
’doNotRedistribute’ or ’specialAccess’ is to be expected if the user
is authenticated and has a high level of access.
3.2.2. <domain> Result
An example of a <domain> result:
<domain
authority="iana.org" registryType="dreg1"
entityClass="domain-handle" entityName="example-com-1">
<domainName>example.com</domainName>
<domainHandle>tcs-com-1</domainHandle>
<nameServer
iris:referentType="host"
authority="iana.org" registryType="dreg1"
entityClass="host-handle" entityName="research7" />
<nameServer
iris:referentType="host"
authority="iana.org" registryType="dreg1"
entityClass="host-handle" entityName="nsol184" />
<registry
iris:referentType="registrationAuthority"
authority="com"
registryType="dreg1"
entityClass="contact-handle"
entityName="VGRS" />
<registrar
iris:referentType="registrationAuthority"
authority="iana.org" registryType="dreg1"
entityClass="contact-handle" entityName="dbarton" />
<initialDelegationDateTime xsi:nil="true"/>
</domain>
The <domain> result represents an instance of a domain assignment.
The children of the <domain> element are as follows:
o <domainName> -- the full name of the domain as it is in DNS. The
contents of this element MUST be a domain name as specified by RFC
1035 [9].
o <idn> -- the name of the domain in nameprep form, if applicable.
See RFC 3491 [15].
o <domainHandle> -- a registry unique assigned identifier for a
domain.
o <nameServer> -- MUST contain an entity reference to a referent of
type <host> (Section 3.2.3).
o <registrant> -- contains an entity reference to the registrant of
this domain. The referent MUST be a <contact> result (Section
3.2.4).
o Domain contacts -- the following elements contain an entity
reference with a relationship to the domain. The referent of each
MUST be a <contact> (Section 3.2.4).
* <billingContacts>
* <technicalContacts>
* <administrativeContacts>
* <legalContacts>
* <zoneContacts>
* <abuseContacts>
* <securityContacts>
* <otherContacts>
o <status> -- This may contain at least one of the following
elements of type ’domainStatusType’ (see Section 3.2.1), but none
of these elements may appear more than once.
* <reservedDelegation> -- permanently inactive
* <assignedAndActive> -- normal state
* <assignedAndInactive> -- registration assigned but delegation
inactive
* <assignedAndOnHold> -- dispute
* <revoked> -- database purge pending
* <transferPending> -- change of authority pending
* <registryLock> -- on hold by registry
* <registrarLock> -- on hold by registrar
o <domainVariant> -- contains an entity reference, the referent of
which MUST be a <domain> (Section 3.2.2).
o <registrationReference> -- contains an entity reference, the
referent of which MUST be a <domain> (Section 3.2.2). This
element is intended to point to the downstream registration
reference. Therefore, if this is a result given back by a domain
registry, it should point to the domain in the domain registrar or
registrant service.
o <registry> -- contains an entity reference specifying the domain
registry operator for this domain, which MUST be a
<registrationAuthority> (Section 3.2.5). This element has an
optional boolean ’hosting’ attribute. When the value of this
attribute is positive, it indicates that the registry is
responsible for authoritatively answering DNS queries for this
domain.
o <registrar> -- contains an entity reference specifying the domain
registrar operator for this domain, which MUST be a
<registrationAuthority> (Section 3.2.5). This element has an
optional boolean ’hosting’ attribute. When the value of this
attribute is positive, it indicates that the registrar is
responsible for authoratively answering DNS queries for this
domain.
o <initialDelegationDateTime> -- contains the date and time of the
initial delegation of this domain.
o <lastRenewalDateTime> -- contains the date and time of last
renewal of this domain.
o <expirationDateTime> -- contains the date and time of the
expiration of this domain.
o <lastContactModificationDateTime> -- specifies the last time a
contact for the domain was added or removed.
o <lastContactModificationBy> -- contains an entity reference. The
referent MUST be a <contact> (Section 3.2.4) responsible for the
last addition or removal of a contact for this domain.
o <lastDelegationModificationDateTime> -- contains the date and time
of the last time one of the nameservers was added or removed for
the delegation of this domain.
o <lastDelegationModificationBy> -- contains an entity reference.
The referent MUST be a <contact> result (Section 3.2.4) and MUST
be responsible for the last addition or removal of a nameserver
for this domain.
o <lastVerificationDateTime> -- contains the date and time of the
last time the data for this domain was verified by the responsible
registration authority.
o <iris:seeAlso> -- contains an entity reference specifying a
referent indirectly associated with this domain.
3.2.3. <host> Result
An example of a <host> result:
<host
authority="iana.org" registryType="dreg1"
entityClass="host-handle" entityName="nsol184" >
<hostHandle>nsol184</hostHandle>
<hostName>a.iana-servers.net</hostName>
<ipV4Address>192.0.2.43</ipV4Address>
<hostContact
iris:referentType="contact"
authority="iana.org" registryType="dreg1"
entityClass="contact-handle" entityName="dbarton" />
</host>
The <host> element represents an instance of a host registration.
The children of the <host> element are as follows:
o <hostHandle> -- a registry unique assigned identifier for the
host.
o <hostName> -- the fully qualified domain name of the host. The
contents of this element are a domain name and MUST conform to RFC
1035 [9].
o <ipV4Address> -- the content of this MUST conform to the a valid
IP version 4 host address, as specified by RFC 791 [8].
o <ipV6Address> -- the content of this MUST conform to the a valid
IP version 6 host address, as specified by RFC 3513 [7].
o <hostContact> -- contains an entity reference specifying a contact
associated with this host. The referent MUST be <contact>
(Section 3.2.4) results.
o <createdDateTime> -- contains the date and time when this host was
created.
o <lastModificationDateTime> -- contains the date and time when this
host was last modified.
o <lastVerificationDateTime> -- contains the date and time when this
data for this host was last verified to be correct by the
appropriate registration authority.
o <iris:seeAlso> -- contains an entity reference specifying a
referent indirectly associated with this host.
3.2.4. <contact> Result
An example of a <contact> result:
<contact
authority="iana.org" registryType="dreg1"