Eric A. Hall
Consultant
INTERNET-DRAFT Andrew Newton
Document: draft-hall-ldap-whois-01.doc VeriSign, Inc.
Expires: August, 2002 February 2002
The Internet Resource Query Service
and the WHOIS Resource Schema
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document describes an architectural framework for locating
and retrieving information about network resources, using LDAPv3
for the data-formatting and query-processing services. This
document also defines LDAP schema and searching rules for four
Internet resource types: DNS domains, IPv4 addresses, IPv6
address, and AS numbers. The framework specified in this document
also allows additional documents to define additional Internet
resource types and their handling rules.
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Table of Contents
1. Abstract..................................................1
2. Definitions and Terminology...............................3
3. Background, Objectives and Overview.......................4
3.1. Background..............................................4
3.2. Overview................................................5
4. The LDAP-WHOIS Namespace..................................6
4.1. Namespace Example.......................................7
4.2. The domainComponent LDAP Hierarchy......................9
4.3. The inetResources Container............................10
4.4. Resource-Specific Entries..............................11
4.5. Redirects and Referrals................................12
5. The LDAP-WHOIS Object Classes and Attributes.............17
5.1. The inetResources Object Class.........................18
5.2. The inetDnsDomain Object Class.........................24
5.3. The inetIpv4Network Object Class.......................31
5.4. The inetIpv6Network Object Class.......................36
5.5. The inetAsNumber Object Class..........................42
5.6. The inetAssociatedResources Object Class...............47
5.7. The inetOrgPerson Object Class.........................52
5.8. The referral Object Class..............................52
5.9. Object Class and Attribute Permissions.................53
6. Search and Match Filters.................................54
6.1. Search Filter Expressions..............................55
6.2. Matching Filter Definitions............................57
7. Query Processing Models..................................62
7.1. Top-Down Processing....................................63
7.2. Bottom-Up Processing...................................67
7.3. Targeted Search Processing.............................72
7.4. Supplemental Query Processing Mechanisms...............74
8. Internationalization and Localization....................80
9. DIT Replication..........................................81
10. Transition Issues........................................82
10.1. NIC Handles............................................82
10.2. Change-Logs............................................83
10.3. Open Issues............................................83
11. Security Considerations..................................84
12. IANA Considerations......................................85
13. Author's Addresses.......................................86
14. References...............................................86
15. Changes from Previous Versions...........................87
Hall & Newton I-D Expires: August 2002 [page 2]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
2. Definitions and Terminology
This document unites, enhances and clarifies several pre-existing
technologies. Readers are expected to be familiar with the
following specifications:
RFC 2247 - Using Domains in LDAP/X.500 DNs
RFC 2251 - Lightweight Directory Access Protocol (v3)
RFC 2252 - Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions.
RFC 2254 - The String Representation of LDAP Search Filters
RFC 2256 - A Summary of the X.500(96) User Schema for use
with LDAPv3
RFC 2798 - Definition of the inetOrgPerson LDAP Object
Class
[namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named
Subordinate References in LDAP Directories
[ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
Internet Registry Directory Requirements
The following abbreviations are used throughout this document:
DIT (Directory Information Tree) - A DIT is a contained
branch of the LDAP namespace, having a root of a particular
distinguished name. "dc=example,dc=com" is used throughout
this document as one DIT, with many example entries being
stored in this DIT.
DN (Distinguished Name) - A distinguished name provides a
unique identifier for an entry, through the use of a multi-
level naming syntax. Entries are named according to their
location relevant to the root of their containing DIT. For
example, "cn=inetResources,dc=example,dc=com" is a DN which
uniquely identifies the "inetResources" entry within the
"dc=example,dc=com" DIT.
RDN (Relative DN) - An RDN provides a locally-scoped unique
identifier for an entry. A complete, globally-unique DN is
Hall & Newton I-D Expires: August 2002 [page 3]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
formed by concatenating the RDNs of an entry together. For
example, "cn=admins,cn=inetResources,dc=example,dc=com"
consists of two RDNs ("cn=admins" and "cn=inetResources")
within the "dc=example,dc=com" DIT. RDNs are typically only
referenced within their local scope.
OID (Object Identifier) - An OID is a globally-unique,
concatenated set of integers which provide a kind of
"serial number" to attributes, object classes, syntaxes and
other schema elements.
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.
3. Background, Objectives and Overview
3.1. Background
The WHOIS information service was originally provided as a network
front-end to a centralized repository of ARPANET resources and
users. Over time, multiple WHOIS information servers have been
deployed which provide similar services for Internet resources.
For example, there are scores of WHOIS servers which serve one or
more of the top-level domains ("com", "jp", etc.), with each
server providing information about the sub-domains that have been
delegated beneath each of the managed TLDs, and which also provide
information about the human operators of those domains, among
other details. Similarly, there are WHOIS servers which provide
information about different portions of the IPv4 address space.
Similarly, there are WHOIS servers which are operated by service
providers which provide information about the resources in use by
that organization and its customers. All told, there are hundreds
of WHOIS servers available on the public Internet, with each
server providing general information about the particular network
resources under the control of each organization.
Unfortunately, the WHOIS specification does not define a strict
set of data-formatting requirements, and as a result, each of the
different implementations provide information in different data
formats. Some servers provide limited amounts of unstructured
information, while others provide information in a highly-detailed
and highly-structured form. Similarly, some servers provide
information in only one language and charset, while others support
Hall & Newton I-D Expires: August 2002 [page 4]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
multiple languages and charsets, and use input switches to control
the output format. Essentially, every WHOIS server has its own
data formats and syntaxes, with little consistency between them,
which has made programmatic processing of the data difficult.
Furthermore, each WHOIS server operates as a self-contained
entity, with no knowledge or linkage between the different
servers, meaning that WHOIS servers cannot redirect clients to
other servers for additional information.
Another concern is that the WHOIS services which are being
operated today offer no means of client authentication, requiring
that server operators essentially publish all data with a single
"world-readable" permission. However, this single permission
conflicts with the privacy and security policies of specific
jurisdictions. A more flexible mechanism for controlling the
release of physical and personal information is required in order
to meet the requirements of the varying constituencies.
There are many other secondary issues with the WHOIS service as it
exists in current form. However, the largest problems are a lack
of standardized data formats, a lack of widely-supported referral
mechanisms, and lack of privacy and security controls, as
described in the preceding text.
This document attempts to address these issues by defining
operational and protocol guidelines for a distributed and highly-
structured WHOIS-like service, using the LDAP protocol for the
query/response transfer service, and using LDAP schema for the
search inputs, answer data, and redirection mechanisms. In short,
the intention of this approach is to provide an extensible and
scalable WHOIS service, leveraging the capabilities of LDAP.
3.2. Overview
This document defines four basic service components and their
interaction as part of a distributed resource-locator service.
Each of these components work together to provide a structured and
distributed resource-locator service.
The four components of this service are:
* Structured Namespace. This document makes use of an LDAP
namespace which is built upon the existing DNS delegation
hierarchy, and which is supplemented by a layered namespace
Hall & Newton I-D Expires: August 2002 [page 5]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
consisting of service-specific containers and resource-
specific entries. This namespace and the associated naming
rules facilitate the programmatic formation of queries,
structured data, and referrals.
* Schema Definitions. This document reuses many existing LDAP
schema definitions, but also introduces several new object
classes, attributes, syntaxes and matching filters. Some of
these definitions apply to the overall architecture, while
others are concerned with specific resource types.
* Searching Rules. This document defines several rules for
forming queries which are designed to facilitate consistent
answer sets, and to improve interoperability between
compliant clients and servers.
* Query Processing Models. This document defines three
distinct query-processing models which may be used for
locating the authoritative servers associated with a named
resource. These include a "top-down" model which is
designed for querying centrally-managed Internet resources,
a "bottom-up" model which is designed for querying user-
managed resources, and a "targeted search" model which is
designed for querying known servers for information about
known resources. This document also specifies protocol
behavior for following subordinate reference referrals,
continuation reference referrals, and attribute references.
It is the intention of the authors that additional resource types
will be added to this framework over time. As such, the
architecture and protocols defined in this specification are
purposefully designed to be capable of accommodating a variety of
different data-types and usage models, including future uses which
are not defined here.
4. The LDAP-WHOIS Namespace
A critical aspect of this service is the use of a predictable
naming syntax, both for the automatic creation of programmatic
searches for data, and for publishing structured data and
referrals. In order to ensure this predictability, this document
defines a multi-layered syntax which MUST be used by all compliant
implementations.
Hall & Newton I-D Expires: August 2002 [page 6]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The LDAP-WHOIS service also makes provisions for the use of
multiple referral services for the purpose of redirecting LDAP
clients to foreign directory information trees (DITs). This allows
organizations to redirect queries to external service providers,
consolidate DITs within a single server, maintain foreign objects
within a private DIT (such as allowing a third-party router to
exist as a separately managed resource within an end-user DIT),
and allows answer sets to contain responses from multiple servers.
4.1. Namespace Example
Figure 1 below shows a subset example of the LDAP-WHOIS namespace.
This namespace will be used throughout this document to illustrate
many of the concepts from this specification.
Figure 1: Namespace for Example Widgets' domain and network.
DIT: dc=example,dc=com
|
+-cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
|
+-attribute: o
| value: "Example Widgets, Inc. public network resources"
|
+-cn=example.com,cn=inetResources,dc=example,dc=com
| [top object class]
| [inetResources object class]
| [inetDnsDomain object class]
| |
| +-attribute: inetDnsContacts
| value: "ldap://ldap.example.com/cn=hostmaster,
| ou=admins,dc=example,dc=com"
|
+-cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com
| [top object class]
| [inetResources object class]
| [inetDnsDomain object class]
| |
| +-attribute: description
| | value: "Example Widgets' reverse-lookup domain"
| |
Hall & Newton I-D Expires: August 2002 [page 7]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
| +-cn=cref1,cn=2.0.192.in-addr.arpa,
| cn=inetResources,dc=example,dc=com
| [top object class]
| [inetResources object class]
| [inetDnsDomain object class]
| [referral object class]
| |
| +-attribute: ref
| value: "ldap://ldap.example.com/cn=example.com,
| cn=inetResources,dc=example,dc=com"
|
+-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
[inetResources object class]
[inetIpv4Network object class]
|
+-attribute: inetIpv4Contacts
value: "ldap://ldap.example.com/cn=hostmaster,
ou=admins,dc=example,dc=com"
DIT: dc=2,dc=0,dc=192,dc=in-addr,dc=arpa
|
+-cn=inetResources
[top object class]
[inetResources object class]
[referral object class]
|
+-attribute: ref
value: "ldap://ldap.example.com/cn=inetResources,
dc=example,dc=com"
Figure 1 shows different DITs, both of which are managed by the
Example Widgets company. The "dc=example,dc=com" DIT is
authoritative for the DNS domain of "example.com", while the
"dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for the
reverse-lookup DNS domain of 2.0.192.in-addr.arpa and the IPv4
network of "192.0.2.0/24".
Both DITs have container entries called "cn=inetResources". This
container entry is responsible for holding all of the entries
which are associated with the Internet resources that are being
managed by the LDAP-WHOIS service. For example, the
"cn=inetResources,dc=example,dc=com" entry contains a subordinate
entry for "cn=example.com", which is a DNS domain that is being
managed through the LDAP-WHOIS service, and also contains entries
for the 2.0.192.in-addr.arpa reverse-lookup DNS domain and the
192.0.2.0/24 IPv4 network.
Hall & Newton I-D Expires: August 2002 [page 8]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entry
only exists as a referral which will cause queries to be
redirected to the "cn=inetResources,dc=example,dc=com" hierarchy.
The naming syntax and rules are described throughout the remainder
of this section 4.1. Figure 1 is only provided as an example a
relatively complete namespace, for illustration and subsequent
discussion purposes.
4.2. The domainComponent LDAP Hierarchy
The top-level of the namespace defined for use with this service
uses the domainComponent naming syntax specified in RFC 2247,
which maps DNS domain names to domainComponent ("dc=") labels to
form a DIT. Each DIT represents a primary identifier for the
management body that is offering an LDAP server, and as such,
provides a primary identifier for the Internet resources under the
control of that organization. The DITs will be used to build LDAP
queries for specific resources, and will also be used to locate
the LDAP servers associated with the controlling organization.
Examples of the RFC 2247 syntax are shown in Figure 2 below.
Figure 2: The LDAP-WHOIS domainComponent Namespace.
dc=.
|
+----------------+---------------+
/ | \
dc=arpa dc=com dc=[...]
| |
+--+--+ dc=example
/ \
dc=in-addr dc=ip6
A complete sequence of domainComponent DNs represents the scope of
the DIT. For example, a DIT with the distinguished name (DN) of
"dc=com" is authoritative for all of the LDAP resources within the
"com" DNS domain (for many LDAP-WHOIS queries, this will also
include any sub-domains under the "com" domain). Meanwhile, a DIT
with the DN of "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is
authoritative for domain name resources within the reverse-lookup
"2.0.192.in-addr.arpa" DNS domain, as well as the IPv4 network
addresses within the 192.0.2.0/24 network. At the other extreme,
Hall & Newton I-D Expires: August 2002 [page 9]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
the dc="." DIT is responsible for all Internet resources (although
this DIT is rarely used).
Since the DIT determines the scope of control over a set of
resources, DITs that overlap also have overlapping scopes of
control. For example, the "dc=com" and "dc=example,dc=com" DITs
can both provide information about the "www.example.com" domain
name resource. In order to allow end-users to specify which scope
they wish to work with for any given query, this document defines
three different query models (these are described in section 7).
When the LDAP servers associated with the chosen DIT need to be
located, the domainComponent DNs from the DIT are mapped to a DNS
domain name, and a query is issued for the LDAP servers associated
with that domain name (this process is also described in section
7). This means that the authority to process LDAP searches for a
DIT comes directly from the portion of the DNS namespace already
under the control of that management body. For example, the LDAP
servers which are used to process queries for the "dc=com" DIT
will be located by querying the DNS zone responsible for the "com"
portion of the DNS namespace, and so forth.
4.3. The inetResources Container
This specification requires the use of a mandatory LDAP container
entry with the well-known relative distinguished name (RDN) of
"cn=inetResources", which MUST exist in the root of every DIT that
provides LDAP-WHOIS services. All resource-specific entries which
are provided on public LDAP-WHOIS servers MUST be stored in the
cn=inetResources container entry.
The primary motivation for this naming is for predictability, in
that it allows searches to be formed programmatically (a search
base for resources in the "dc=example,dc=com" DIT can be
programmatically formed as "cn=inetResources,dc=example,dc=com",
for example). However, there are several other motivating factors
for this naming syntax.
For example, it is easier to apply a single anonymous read-only
permission to the inetResources container than it is to apply the
same permission to multiple discrete entries, which in turn means
that it is more likely that the appropriate restrictions will be
defined. Furthermore, the use of a single container entry for all
of an organization's Internet resources allows that branch of the
DIT to be redirected to another DIT through the use of a single
Hall & Newton I-D Expires: August 2002 [page 10]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
referral operation (this will be particularly important when the
LDAP servers that are located by DNS lookups are not the same
servers that provide LDAP-WHOIS services). Another reason to use
this naming syntax is that it shelters clients from server-side
vagaries with DIT entries (where different vendors use different
object classes to define the DITs).
All told, the use of the "cn=inetResources" RDN facilitates smooth
operations, and is important enough to justify the MANDATORY usage
of this naming syntax.
4.4. Resource-Specific Entries
This document defines four Internet resource types, each of which
have their own naming rules. However, each resource type has a
consistent naming principle, in that the specific managed resource
has an RDN which uniquely identifies that resource, with the RDN
residing within the inetResources container entry.
For example, an entry for the "www.example.com" domain name
resource stored in the "dc=example,dc=com" DIT would have a DN of
"cn=www.example.com,cn=inetResources,dc=example,dc=com", while an
entry for the "192.0.2.0/24" IPv4 network resource would have a DN
of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although
the relative naming syntax is different for each resource type,
the resource naming is consistent for each type, and the position
of the RDN within the DN is also predictable.
Most resource types cannot be located through simple LDAP browsing
and equality matches. Instead, resource-specific entries use
structured naming rules in order to facilitate the extensible
match search operations which are specific to each of the defined
resource types. For example, there is not likely to be a specific
entry for every possible IPv4 address. In order to allow the
appropriate entry to be located, however, the client can use the
inetIpv4NetworkMatch extensible matching search operation, which
locates the appropriate entry based on the search input.
The naming rules associated with each resource type are provided
in section 5, along with the schema definitions for each of the
resource types. The extensible matching filters associated with
each resource type are described in section 6.
Hall & Newton I-D Expires: August 2002 [page 11]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
4.5. Redirects and Referrals
A critical objective behind this service is for servers to be able
to redirect clients to other servers, entries, or DITs, when this
is necessary or desirable. Towards this end, this document
specifies three methods for generating and processing redirects
and referrals: subordinate reference referrals, continuation
reference referrals, and attribute references.
Subordinate reference referrals indicate that the queried entry is
an alias for some other entry, and that the query has to be
restarted in order for the current operation to be completed.
Meanwhile, continuation references indicate that the search was
successfully initiated, but that additional queries are required
for the original query to be completely exhausted. Finally,
attribute references simply indicate that supplemental data is
available at some other location, but that no additional queries
are required to satisfy the current operation.
NOTE: RFC 2251 defines a superior reference referral which
is used as a "default referral" for out-of-scope searches.
However, this application specifically excludes support for
superior reference referrals. Any superior reference
referrals which are encountered as a part of this service
are to be treated as errors.
Subordinate references and continuation references use the ref
attribute and referral object class defined in [namedref].
Attribute references use a superset of the formatting rules
associated with the labeledURI attribute, as defined in RFC 2079.
All of these mechanisms use LDAP URLs as their input data,
although these URLs have service-specific restrictions that are
somewhat tighter than the source specifications allow.
Among these rules:
* All referenced entries MUST comply with the naming syntax
rules specified in this document. This means that all
entries MUST use the domainComponent ("dc=") naming syntax
for their DITs, resource-specific entries MUST reside in
the inetResources container entry, and resource-specific
entries MUST comply with the naming rules for the resource
type in question.
* Referral sources and targets MUST have the same resource-
specific object classes defined (for example, the referral
Hall & Newton I-D Expires: August 2002 [page 12]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
source and target for a DNS domain resource would both have
the inetDnsDomain object class defined). This is a
prerequisite for the proper handling of the search filters
specified in this document. Attribute references are not
referrals, so they are exempt from this requirement.
* Referenced entries MAY exist as referrals to other entries,
but recursive referrals are discouraged.
* Except where otherwise noted, the protocol identifier of a
URL MUST specify either the LDAP or LDAPS (LDAP over
TLS/SSL) service types. Although general-purpose LDAP
referrals are allowed to specify any URL, LDAP-WHOIS
referrals and references are intended to be used for
automated queries, so the use of other protocols or
services is expressly forbidden.
* The host identifier of a URL MUST specify either an IP
address or a domain name. URLs which do not provide host
identifiers are invalid in all cases.
* URLs MUST be provided and stored in a URL-safe format. For
example, the IPv4 and IPv6 network address syntaxes defined
in this document make use of the forward-slash ("/")
character to indicate a subnet prefix, and if this
character needs to be provided in a URL, it must be
provided in the escaped form ("%2F" in this example).
Furthermore, some of the matching rules described in this
document require that the URLs also be stored in this
format in order for the searches to succeed.
* Implementations MUST NOT restrict URL values to verifiable
entries from local partitions. Implementations MAY validate
targets when the partition is known and accessible, but a
lack of knowledge regarding a target MUST NOT be cause to
prevent the entry from being specified.
Clients MAY implement support for additional protocol identifiers
if they wish to act upon URLs which are provided in conflict with
the requirements above. However, clients MUST NOT violate any
other mandates in this document while doing so (in particular,
clients MUST NOT break the query-processing procedures defined in
section 7 of this document).
Each of the supported redirection mechanisms are discussed in more
detail below.
Hall & Newton I-D Expires: August 2002 [page 13]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
4.5.1. Subordinate reference referrals
Subordinate reference referrals are returned when the search base
specified in a query names an entry which exists as a referral
object class that points to some other entry.
Any of the named entries specified in section 4 of this document
MAY be defined as subordinate reference referrals which point to
other entries. However, almost all of the search functions defined
for use by this service use the inetResources container entry as
the search base (the exceptions to this rule are targeted searches
for explicit entries), so subordinate reference referrals will
most commonly be seen when an inetResources container entry has
been redirected to an inetResources container in another DIT.
For example, the namespace shown in Figure 1 has an entry of
"cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" defined
with the referral object class, with the ref attribute value
pointing to the LDAP server of "ldap.example.com" and the DN of
"cn=inetResources,dc=example,dc=com". Any queries for resources
within "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"
would be answered with that subordinate reference referral, and
these queries would have to be restarted using the specified
search base and server before they would be processed.
Servers MUST support the use of subordinate reference referrals
for this purpose, and clients MUST be prepared to accept and
process any subordinate reference referrals in answer sets.
When subordinate reference referrals are used for this purpose,
the referral source MUST be defined with the referral object
class, and MUST also be defined with the appropriate object class
for that resource type. For example, a "cn=inetResources" entry
which provided a subordinate reference referral would need to have
both the referral and inetResources object classes defined, while
a DNS domain resource such as "dc=example.com" would need to have
both the referral and inetDnsDomain object classes defined (among
the other object class definitions which were required for that
entry). Referral targets need to use whatever object classes are
appropriate for the resource in question, and MAY also be
referrals to other entries.
Client rules for processing subordinate reference referrals are
given in section 7.4.1.
Hall & Newton I-D Expires: August 2002 [page 14]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
4.5.2. Continuation reference referrals
Continuation reference referrals are returned when a search
operation has been successfully processed by the queried server,
but the answer data also includes referrals to other entries.
These referrals are often provided as supplemental data to an
answer set, although this is not required (a continuation
reference referral can be the only response, but it won't be the
only response in the common case).
For example, the namespace shown in Figure 1 has an entry of
"cn=cref1,cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,
dc=com" defined with the referral object class, with the ref
attribute value pointing to the LDAP server of "ldap.example.com"
and the DN of "cn=example.com,cn=inetResources,dc=example,dc=com".
Any answers to any queries about "cn=2.0.192.in-addr.arpa" would
also include the continuation reference referral, and new queries
for the referral target would have to be issued before the
original queries were completely processed.
Servers MUST support the use of continuation reference referrals
for this purpose, and clients MUST be prepared to accept and
process any subordinate reference referrals in answer sets.
When continuation reference referrals are used for this purpose,
entries MAY exist for the queried resource, but one or more
entries MUST exist with the referral object class defined, and
which provide LDAP URLs that point to other entries which have
additional information about the resource in question.
Continuation reference referrals are returned in response to
specific extensible match queries, and have specific naming
requirements which are necessary for the matching functions to
work properly. These considerations are described in 7.4.3.
Client rules for processing continuation reference referrals are
also given in section 7.4.3.
4.5.3. Attribute references
This document defines attribute references as attribute values
which provide LDAP or LDAPS URLs, for the purpose of providing
pointers to contextually-related information regarding the entry
Hall & Newton I-D Expires: August 2002 [page 15]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
currently being viewed. Attribute references use the same basic
syntax as the labeledURI attribute defined in RFC 2079, although
there are additional restrictions, as described above.
The contact attributes defined in this document use the attribute
reference rules and formats to provide role-specific pointers to
inetOrgPerson entries. Whenever one of these attributes is
encountered, it is up to the client to deconstruct the provided
URLs in order to locate and read the inetOrgPerson entries,
although such actions are secondary to the original query process,
and will typically only be performed at the user's request.
For example, the namespace shown in Figure 1 has an entry of
"cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" defined with
the inetIpv4Network object class, with the inetIpv4Contacts
attribute value pointing to the LDAP server of "ldap.example.com"
and the DN of "cn=hostmaster,ou=admins,dc=example,dc=com". When
this attribute is provided as part of an answer to a query, a
client MAY choose to follow this URL for information about that
contact, although this would be considered a new and separate
query, and would not be required to satisfy the original query.
Note that the attribute reference URLs are similar to the URLs
defined in RFC 2079, and use a two-part notation of
"url://any.host:port/any/path description", with the
"description" string providing a free-text description of the
target specified by the URL. When the descriptive text is provided
in an attribute reference, it SHOULD be displayed to the user as
potentially informative data.
Client rules for processing attribute references are given in
section 7.4.4.
4.5.4. labeledURI references
Some of the object classes defined in this document make use of
the labeledURI attribute, as defined by RFC 2079. These attributes
(and their values) are not governed by this document, but instead
are governed by RFC 2079. As such, the rules set forth in RFC 2079
always apply to those attributes. In particular, this means that
those attribute values may reference any protocol (such as
http://) and are not restricted to LDAP protocol targets.
Hall & Newton I-D Expires: August 2002 [page 16]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
5. The LDAP-WHOIS Object Classes and Attributes
This document defines a general framework for locating information
about public network resources in a distributed environment, and a
critical element of this definition are schema definitions for the
object classes and attributes that provide this information.
Towards that end, this document defines a schema for the global
inetResources object class which is inherited by all of the
resource-specific types, defines four resource-specific object
classes, and defines a generalized object class for cross-
referencing resources. This document also takes advantage of some
pre-existing schema definitions (in particular, the inetOrgPerson
object class), where suitable schema were available. Each of the
schema definitions provided in this document include attribute
definitions, naming rules, and other definitions which are
designed to facilitate searching and browsing Internet resources.
The following resource definitions are provided in this section:
* Organizational and summary data. The inetResources object
class defines a variety of general-purpose attributes for
describing an organization and its resources. For example,
there is a free-text attribute which may be used to provide
general comments about the organization or the resources
under its control, attributes for providing general-use
postal and email addresses, and so forth. The inetResources
object class also defines several attributes which may be
used to provide attribute references for a variety of
administrative roles.
* DNS domains. The inetDnsDomain object class is subordinate
to the inetResources object class, providing attributes for
describing a particular DNS domain, and inheriting
attributes from the inetResources object class.
* IPv4 address blocks. The inetIpv4Network object class is
also subordinate to the inetResources object class, and
provides attributes related to the management of IPv4
networks in particular.
* IPv6 address blocks. The inetIpv6Network object class
provides summary data about IPv6 networks, similar to the
data provided by the inetIpv4Network object class.
Hall & Newton I-D Expires: August 2002 [page 17]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
* Autonomous system (AS) identifiers. IPv4 and IPv6 networks
can be collectively identified as a single autonomous
system (AS), thereby allowing groups of discontiguous
address blocks to be treated as a single managed entity.
The inetAsNumber object class provides attributes for these
AS numbers, and is also subordinate to the inetResources
object class.
* Associated objects. Internet resources are typically
assigned by independent entities, although there is often
an extensive amount of cross-pollination. For example, AS
Numbers are typically associated with IPv4 and IPv6 address
blocks, with this association being considered as a
mandatory linkage. However, less-formal associations also
often exist, such as a private organization associating an
IP address block with a specific DNS domain, or where a
regional authority is responsible for all domain name and
IP address delegations. Due to this flexibility, the LDAP-
WHOIS service provides an auxiliary object class for
associated objects which may be used with any of the
resource-specific object classes defined in this document.
* Persons. This document makes use of the inetOrgPerson
object class definition for the purpose of describing
people and administrative roles.
Each of the attributes and object classes listed above represent
the Internet-wide network resources which MAY be offered by an
LDAP-WHOIS server. It is expected that additional network resource
definitions will be provided by other documents.
5.1. The inetResources Object Class
The inetResources object class is a structural object class which
defines the attributes associated with a "cn=inetResources"
container entry, and which provides general information about the
network resources associated with the current DIT.
5.1.1. Naming syntax
This document requires the presence of an entry named
"cn=inetResources" in the root of every DIT which provides LDAP-
WHOIS services.
Hall & Newton I-D Expires: August 2002 [page 18]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
5.1.2. Schema definition
Every DIT which provides public LDAP-WHOIS data MUST have a
"cn=inetResources" entry in the root of the DIT. The inetResources
entry MUST exist with the top and inetResources object classes
defined. If the entry exists as a referral, the entry MUST also be
defined with the referral object class, in addition to the above
requirements.
The inetResources object class is a structural object class which
is subordinate to the top abstract class, and which MUST be
treated as a container class capable of holding additional
subordinate entries. The inetResources object class has one
mandatory attribute which is "cn" (the naming attribute), and also
has several optional attributes. Each of the other object classes
defined by this document are subordinate to the inetResources
object class and inherit the attributes defined for the
inetResources object class.
The inetResources object class is intended to provide summary
information about a collection of resources under the control of a
single organization or management body. For example, the mail
attribute is intended to be used as a general-purpose email
address for the organization as a whole (such as
"info@example.com"), rather than being used as an email address
for a particular administrative role. Because this object class is
also inherited by the resource-specific object classes, these
attributes can be defined at each of the subordinate entries if a
global set of values is undesirable or unfeasible.
The inetResources object class provides several multi-valued
contact-related attributes for a variety of well-known
administrative roles. This model allows the inetResources entry
and each of the subordinate managed resources to share a common
set of administrative roles, or to have unique roles for each
resource, as seen fit by the managing entity. The contact
attribute values follow the same rules as the labeledURI attribute
defined in RFC 2079, with additional restrictions as described in
section 4.5 of this document.
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
Hall & Newton I-D Expires: August 2002 [page 19]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Since multiple directory trees can share a single inetResources
entry (through the use of subordinate reference referrals), it is
important for the associated data to be applicable for all of the
objects which refer to it. For example, it would be effective for
a small private company to use a shared set of inetResources
attributes for their DNS domain names and IP network blocks, but
it would probably be counter-productive for a global ISP to share
contact data across all of their hosted domains and routed
networks. If separate contacts are required for each resource, the
contact data should be specified within each entry, rather than
being linked to the inetResources entry.
The schema definition for the inetResources object class is as
follows:
inetResources
( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The
inetResources container for the LDAP-WHOIS service' SUP top
STRUCTURAL MUST cn MAY ( o $ ou $ description $
inetResourceComments $ businessCategory $ telephoneNumber $
facsimileTelephoneNumber $ mail $ labeledURI $
preferredDeliveryMethod $ physicalDeliveryOfficeName $
postOfficeBox $ postalAddress $ postalCode $ street $ l $
st $ c $ inetAbuseContacts $ inetAbuseContactsModifiedBy $
inetAbuseContactsModifiedDate $ inetGeneralContacts $
inetGeneralContactsModifiedBy $
inetGeneralContactsModifiedDate $ inetSecurityContacts $
inetSecurityContactsModifiedBy $
inetSecurityContactsModifiedDate $ inetTechContacts $
inetTechContactsModifiedBy $ inetTechContactsModifiedDate $
inetGeneralDisclaimer ) )
The attributes from the inetResources object class are described
below:
businessCategory, see RFC 2256, section 5.16
c (country), see RFC 2256, section 5.7
cn (commonName), see RFC 2256, section 5.4
description, see RFC 2256, section 5.14
facsimileTelephoneNumber, see RFC 2256, section 5.24
Hall & Newton I-D Expires: August 2002 [page 20]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetAbuseContacts
( 1.3.6.1.4.1.7161.1.0.1 NAME 'inetAbuseContacts' DESC
'Contacts for reporting abusive behavior or acceptable-use
policy violations.' EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetAbuseContactsModifiedBy
( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContactsModifiedBy'
DESC 'Person who last modified the inetAbuseContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetAbuseContactsModifiedDate
( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetAbuseContactsModifiedDate'
DESC 'Last modification date of the inetAbuseContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetGeneralContacts
( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetGeneralContacts' DESC
'Contacts for general administrative issues.' EQUALITY
caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
inetGeneralContactsModifiedBy
( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetGeneralContactsModifiedBy'
DESC 'Person who last modified the inetGeneralContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetGeneralContactsModifiedDate
( 1.3.6.1.4.1.7161.1.0.6 NAME
'inetGeneralContactsModifiedDate' DESC 'Last modification
date of the inetGeneralContacts attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 21]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetGeneralDisclaimer
( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC
'General disclaimer text regarding this data' EQUALITY
caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
inetResourceComments
( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetResourceComments' DESC
'General comments about this entry' EQUALITY
caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
inetSecurityContacts
( 1.3.6.1.4.1.7161.1.0.9 NAME 'inetSecurityContacts' DESC
'Contacts for general security issues.' EQUALITY
caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
inetSecurityContactsModifiedBy
( 1.3.6.1.4.1.7161.1.0.10 NAME
'inetSecurityContactsModifiedBy' DESC 'Person who last
modified the inetSecurityContacts attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetSecurityContactsModifiedDate
( 1.3.6.1.4.1.7161.1.0.11 NAME
'inetSecurityContactsModifiedDate' DESC 'Last modification
date of the inetSecurityContacts attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetTechContacts
( 1.3.6.1.4.1.7161.1.0.12 NAME 'inetTechContacts' DESC
'Contacts for general technical issues.' EQUALITY
caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
inetTechContactsModifiedBy
( 1.3.6.1.4.1.7161.1.0.13 NAME 'inetTechContactsModifiedBy'
DESC 'Person who last modified the inetTechContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 22]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetTechContactsModifiedDate
( 1.3.6.1.4.1.7161.1.0.14 NAME 'inetTechContactsModifiedDate'
DESC 'Last modification date of the inetTechContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
l (locality), see RFC 2256, section 5.8
labeledURI, see RFC 2079
mail, see RFC 2798, section 9.1.3
o (organization), see RFC 2256, section 5.11
ou (organizational unit), see RFC 2256, section 5.12
physicalDeliveryOfficeName, see RFC 2256, section 5.20
postalAddress, see RFC 2256, section 5.17
postalCode, see RFC 2256, section 5.18
postOfficeBox, see RFC 2256, section 5.19
preferredDeliveryMethod, see RFC 2256, section 5.29
st (stateOrProvinceName), see RFC 2256, section 5.9
street (streetAddress), see RFC 2256, section 5.10
telephoneNumber, see RFC 2256, section 5.21
5.1.3. Example
An example of the inetResources object class in use is shown in
Figure 3 below.
Hall & Newton I-D Expires: August 2002 [page 23]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Figure 3: The Example Widgets inetResources container entry.
cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
|
+-attribute: o
| value: "Example Widgets' network resources"
|
+-attribute: inetGeneralContacts
| value: "ldap://ldap.example.com/cn=admins,ou=admins,
| dc=example,dc=com"
|
+-attribute: telephoneNumber
| value: "1-800-555-1212"
|
+-attribute: mail
| value: "info@example.com"
|
+-attribute: inetResourceComments
value: "Please don't send complaints to the
postmaster@example.com mailbox."
5.2. The inetDnsDomain Object Class
The inetDnsDomain object class is a structural object class which
provides administrative information about a specific DNS domain
name resource, such as a zone, a well-known host, or some other
network resource which is primarily identified by a domain name.
5.2.1. Naming syntax
The naming syntax for DNS domain entries MUST follow the form of
"cn=<inetDnsDomainSyntax>,cn=inetResources,<dc-DIT>". Each DNS
domain name which is managed as a discrete LDAP-WHOIS resource
MUST have a dedicated entry in each of the DITs which provide
public LDAP-WHOIS data for that resource.
The inetDnsDomainSyntax component of an entry is subject to DN
rules, although the inetDnsDomainSyntax is also used for extended
search operations, and is therefore subject to specific syntax
rules. The basic rules for this format are that domain names MUST
be stored as sequences of labels, where each label consists of a
Hall & Newton I-D Expires: August 2002 [page 24]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
maximum of 63 characters, with each label being separated by a
full-stop (period) character, and with the entire domain name
sequence being a maximum of 255 characters.
For example, the "www.example.com" DNS domain name resource stored
in the "dc=example,dc=com" DIT would be represented as an entry
named "cn=www.example.com,cn=inetResources,dc=example,dc=com",
while the "2.0.192.in-addr.arpa" reverse-lookup domain which was
stored in the "dc=example,dc=com" DIT would be named
"cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com".
Note that the domain name syntax rules defined by STD 13 allow any
eight-bit character code to be used within any domain name,
although the host naming rules defined by RFC 952, STD 13 and STD
3 only allow a subset of the printable characters from US-ASCII to
be used for domain names which specify connection targets.
However, many domain names will need to be queried which will not
conform to the host naming rules ("_ldap._tcp.example.com" might
be specified in a search, for example), so any eight-bit character
MUST be considered valid for this service.
RFC 2253 defines several escaping mechanisms for use when handling
certain "special" characters, and these mechanisms MUST be used
whenever a character in a domain name needs to be escaped in order
for an assertion value to be parsed. However, STD 13 also allows
the use of special characters, and also provides several
mechanisms for escaping special characters in DNS domain names,
and these rules MUST also be accommodated if valid DNS names are
to be supported.
In order to facilitate this potential overlap while minimizing
confusion during handling, LDAP-WHOIS clients MUST allow DNS
domain name query strings to be entered as raw eight-bit data, but
if any of the characters need to be escaped for the assertion
value to be properly built, then the client MUST escape these
characters before the search is submitted.
Secondarily, if the user needs to search for a DNS domain name
which would normally require escaping or other special handling in
order for the domain name to be processed, then the user MUST
provide the domain name in its escaped form. By extension, this
also means that these DNS domain names MUST be stored as RDNs in
their escaped form.
STD 13 and RFC 2253 both use a common method of escaping special
characters with a reverse solidus (backslash) character, with
Hall & Newton I-D Expires: August 2002 [page 25]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
either the special character or a two-digit decimal code for that
character immediately following the reverse solidus.
For example, if a user needs to specify the domain name of
"weird name.example.com" (where "weird name" is a valid domain
name label with an embedded space), then the domain name would
have an RDN of "cn=weird\32name.example.com" in the directory, and
would have to be entered into the client as a search for
"weird\32name.example.com". The client would then perform a
secondary escape to form "weird\\32name.example.com" as the
assertion value, and this secondary escape would be removed by the
LDAP-WHOIS server upon receipt. Thus a match would be found.
NOTE: Remember that IPv4 addresses are also stored in DNS
for reverse-lookup purposes, and the associated zones and
PTR domain names may also require escaping, particularly
when used with site-specific CIDR notation.
The common reference to the root domain is a single full-stop
(".") character, and this usage is also endorsed by this document
when the root domain name needs to be explicitly queried. For any
domain name which contains a non-root label, the trailing period
which normally signifies the root domain MUST be omitted. The
maximum size of a valid DNS domain name is 255 characters (this
limit applies to the unescaped assertion value). Clients MUST
restrict input to this range, prior to submitting the LDAP query.
The domain name component of the DN MUST match the domain name of
the managed resource exactly as the domain name exists in the DNS
namespace. For example, if an organization wishes to provide
information about "www.example.com", then a RDN entry would need
to exist for "cn=www.example.com". If an organization wishes to
provide information about the "www.example.com" canonical target
"server1.example.net", then a RDN for "cn=server1.example.net"
would need to exist. If an organization wishes to provide
information about "server1.example.net" whenever a query is
received for "www.example.com", then the "cn=www.example.com"
entry would need to be defined as a subordinate reference
referral, with the ref attribute pointing to the
"cn=server1.example.net" entry.
This usage model also applies to reverse-lookup domains. If an
organization is the authority for the "2.0.192.in-addr.arpa"
reverse-lookup domain associated with an IPv4 network (this is
different from providing information about the network block in
particular, as is discussed separately in section 5.3), then that
Hall & Newton I-D Expires: August 2002 [page 26]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
syntax would also be used to form the RDN for the associated
inetDnsDomain entry.
Note that reverse-lookup domain names are mapped directly as they
exist in the public DNS namespace. If a /24 IPv4 network block
such as 192.0.2.0 has been delegated to an organization, the
default controlling domain name of the reverse-lookup zone will be
2.0.192.in-addr.arpa, and the name of the associated LDAP-WHOIS
entry would be "cn=2.0.192.in-addr.arpa". However, if that network
had been delegated to an ISP who had in turn delegated the
192.0.2.0/29 address block and an associated reverse-lookup zone
of 29-0.2.0.192.in-addr.arpa to a user, then the associated LDAP-
WHOIS entry for that zone would be "cn=29-0.2.0.192.in-addr.arpa".
5.2.2. Schema definition
DNS domain name entries MUST exist with the top, inetResources and
inetDnsDomain object classes defined. If an entry exists as a
referral, the entry MUST also be defined with the referral object
class, in addition to the above requirements.
The inetDnsDomain object class is a structural object class which
is subordinate to the inetResources object class, and which MUST
be treated as a container class capable of holding additional
subordinate entries. The inetDnsDomain object class has no
mandatory attributes, although it does have several optional
attributes.
The inetDnsDomain object class defines attributes which are
specific to DNS domains, particularly as this relates to domain
delegation (DNS operational information is available through DNS
itself). This includes information such as the delegation date and
the status of the delegation. The inetDnsDomain object class is
subordinate to the inetResources object class, so it inherits
those attributes as well.
Some of the inetDnsDomain object class attributes define contact-
related referrals which provide LDAP URLs that refer to
inetOrgPerson entries, and these entries will need to be queried
separately if detailed information about a particular contact is
required. The contact attribute values follow the same rules as
the labeledURI attribute defined in RFC 2079, with additional
restrictions as described in section 4.5 of this document.
Hall & Newton I-D Expires: August 2002 [page 27]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
The schema definition for the inetDnsDomain object class is as
follows:
inetDnsDomain
( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS
domain attributes.' SUP inetResources STRUCTURAL MAY (
inetDnsDelegationStatus $ inetDnsDelegationDate $
inetDnsDelegationModifiedDate $ inetDnsDelegationModifiedBy
$ inetDnsContacts $ inetDnsContactsModifiedBy $
inetDnsContactsModifiedDate $ inetDnsAuthServers ) )
The attributes from the inetDnsDomain object class are described
below:
inetDnsAuthServers
( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC
'Authoritative DNS servers for this domain.' EQUALITY
caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The inetDnsAuthServers attribute provides a read-only
summary of the authoritative servers associated with the
zone. The attribute is defined as multi-valued, with each
attribute value currently (tentatively) being defined as:
domain.dom [address/prefix]
where "domain.dom" is the domain name of the authoritative
server, written as an inetDnsDomainSyntax string, and where
"address/prefix" is an IPv4 or IPv6 host-specific network
address, written as either an inetIpv4NetworkSyntax or
inetIpv6NetworkSyntax string. Clients that wish to obtain
additional information about the listed servers can issue
new queries for either the domain name or address syntax.
NOTE: THIS IS A TEMPORARY ATTRIBUTE WHICH WILL EVENTUALLY
BE REPLACED WITH GENERALIZED RESOURCE-RECORD ENTRIES AND
ATTRIBUTES.
Hall & Newton I-D Expires: August 2002 [page 28]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetDnsContacts
( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContacts' DESC
'Contacts for reporting problems with this domain name.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetDnsContactsModifiedBy
( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedBy'
DESC 'Person who last modified the inetDnsContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetDnsContactsModifiedDate
( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsContactsModifiedDate'
DESC 'Last modification date of the inetDnsContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetDnsDelegationDate
( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsDelegationDate' DESC
'Date of original delegation.' EQUALITY
GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
inetDnsDelegationModifiedBy
( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsDelegationModifiedBy'
DESC 'Person who last modified the inetDnsDelegationStatus
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetDnsDelegationModifiedDate
( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDelegationModifiedDate'
DESC 'Last modification date of the inetDnsDelegationStatus
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetDnsDelegationStatus
( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDelegationStatus' DESC
'Current delegation status code for this domain.' EQUALITY
Hall & Newton I-D Expires: August 2002 [page 29]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2}
SINGLE-VALUE )
NOTE: In an effort to facilitate internationalization and
programmatic processing, the current status of a delegation
is identified by a 16-bit integer. The values and status
mapping is as follows:
0 Reserved delegation (permanently inactive)
1 Assigned and active (normal state)
2 Assigned but not yet active (new delegation)
3 Assigned but on hold (disputed)
4 Assignment revoked (database purge pending)
Additional values for the inetDnsDelegationStatus attribute
are reserved for future use, and are to be administered by
IANA. Note that there is no status code for "unassigned";
unassigned entries SHOULD NOT exist, and SHOULD NOT be
returned as answers.
The inetDnsDomainSyntax syntax is as follows:
inetDnsDomainSyntax
( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A
fully-qualified DNS domain name.' )
5.2.3. Example
An example of the inetDnsDomain object class in use is shown in
Figure 4 below, with some additional attributes inherited from the
parent inetResources entry. This query is most likely being sent
to the LDAP servers responsible for operating the "example.com"
DNS domain.
Figure 4: The example.com inetDnsDomain entry.
cn=example.com,cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
[inetDnsDomain object class]
|
+-attribute: description
| value: "The example.com DNS domain"
|
Hall & Newton I-D Expires: August 2002 [page 30]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
+-attribute: inetDnsContacts
| value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
| dc=example,dc=com"
|
+-attribute: inetGeneralContacts
value: "ldap://ldap.example.com/cn=admins,ou=admins,
dc=example,dc=com"
5.3. The inetIpv4Network Object Class
The inetIpv4Network object class is a structural object class
which provides administrative information about a specific IPv4
address and an associated subnet prefix (this pairing is most
often used to represent the starting address of an IPv4 network,
but can also be used to identify a specific host).
5.3.1. Naming syntax
The naming syntax for IPv4 network entries MUST follow the form of
"cn=<inetIpv4NetworkSyntax>,cn=inetResources,<dc-DIT>". Each IPv4
network address which is managed as a discrete LDAP-WHOIS network
resource MUST have a dedicated entry in each of the DITs which
provide public LDAP-WHOIS data regarding that network address.
The inetIpv4NetworkSyntax component of an entry is subject to DN
rules, although the inetIpv4NetworkSyntax is also used for
extended search operations, and is therefore subject to specific
syntax rules. The inetIpv4NetworkSyntax specifically requires the
use of the starting address from a range of inclusive addresses,
and specifically requires the use of CIDR prefix annotation. In
this manner, it is possible to create an inetIpv4Network entry for
a range of addresses (by specifying the starting address and the
network prefix size), or a single host (by specifying the host-
specific address and a /32 prefix).
In this definition, inetIpv4NetworkSyntax uses the traditional
"dotted-quad" notation, where each of four sub-components provide
a decimal value that represents one octet from a 32-bit IPv4
address, with the sub-components being separated by a full-stop
(period) character, and with the four-part sequence being followed
by a "/" character and a three-digit decimal "prefix" value. An
augmented BNF for this syntax is as follows:
Hall & Newton I-D Expires: August 2002 [page 31]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetIpv4NetworkSyntax = vFourPart "." vFourPart "." vFourPart
"." vFourPart "/" vFourPrefix
vFourPart = decimal value between "0" and "255" inclusive,
with the non-affective leading zeroes removed
vFourPrefix = decimal value between "1" and "32" inclusive,
with the non-affective leading zeroes removed
For example, an IPv4 network with a range of addresses between
"10.0.0.0" and "10.0.255.255" inclusive would be written as
"10.0.0.0/16", and would appear with an RDN of "cn=10.0.0.0/16".
Similarly, a host address of "192.0.2.14" would have the RDN of
"cn=192.0.2.14/32".
The leading zeroes from each octet MUST be removed during query
string formation. Octets which have a value of zero MUST be
represented by the single-digit numeric value of "0".
Note that the use of "/" is illegal in LDAP URLs when it is
provided as data (in particular, URLs use this character as a part
delimiter). This character MUST be escaped as "%2F" when it is
provided as part of an inetIpv4Network entry in a ref attribute.
5.3.2. Schema definition
IPv4 network entries MUST exist with the top, inetResources and
inetIpv4Network object classes defined. If an entry exists as a
referral, the entry MUST also be defined with the referral object
class, in addition to the above requirements.
The inetIpv4Network object class is a structural object class
which is subordinate to the inetResources object class, and which
MUST be treated as a container class capable of holding additional
subordinate entries. The inetIpv4Network object class has no
mandatory attributes, although it does have several optional
attributes.
The inetIpv4Network object class defines attributes which are
specific to IPv4 networks, such as the delegation date and the
status of the delegation. The inetIpv4Network object class is
subordinate to the inetResources object class, so it inherits
those attributes as well.
Hall & Newton I-D Expires: August 2002 [page 32]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Some of the inetIpv4Network object class attributes define
contact-related referrals which provide LDAP URLs that refer to
inetOrgPerson entries, and these entries will need to be queried
separately if detailed information about a particular contact is
required. The contact attribute values follow the same rules as
the labeledURI attribute defined in RFC 2079, with additional
restrictions as described in section 4.5 of this document.
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
The schema definition for the inetIpv4Network object class is as
follows:
inetIpv4Network
( 1.3.6.1.4.1.7161.1.2.0 NAME 'inetIpv4Network' DESC 'IPv4
network attributes.' SUP inetResources STRUCTURAL MAY (
inetIpv4DelegationStatus $ inetIpv4DelegationDate $
inetIpv4DelegationModifiedDate $
inetIpv4DelegationModifiedBy $ inetIpv4Contacts $
inetIpv4ContactsModifiedBy $ inetIpv4ContactsModifiedDate $
inetIpv4RoutingContacts $ inetIpv4RoutingContactsModifiedBy
$ inetIpv4RoutingContactsModifiedDate ) )
The attributes from the inetIpv4Network object class are described
below:
inetIpv4Contacts
( 1.3.6.1.4.1.7161.1.2.2 NAME 'inetIpv4Contacts' DESC
'Contacts for reporting problems with this IPv4 network.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetIpv4ContactsModifiedBy
( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy'
DESC 'Person who last modified the inetIpv4Contacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 33]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetIpv4ContactsModifiedDate
( 1.3.6.1.4.1.7161.1.2.4 NAME 'inetIpv4ContactsModifiedDate'
DESC 'Last modification date of the inetIpv4Contacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetIpv4DelegationDate
( 1.3.6.1.4.1.7161.1.2.5 NAME 'inetIpv4DelegationDate' DESC
'Date of original delegation.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
inetIpv4DelegationModifiedBy
( 1.3.6.1.4.1.7161.1.2.6 NAME 'inetIpv4DelegationModifiedBy'
DESC 'Person who last modified the inetIpv4DelegationStatus
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetIpv4DelegationModifiedDate
( 1.3.6.1.4.1.7161.1.2.7 NAME
'inetIpv4DelegationModifiedDate' DESC 'Last modification
date of the inetIpv4DelegationStatus attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetIpv4DelegationStatus
( 1.3.6.1.4.1.7161.1.2.8 NAME 'inetIpv4DelegationStatus' DESC
'Current delegation status code for this network.' EQUALITY
numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2}
SINGLE-VALUE )
Hall & Newton I-D Expires: August 2002 [page 34]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
NOTE: In an effort to facilitate internationalization and
programmatic processing, the current status of a delegation
is identified by a 16-bit integer. The values and status
mapping is as follows:
0 Reserved delegation (permanently inactive)
1 Assigned and active (normal state)
2 Assigned but not yet active (new delegation)
3 Assigned but on hold (disputed)
4 Assignment revoked (database purge pending)
Additional values for the inetIpv4DelegationStatus
attribute are reserved for future use, and are to be
administered by IANA. Note that there is no status code for
"unassigned"; unassigned entries SHOULD NOT exist, and
SHOULD NOT be returned as answers.
inetIpv4RoutingContacts
( 1.3.6.1.4.1.7161.1.2.9 NAME 'inetIpv4RoutingContacts' DESC
'Contacts for routing issues with this IPv4 network.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetIpv4RoutingContactsModifiedBy
( 1.3.6.1.4.1.7161.1.2.10 NAME
'inetIpv4RoutingContactsModifiedBy' DESC 'Person who last
modified the inetIpv4RoutingContacts attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetIpv4RoutingContactsModifiedDate
( 1.3.6.1.4.1.7161.1.2.11 NAME
'inetIpv4RoutingContactsModifiedDate' DESC 'Last
modification date of the inetIpv4RoutingContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 35]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The inetIpv4NetworkSyntax syntax is as follows:
inetIpv4NetworkSyntax
( 1.3.6.1.4.1.7161.1.2.1 NAME 'inetIpv4NetworkSyntax' DESC
'An IPv4 address and prefix.' )
5.3.3. Example
An example of the inetIpv4Network object class is shown in Figure
5 below, with attributes from the inetResources object class also
being used to provide administrative contacts. This data is a
result of a query which was sent to the LDAP servers responsible
for operating the "192.0.2.0/24" network block.
Figure 5: The 192.0.2.0/24 inetIpv4Network entry.
cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
[inetIpv4Network object class]
|
+-attribute: description
| value: "The example.com network"
|
+-attribute: inetIpv4Contacts
| value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
| dc=example,dc=com"
|
+-attribute: inetGeneralContacts
value: "ldap://ldap.example.com/cn=admins,ou=admins,
dc=example,dc=com"
As stated earlier, reverse-lookup DNS domains for IPv4 address
blocks are managed as inetDnsDomain object class entries. These
are entirely different network resources, and should not be
confused with inetIpv4Network object class entries.
5.4. The inetIpv6Network Object Class
The inetIpv6Network object class is a structural object class
which provides administrative information about a specific IPv6
address and an associated subnet prefix (this pairing is most
Hall & Newton I-D Expires: August 2002 [page 36]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
often used to represent the starting address of an IPv6 network,
but can also be used to identify a specific host).
5.4.1. Naming syntax
The naming syntax for IPv6 network entries MUST follow the form of
"cn=<inetIpv6NetworkSyntax>,cn=inetResources,<dc-DIT>". Each IPv6
network address which is managed as a discrete LDAP-WHOIS network
resource MUST have a dedicated entry in each of the DITs which
provide public LDAP-WHOIS data regarding that network address.
The inetIpv6NetworkSyntax component of an entry is subject to DN
rules, although the inetIpv6NetworkSyntax is also used for
extended search operations, and is therefore subject to specific
syntax rules. This syntax specifically requires the use of the
starting address from a range of inclusive addresses, and
specifically requires the use of the common IPv6 prefix
annotation. In this manner, it is possible to create an
inetIpv6Network entry for a range of addresses (by specifying the
starting address and the network prefix size), or a single host
(by specifying the host-specific address and a /128 prefix).
In this definition, the inetIpv6NetworkSyntax uses the
uncompressed, 32-nibble IPv6 addressing syntax, where the network
address consists of eight sub-components, with each sub-component
consisting of four hexadecimal values that represent one nibble,
with each sub-component being separated by a colon character, and
with the entire sequence being followed by a "/" character and a
three-digit decimal "prefix" value. An augmented BNF for this
syntax is as follows:
inetIpv6NetworkSyntax = vSixPart ":" vSixPart ":" vSixPart
":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":"
vSixPart "/" vSixPrefix
vSixPart = 4*4nibblePart
nibblePart = hexadecimal digit between "0" and "F" inclusive
vSixPrefix = decimal value between "1" and "128" inclusive,
with the non-affective leading zeroes removed
Hall & Newton I-D Expires: August 2002 [page 37]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
For example, an IPv6 network with a range of addresses between
"3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff"
inclusive would have a RDN of
"cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". Similarly, a host
address of "3ffe:ffff::1:2:3:4" would have the RDN of
"cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128".
Each of the 16-bit colon-separated values MUST be written in the
uncompressed form. Nibbles with a value of zero MUST be
represented by the hexadecimal sequence of "0000".
Note that the use of "/" is illegal in LDAP URLs when it is
provided as data (in particular, URLs use this character as a part
delimiter). This character MUST be escaped as "%2F" when it is
provided as part of an inetIpv6Network entry in a ref attribute.
5.4.2. Schema Definition
IPv6 network entries MUST exist with the top, inetResources and
inetIpv6Network object classes defined. If an entry exists as a
referral, the entry MUST also be defined with the referral object
class, in addition to the above requirements.
The inetIpv6Network object class is a structural object class
which is subordinate to the inetResources object class, and which
MUST be treated as a container class capable of holding additional
subordinate entries. The inetIpv6Network object class has no
mandatory attributes, although it does have several optional
attributes.
The inetIpv6Network object class defines attributes which are
specific to IPv6 networks, such as the delegation date and the
status of the delegation. The inetIpv6Network object class is
subordinate to the inetResources object class, so it inherits
those attributes as well.
Some of the inetIpv6Network object class attributes define
contact-related referrals which provide LDAP URLs that refer to
inetOrgPerson entries, and these entries will need to be queried
separately if detailed information about a particular contact is
required. The contact attribute values follow the same rules as
the labeledURI attribute defined in RFC 2079, with additional
restrictions as described in section 4.5 of this document.
Hall & Newton I-D Expires: August 2002 [page 38]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
The schema definition for the inetIpv6Network object class is as
follows:
inetIpv6Network
( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6
network attributes.' SUP inetResources STRUCTURAL MAY (
inetIpv6DelegationStatus $ inetIpv6DelegationDate $
inetIpv6DelegationModifiedDate $
inetIpv6DelegationModifiedBy $ inetIpv6Contacts $
inetIpv6ContactsModifiedBy $ inetIpv6ContactsModifiedDate $
inetIpv6RoutingContacts $ inetIpv6RoutingContactsModifiedBy
$ inetIpv6RoutingContactsModifiedDate ) )
The attributes from the inetIpv6Network object class are described
below:
inetIpv6Contacts
( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC
'Contacts for reporting problems with this network.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetIpv6ContactsModifiedBy
( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6ContactsModifiedBy'
DESC 'Person who last modified the inetIpv6Contacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetIpv6ContactsModifiedDate
( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6ContactsModifiedDate'
DESC 'Last modification date of the inetIpv6Contacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 39]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetIpv6DelegationDate
( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6DelegationDate' DESC
'Date of original delegation.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
inetIpv6DelegationModifiedBy
( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy'
DESC 'Person who last modified the inetIpv6DelegationStatus
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetIpv6DelegationModifiedDate
( 1.3.6.1.4.1.7161.1.3.7 NAME
'inetIpv6DelegationModifiedDate' DESC 'Last modification
date of the inetIpv6DelegationStatus attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetIpv6DelegationStatus
( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6DelegationStatus' DESC
'Current delegation status code for this network.' EQUALITY
numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2}
SINGLE-VALUE )
NOTE: In an effort to facilitate internationalization and
programmatic processing, the current status of a delegation
is identified by a 16-bit integer. The values and status
mapping is as follows:
0 Reserved delegation (permanently inactive)
1 Assigned and active (normal state)
2 Assigned but not yet active (new delegation)
3 Assigned but on hold (disputed)
4 Assignment revoked (database purge pending)
Additional values for the inetIpv6DelegationStatus
attribute are reserved for future use, and are to be
administered by IANA. Note that there is no status code for
"unassigned"; unassigned entries SHOULD NOT exist, and
SHOULD NOT be returned as answers.
Hall & Newton I-D Expires: August 2002 [page 40]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetIpv6RoutingContacts
( 1.3.6.1.4.1.7161.1.3.9 NAME 'inetIpv6RoutingContacts' DESC
'Contacts for routing issues with this network.' EQUALITY
caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
inetIpv6RoutingContactsModifiedBy
( 1.3.6.1.4.1.7161.1.3.10 NAME
'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last
modified the inetIpv6RoutingContacts attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetIpv6RoutingContactsModifiedDate
( 1.3.6.1.4.1.7161.1.3.11 NAME
'inetIpv6RoutingContactsModifiedDate' DESC 'Last
modification date of the inetIpv6RoutingContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
The inetIpv6NetworkSyntax syntax is as follows:
inetIpv6NetworkSyntax
( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC
'An IPv6 address and prefix.' )
5.4.3. Example
An example of the inetIpv6Network object class is shown in Figure
6 below, with attributes from the inetResources object class also
being used to provide administrative contacts. This data is a
result of a query which was sent to the LDAP servers responsible
for operating the ip6.arpa delegation domain.
Hall & Newton I-D Expires: August 2002 [page 41]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Figure 6: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32
inetIpv6Network delegation entry.
cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32,
cn=inetResources,dc=ip6,dc=arpa
[top object class]
[inetResources object class]
[inetIpv6Network object class]
|
+-attribute: description
| value: "The example.net top-level network"
|
+-attribute: inetIpv6Contacts
| value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
| dc=example,dc=net"
|
+-attribute: inetGeneralContacts
value: "ldap://ldap.example.com/cn=admins,ou=admins,
dc=example,dc=net"
Reverse-lookup DNS domains for IPv6 address blocks are managed as
inetDnsDomain object class entries which are entirely different
network resources, and which should not be confused with the
inetIpv6Network object class entries. Note that due to the 128-bit
address size and the structuring rules defined in RFC 1886, a
fully-formed IPv6 reverse-lookup domain name will have 34 labels,
which can result in very large distinguished names.
5.5. The inetAsNumber Object Class
The inetAsNumber object class is a structural object class which
provides administrative information about a specific autonomous
system (AS) number. AS numbers are used to identify routing
domains, allowing multiple discontiguous IPv4 and IPv6 network
blocks to be referenced with a single, globally-unique identifier.
5.5.1. Naming syntax
The naming syntax for AS number entries MUST follow the form of
"cn=<inetAsNumberSyntax>,cn=inetResources,<dc-DIT>". Each AS
number which is managed as a discrete LDAP-WHOIS network resource
MUST have a dedicated entry in each of the DITs which provide
public LDAP-WHOIS data regarding that autonomous system.
Hall & Newton I-D Expires: August 2002 [page 42]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The inetAsNumberSyntax component of an entry is subject to DN
rules, although the inetAsNumberSyntax is also used for search and
compare operations, and is therefore subject to specific syntax
rules. The AS number syntax uses the decimal equivalent of a 16-
bit autonomous system number, with the non-affective leading
zeroes removed. An augmented BNF for this syntax is as follows:
inetAsNumberSyntax = decimal value between "0" and "65535"
inclusive, with the non-affective leading zeroes removed
For example, an entry for AS number "1" from the "dc=arin,dc=net"
DIT would have a DN of "cn=1,cn=inetResources,dc=arin,dc=net",
while an entry for AS number "65535" from the same DIT would have
a DN of "cn=65535,cn=inetResources,dc=arin,dc=net".
5.5.2. Schema definition
AS number entries MUST exist with the top, inetResources and
inetAsNumber object classes defined. If an entry exists as a
referral, the entry MUST also be defined with the referral object
class, in addition to the above requirements.
The inetAsNumber object class is a structural object class which
is subordinate to the inetResources object class, and which MUST
be treated as a container class capable of holding additional
subordinate entries. The inetAsNumber object class has no
mandatory attributes, although it does have several optional
attributes.
The inetAsNumber object class defines attributes which are
specific to autonomous systems and their associated routing
domains, such as the delegation date, and the status of the
delegation. The inetAsNumber object class is subordinate to the
inetResources object class, so it inherits those attributes as
well.
Some of the inetAsNumber object class attributes define contact-
related referrals which provide LDAP URLs that refer to
inetOrgPerson entries, and these entries will need to be queried
separately if detailed information about a particular contact is
required. The contact attribute values follow the same rules as
the labeledURI attribute defined in RFC 2079, with additional
restrictions as described in section 4.5 of this document.
Hall & Newton I-D Expires: August 2002 [page 43]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
The network-specific attributes MUST only contain network
addresses which are directly associated with the AS number, and
MUST use the largest superior prefix delegated to those networks
(using the inetIpv4NetworkSyntax and inetIpv6NetworkSyntax rules);
these attributes MUST NOT contain host or subnet addresses which
are subordinate to another value which is already listed, and
these attributes MUST NOT contain network addresses of networks
which are associated with any other AS number.
The schema definition for the inetAsNumber object class is as
follows:
inetAsNumber
( 1.3.6.1.4.1.7161.1.4.0 NAME 'inetAsNumber' DESC 'Autonomous
system attributes.' SUP inetResources STRUCTURAL MAY (
inetAsnDelegationStatus $ inetAsnDelegationDate $
inetAsnDelegationModifiedDate $ inetAsnDelegationModifiedBy
$ inetAsnContacts $ inetAsnContactsModifiedBy $
inetAsnContactsModifiedDate $ inetAsnRoutingContacts $
inetAsnRoutingContactsModifiedBy $
inetAsnRoutingContactsModifiedDate ) )
The attributes from the inetIpv4Network object class are described
below:
inetAsnContacts
( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC
'Contacts for reporting problems with this routing domain.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetAsnContactsModifiedBy
( 1.3.6.1.4.1.7161.1.4.3 NAME 'inetAsnContactsModifiedBy'
DESC 'Person who last modified the inetAsnContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 44]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetAsnContactsModifiedDate
( 1.3.6.1.4.1.7161.1.4.4 NAME 'inetAsnContactsModifiedDate'
DESC 'Last modification date of the inetAsnContacts
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetAsnDelegationDate
( 1.3.6.1.4.1.7161.1.4.5 NAME 'inetAsnDelegationDate' DESC
'Date of original delegation.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
inetAsnDelegationModifiedBy
( 1.3.6.1.4.1.7161.1.4.6 NAME 'inetAsnDelegationModifiedBy'
DESC 'Person who last modified the inetAsnDelegationStatus
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetAsnDelegationModifiedDate
( 1.3.6.1.4.1.7161.1.4.7 NAME 'inetAsnDelegationModifiedDate'
DESC 'Last modification date of the inetAsnDelegationStatus
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetAsnDelegationStatus
( 1.3.6.1.4.1.7161.1.4.8 NAME 'inetAsnDelegationStatus' DESC
'Current delegation status code for this AS number.'
EQUALITY numericStringMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE )
Hall & Newton I-D Expires: August 2002 [page 45]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
NOTE: In an effort to facilitate internationalization and
programmatic processing, the current status of a delegation
is identified by a 16-bit integer. The values and status
mapping is as follows:
0 Reserved delegation (permanently inactive)
1 Assigned and active (normal state)
2 Assigned but not yet active (new delegation)
3 Assigned but on hold (disputed)
4 Assignment revoked (database purge pending)
Additional values for the inetIpv6DelegationStatus
attribute are reserved for future use, and are to be
administered by IANA. Note that there is no status code for
"unassigned"; unassigned entries SHOULD NOT exist, and
SHOULD NOT be returned as answers.
inetAsnRoutingContacts
( 1.3.6.1.4.1.7161.1.4.9 NAME 'inetAsnRoutingContacts' DESC
'Contacts for routing issues with this IPv4 network.'
EQUALITY caseExactMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
inetAsnRoutingContactsModifiedBy
( 1.3.6.1.4.1.7161.1.4.10 NAME
'inetAsnRoutingContactsModifiedBy' DESC 'Person who last
modified the inetAsnRoutingContacts attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetAsnRoutingContactsModifiedDate
( 1.3.6.1.4.1.7161.1.4.11 NAME
'inetAsnRoutingContactsModifiedDate' DESC 'Last
modification date of the inetAsnRoutingContacts attribute.'
EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
The inetAsNumberSyntax syntax is as follows:
inetAsNumberSyntax
( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetAsNumberSyntax' DESC 'An
autonomous system number.' )
Hall & Newton I-D Expires: August 2002 [page 46]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
5.5.3. Example
An example of the inetAsNumber object class is shown in Figure 7
below, with attributes from the inetResources object class also
being used to provide administrative contacts. This data is a
result of a query which was sent to the LDAP servers associated
with the "arin.net" domain.
Figure 7: The inetAsNumber delegation entry for AS 65535.
cn=65535,cn=inetResources,dc=arin,dc=net
[top object class]
[inetResources object class]
[inetAsNumber object class]
|
+-attribute: description
| value: "The example.net network"
|
+-attribute: inetAsnContacts
| value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
| dc=example,dc=net"
|
+-attribute: inetGeneralContacts
value: "ldap://ldap.example.com/cn=admins,ou=admins,
dc=example,dc=net"
5.6. The inetAssociatedResources Object Class
The inetAssociatedResources object class defines cross-reference
attributes which may be used with any of the object classes
defined in this document. For example, it allows inetDnsDomain
object class entries to be associated with IPv4 networks, or even
to other DNS domains, if that information is known (this
information may be useful if a single organization has multiple
DNS domains registered). Furthermore, it allows inetOrgPerson
object classes to be associated with managed resources such as IP
networks or DNS domains. In short, any resource can be associated
with any other resource through the use of this object class.
The inetAssociatedResources object class MUST NOT be associated
with an entry that only exists as a referral source.
Hall & Newton I-D Expires: August 2002 [page 47]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
5.6.1. Naming syntax
The inetAssociatedResources object class is an auxiliary object
class, and not a structural object class. Entries which use this
object class definition are primarily defined under the rules
associated with the structural object class that defines the
Internet resource in question. As such, the naming rules
associated with the structural object class in use with that entry
take precedence. Therefore, the inetAssociatedResources object
class does not define a naming syntax.
5.6.2. Schema definition
The inetAssociatedResources object class is an auxiliary object
class which is subordinate to the top object class. The
inetAssociatedResources object class has no mandatory attributes,
although it does have several optional attributes.
Although the inetAssociatedResources object class is subordinate
to the top object class, it is intended to only be associated with
the resource-specific structural object classes defined in this
document. For example, the inetAssociatedResources object class is
not likely to provide much value when it is associated with the
inetResources object class, since the inetResources object class
does not specifically define any resources (and since it does not
define resources, it cannot define any associated resources). On
the other hand, it is reasonable for the inetAssociatedResources
object class to be associated with an inetOrgPerson object class
entry, particularly if the referenced person (or role) is
responsible for the management of multiple resources.
Each of the associated resource attributes provide multi-valued
data, using the syntax notations which are specific to the
resource in question. For example, the inetAssociatedDnsDomain
attribute provides associated DNS domain name resources using a
multi-valued array, with each DNS domain name using the
inetDnsDomainSyntax naming rules.
The various ModifiedBy and ModifiedDate attributes SHOULD be
treated as operational attributes. Their values SHOULD be filled
in automatically by the database management application, and
SHOULD NOT be returned except when explicitly requested.
Hall & Newton I-D Expires: August 2002 [page 48]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The schema definition for the inetAssociatedResources object class
is as follows:
inetAssociatedResources
( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC
'Network resources associated with this entry.' SUP top
AUXILIARY MAY ( inetAssociatedDnsDomains $
inetAssociatedDnsDomainsModifiedBy $
inetAssociatedDnsDomainsModifiedDate $
inetAssociatedIpv4Networks $
inetAssociatedIpv4NetworksModifiedBy $
inetAssociatedIpv4NetworksModifiedDate $
inetAssociatedIpv6Networks $
inetAssociatedIpv6NetworksModifiedBy $
inetAssociatedIpv6NetworksModifiedDate $
inetAssociatedAsNumbers $
inetAssociatedAsNumbersModifiedBy $
inetAssociatedAsNumbersModifiedDate ) )
The attributes from the inetAssociatedResources object class are
described below:
inetAssociatedAsNumbers
( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC
'The autonomous system numbers associated with this entry.'
EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax )
inetAssociatedAsNumbersModifiedBy
( 1.3.6.1.4.1.7161.1.5.3 NAME
'inetAssociatedAsNumbersModifiedBy' DESC 'Person who last
modified the inetAssociatedAsNumbers attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetAssociatedAsNumbersModifiedDate
( 1.3.6.1.4.1.7161.1.5.4 NAME
'inetAssociatedAsNumbersModifiedBy' DESC 'Last modification
date of the inetAssociatedAsNumbers attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 49]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetAssociatedDnsDomains
( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedDnsDomains' DESC
'The DNS domains associated with this entry.' EQUALITY
caseIgnoreMatch SYNTAX inetDnsDomainSyntax )
inetAssociatedDnsDomainsModifiedBy
( 1.3.6.1.4.1.7161.1.5.6 NAME
'inetAssociatedDnsDomainsModifiedBy' DESC 'Person who last
modified the inetAssociatedDnsDomains attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetAssociatedDnsDomainsModifiedDate
( 1.3.6.1.4.1.7161.1.5.7 NAME
'inetAssociatedDnsDomainsModifiedBy' DESC 'Last
modification date of the inetAssociatedDnsDomains
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetAssociatedIpv4Networks
( 1.3.6.1.4.1.7161.1.5.8 NAME 'inetAssociatedIpv4Networks'
DESC 'The IPv4 networks associated with this entry.'
EQUALITY caseIgnoreMatch SYNTAX inetIpv4NetworkSyntax )
inetAssociatedIpv4NetworksModifiedBy
( 1.3.6.1.4.1.7161.1.5.9 NAME
'inetAssociatedIpv4NetworksModifiedBy' DESC 'Person who
last modified the inetAssociatedIpv4Networks attribute.'
EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetAssociatedIpv4NetworksModifiedDate
( 1.3.6.1.4.1.7161.1.5.10 NAME
'inetAssociatedIpv4NetworksModifiedDate' DESC 'Last
modification date of the inetAssociatedIpv4Networks
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
Hall & Newton I-D Expires: August 2002 [page 50]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetAssociatedIpv6Networks
( 1.3.6.1.4.1.7161.1.5.11 NAME 'inetAssociatedIpv6Networks'
DESC 'The IPv6 networks associated with this entry.'
EQUALITY caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax )
inetAssociatedIpv6NetworksModifiedBy
( 1.3.6.1.4.1.7161.1.5.12 NAME
'inetAssociatedIpv6NetworksModifiedBy' DESC 'Person who
last modified the inetAssociatedIpv6Networks attribute.'
EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetAssociatedIpv6NetworksModifiedDate
( 1.3.6.1.4.1.7161.1.5.13 NAME
'inetAssociatedIpv6NetworksModifiedDate' DESC 'Last
modification date of the inetAssociatedIpv6Networks
attribute.' EQUALITY generalizedTimeMatch ORDERING
generalizedTimeOrderingMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
5.6.3. Example
An example of the inetAssociatedResources object class is shown in
Figure 8 below.
Figure 8: The inetAssociatedResources attributes associated with
the 192.0.2.0/24 IPv4 network entry.
cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
[inetIpv4Network object class]
[inetAssociatedResources object class]
|
+-attribute: description
| value: "The example.com network"
|
+-attribute: inetAssociatedAsNumbers
| value: "65535"
|
Hall & Newton I-D Expires: August 2002 [page 51]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
+-attribute: inetAssociatedDnsDomains
value: "example.com"
5.7. The inetOrgPerson Object Class
This document provides several contact-related attributes which
use LDAP URLs to reference inetOrgPerson entries. Whenever one of
these contact attributes are returned, a separate query for the
inetOrgPerson entry associated with the contact attribute will be
required if the details of that contact are needed. In order to
facilitate programmatic access to this data, LDAP URLs provided in
contact attributes MUST refer to entries which use the
inetOrgPerson object class, MUST refer to an entry in a DIT which
uses the domainComponent object class syntax ("dc="), and MUST
specify the LDAP or LDAPS protocol-types for the URL.
The model put forth in this document allows each contact attribute
to refer to a variable number of contacts. In this model, a query
for a contact attribute MAY return a variable number of LDAP URLs,
and each of these contacts can then be queried individually. This
allows for multiple explicit contacts per role, while also
providing predictable naming and query structures.
The target entries MAY exist anywhere in the LDAP hierarchy (as
long as they follow the domainComponent naming syntax). It is
expected that pre-existing inetOrgPerson entries will be used for
this purpose. If this is not desirable or feasible, then an entry
MUST be created which meets the minimum requirements defined in
this document. Regardless of where the entry is located, the
target inetOrgPerson entries MUST conform with the schema
specification defined in RFC 2798.
The target inetOrgPerson entries MAY have any number of attributes
defined, with any number of access restrictions, as required by
local security policies, government regulations or personal
privacy concerns. However, the mail attribute MUST be defined,
MUST be valid, and MUST have anonymous read permissions.
Furthermore, all of the attributes MUST be secured against
anonymous add, delete and modify permissions.
5.8. The referral Object Class
This document allows the use of the referral object class to
define subordinate reference referrals and continuation reference
Hall & Newton I-D Expires: August 2002 [page 52]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
referrals for inetResources container entries and all of the
resource-specific entries.
Referral entries MUST conform to the schema specification defined
in [namedref]. In particular, referral entries MUST NOT contain
any user-definable attributes other than the mandatory "cn" naming
attribute and the mandatory "ref" operational attribute. By
extension, referral entries MUST be leaf nodes, and MUST NOT have
any subordinate entries defined at the referral source.
Furthermore, in order to facilitate programmatic access to this
data, LDAP URLs provided in ref attributes MUST refer to entries
which use the same object classes as the source entry, MUST refer
to an entry in a DIT which uses the domainComponent object class
syntax ("dc="), and MUST specify the LDAP or LDAPS protocol-types
for the URL.
5.9. Object Class and Attribute Permissions
The information presented through the LDAP-WHOIS service will be
used for many operational and problem-resolution purposes. In
order for this information to be suitable for this purpose, it
must be accurate. In order to ensure the veracity of the
information, a minimal set of operational guidelines are provided
in this section. For the most part, these rules are designed to
prevent unauthorized modifications to the data.
Note that these rules only apply to data which is willingly
provided; no data is required to be entered, but where the data is
provided, it MUST be accurate, and it MUST be secured against
unauthorized modifications.
* The inetResources container entry and all of the resource-
specific subordinate entries within every public DIT that
provides LDAP-WHOIS resources SHOULD have anonymous read-
only access permissions, and SHOULD NOT have anonymous add,
delete or modify permissions.
* With the exception of contact-related attributes from the
inetOrgPerson object class, each attribute MAY have
whatever restrictions are necessary in order to suit local
security policies, government regulations or personal
privacy concerns. When the inetOrgPerson object class is
used to provide contact details, the mail attribute MUST be
defined, SHOULD be valid, SHOULD have read-only anonymous
Hall & Newton I-D Expires: August 2002 [page 53]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
access, and SHOULD NOT have anonymous add, delete or modify
permissions.
By using the inetOrgPerson object class, it is expected
that existing contact-related entries can be reused. If
reusing these entries is undesirable or unfeasible, entries
with the necessary access SHOULD be made available.
Note that contact pointers are entirely optional and are
not required to exist. However, where they exist, they MUST
comply with the above requirements.
* End-users and implementers SHOULD provide anonymous access
to the creatorsName, createTimestamp, modifiersName and
modifyTimestamp operational attributes associated with each
entry in the inetResources branch, since this information
is useful for determining the age of the information.
* Server managers MAY define additional add, delete or modify
permissions for authenticated users, using any LDAPv3
authentication mechanisms they wish. In particular,
delegation entities MAY provide for the remote management
of delegated resources (such as assigning modification
privileges to the managers of a particular delegated domain
or address block), although this is entirely optional, and
is within the sole discretion of the delegation body.
External applications SHOULD NOT make critical decisions based on
the information provided through this service without having
reason to trust the veracity of the information. Clients and users
SHOULD limit the use of unknown or untrusted information to
routine purposes.
6. Search and Match Filters
LDAP search filters are fairly flexible, in that they allow for a
wide variety of configurable elements, such as the maximum number
of entries which are returned, the type of comparison operation
that needs to be performed, and other details. In order to promote
interoperability, default values are defined here for many of
these elements, although these defaults are only applicable when
they are used with the LDAP-WHOIS service.
In particular, this document defines several suggested and
mandatory search filter qualifiers, which are described in detail
Hall & Newton I-D Expires: August 2002 [page 54]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
in section 6.1. This document also defines extensibleMatch filter
definitions which MUST be implemented whenever the associated
resource types defined in this document are implemented by an
LDAP-WHOIS client or server. These filter definitions are provided
in section 6.2 below.
6.1. Search Filter Expressions
Section 4.5.1 of RFC 2251 defines the LDAP search request
specification, although it does not provide guidelines or
recommended values for the filter settings. In an effort to
promote interoperability among LDAP-WHOIS clients and servers,
this document defines some recommended and mandatory values for
searches within the LDAP-WHOIS service.
NOTE: These rules ONLY apply to the LDAP-WHOIS search
operations in particular. Any queries for other resources
(such as requests for inetOrgPerson contact entries) MUST
NOT impose these restrictions. Also note that other
documents which define additional resource types can also
define different restrictions, and those definitions will
take preference over these guidelines.
Generic LDAP clients may be used to browse and search for data,
and in those cases, these rules are not likely to be followed. As
such, servers MUST be prepared to enforce these rules
independently of the client settings.
The values of an LDAP search filter should be as follows:
* Search base. The DIT to be used in a search will vary for
each query operation. The methodology for determining the
current search base for a query is defined by the query-
processing protocols described in section 7, although LDAP-
WHOIS searches are normally constrained to the
"cn=inetResources" container of a particular DIT.
* Scope. In order to support continuation reference referrals
(which are defined as referral entries beneath a resource-
specific entry), clients MUST use a sub-tree scope for
LDAP-WHOIS searches. Servers MUST NOT arbitrarily limit the
scope of search operations.
* Dereference aliases. Although the LDAP-WHOIS service does
not make direct use of alias entries, they are not
Hall & Newton I-D Expires: August 2002 [page 55]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
prohibited. Clients SHOULD set the Dereference Aliases
option to "Always" for LDAP-WHOIS searches. Servers SHOULD
dereference any aliases which are encountered, where this
is feasible (in particular, where the alias refers to
another DIT on the same server).
* Size limit. The size limit field specifies the maximum
number of entries that a server should return. For the
LDAP-WHOIS service, this setting SHOULD be set to a value
between 25 and 100. This range ensures that the client is
capable of receiving a sufficient number of entries and
continuation references in a single response, but also
works to prevent runaway queries that match everything
(such as searches for "com", which can match every
inetDnsDomain entry in the "cn=inetResources,dc=com"
container). Servers MAY truncate answer sets to 100
responses if the client specifies a larger value.
* Time limit. The time limit field specifies the maximum
number of seconds that a server should process the search.
For the LDAP-WHOIS service, this setting SHOULD be set to a
value between 10 and 60 seconds. This range ensures that
the server is able to process a sufficient number of
entries, but also works to prevent runaway queries that
match everything. Servers MAY stop processing queries after
60 seconds if the client specifies a larger value.
* Types-only. The types-only setting is a Boolean flag which
controls whether or not attribute values are returned in
the answer sets. Since excessive queries are likely to be
more burdensome than larger answer sets, this setting
SHOULD be set to FALSE. Resource-constrained clients (such
as PDAs) MAY set this value to TRUE, but these clients MUST
be prepared to issue the necessary subsequent queries.
* Filter. The search operation will depend on the type of
data being queried. For LDAP-WHOIS queries, the filter MUST
use the matching rules defined in section 6.2 for the
relevant resource type. Other resource-specific documents
may define their own handling rules.
Note that the extensible match filters defined in this
document MUST be supported by LDAP-WHOIS clients and
servers. LDAP-WHOIS servers MAY also support additional
sub-string filters, soundex filters, or any other filters
they wish (these may be required for generic LDAP clients),
Hall & Newton I-D Expires: August 2002 [page 56]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
although LDAP-WHOIS clients MUST NOT expect any additional
filters to be available.
* Attribute list. Clients MAY restrict the list of attributes
which are returned in searches, but are discouraged from
doing so without cause.
6.2. Matching Filter Definitions
Each of the object classes defined in this document have their own
search criteria which MUST be used whenever a collection of
resource pools need to be searched. In this model, resource types
are specified during the search operation, and most of the
resource types have extensibleMatch definition which are used
whenever the available resources need to be searched.
For example, if a user wishes to find the inetIPv4network object
class entry associated with a specific IPv4 address, then the
inetIpv4NetworkMatch extensibleMatch filter MUST be specified by
the client, and MUST be used by the server when attempting to
locate the relevant inetIpv4Network entry.
This document defines unique extensibleMatch filters for three of
the four resource-specific object classes which are also defined
herein: inetDnsDomain, inetIpv4Network, and inetIpv6Network. The
inetResources, inetAsNumber and inetOrgPerson object classes can
be searched with simple equalityMatch filters, and do not require
dedicated extensibleMatch filters, although they do have specific
handling rules which are discussed below.
6.2.1. inetDnsDomainMatch
The inetDnsDomainMatch filter provides an identifier and search
string format which collectively inform a queried server that a
specific DNS domain name should be searched for, and that any
matching inetDnsDomain object class entries should be returned.
The inetDnsDomainMatch extensibleMatch filter is defined as
follows:
inetDnsDomainMatch
( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDomainMatch' SYNTAX
inetDnsDomainSyntax )
Hall & Newton I-D Expires: August 2002 [page 57]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The assertion value MUST be a valid DNS domain name, using the
inetDnsDomainSyntax syntax rules defined in section 5.2.
The server MUST compare the assertion value against the RDN of all
entries in the inetResources container which have an object class
of inetDnsDomain. Any entry for a DNS domain resource which is
clearly superior to the DNS domain name provided in the input
string MUST be returned to the client. Entries which do not
encompass the queried domain name MUST NOT be returned. Entries
which do not have an object class of inetDnsDomain MUST NOT be
returned.
For example, assume that the client has issued a query with the
assertion value of "www.example.com". If the queried server has an
inetDnsDomain object class entry with a DN of
"cn=example.com,cn=inetResources,dc=com", then that entry would be
returned to the client. Similarly, a continuation reference
referral of "cn=cref1,cn=example.com,cn=inetResources,dc=com"
would also be returned, since it has a "cn" component that is
superior to the queried domain name, and has the inetDnsDomain
object class.
Domain names MUST be compared on label boundaries, and MUST NOT be
qualified through simple character matching. Given two entries of
"cn=example.com" and "cn=an-example.com", only the first would
match an assertion value of "example.com".
Using the notation format described in RFC 2254, the search filter
expression for the inetDnsDomainMatch query above would be written
as "(1.3.6.1.4.1.7161.1.1.9:=www.example.com)".
Response entries MAY be fully-developed inetDnsDomain entries, or
MAY be referrals generated from entries which have the
inetDnsDomain and referral object classes defined. Any attribute
values which are received MUST be displayed by the client. If a
subordinate reference referral is received, the client MUST
restart the query, using the provided data as the new search base.
If any continuation reference referrals are received, the client
SHOULD start new queries for each reference, and append the output
of those queries to the original query's output.
6.2.2. inetIpv4NetworkMatch
The inetIpv4NetworkMatch filter provides an identifier and search
string format which collectively inform a queried server that a
Hall & Newton I-D Expires: August 2002 [page 58]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
specific IPv4 address should be searched for, and that any
matching inetIpv4network object class entries should be returned.
NOTE: IPv4 addresses are also stored in DNS for reverse-
lookups, and those entries are treated as inetDnsDomain
object class entries rather than being treated as
inetIpv4Network object class entries (they are treated as
DNS zones with their own operational administrators). As
such, those entries use the inetDnsDomainMatch query
described in section 6.2.1.
The inetIpv4NetworkMatch extensibleMatch filter is defined as
follows:
inetIpv4NetworkMatch
( 1.3.6.1.4.1.7161.1.2.12 NAME 'inetIpv4NetworkMatch' SYNTAX
inetIpv4NetworkSyntax )
The assertion value MUST be an IPv4 address, using the
inetIpv4NetworkSyntax defined in section 5.3. Clients MUST provide
assertion values in this syntax. If an input string does not match
this syntax, the client MAY attempt to manipulate the input string
such that an appropriate assertion value can be formed. For
example, if a user enters a traditional IPv4 address without
specifying a prefix value, the client MAY append "/32" to the end
of the input string to form a valid assertion value. Similarly, if
a user provides an octal or hexadecimal value, the client MAY
attempt to convert the input string to the traditional dotted-quad
IPv4 address notation.
The server MUST compare the assertion value against the RDN of all
entries in the inetResources container which have an object class
of inetIpv4Network. Any entry for an IPv4 network resource which
is clearly superior to the IPv4 address provided in the input
string MUST be returned to the client. Superiority in this case
means exactly what it sounds like: the address range specified by
the inetIpv4Network object class entry (as determined by the
network number and the prefix combination of the entry's RDN) MUST
define a range of IPv4 addresses which encompasses the IPv4
address specified in the query, and any such entry MUST be
returned in the response message. Entries which do not encompass
the queried address MUST NOT be returned. Entries which do not
have an object class of inetIpv4Network MUST NOT be returned.
For example, assume that the client is submitting a search for
"192.0.2.14/32", with the search base of "dc=in-addr,dc=arpa". The
Hall & Newton I-D Expires: August 2002 [page 59]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
queried server may only have an inetIpv4Network entry for
"cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa", and as such
that would be the only entry returned. However, the server could
also have multiple entries which matched the queried IPv4 address,
such as "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa" and
"cn=192.0.2.0/24,cn=inetResources,dc=in-addr,dc=arpa", both of
which reflected specific delegations.
Similarly, a query for this IPv4 address which was sent to the
LDAP servers responsible for the operational network could result
in "cn=192.0.2.8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" and
"cn=192.0.2.14/32,dc=8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"
entries being returned to the client (assuming the subnet
allocation policy of the network reflected this usage, and that
there was an explicit entry for the IPv4 address in question).
Using the notation format described in RFC 2254, the search filter
expression for the inetDnsDomainMatch query above would be written
as "(1.3.6.1.4.1.7161.1.2.12:=192.0.2.14/32)".
Response entries MAY be fully-developed inetIpv4Network entries,
or MAY be referrals generated from entries which have the
inetIpv4Network and referral object classes defined. Any attribute
values which are received MUST be displayed by the client. If a
subordinate reference referral is received, the client MUST
restart the query, using the provided data as the new search base.
If any continuation reference referrals are received, the client
SHOULD start new queries for each reference, and append the output
of those queries to the original query's output.
6.2.3. inetIpv6NetworkMatch
The inetIpv6NetworkMatch filter provides an identifier and search
string format which collectively inform a queried server that a
specific IPv6 address should be searched for, and that any
matching inetIpv6network object class entries should be returned.
NOTE: IPv6 addresses are also stored in DNS for reverse-
lookups, and those entries are treated as inetDnsDomain
object class entries rather than being treated as
inetIpv6Network object class entries (they are treated as
DNS zones with their own operational administrators). As
such, those entries use the inetDnsDomainMatch query
described in section 6.2.1.
Hall & Newton I-D Expires: August 2002 [page 60]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
The inetIpv6NetworkMatch extensibleMatch filter is defined as
follows:
inetIpv6NetworkMatch
( 1.3.6.1.4.1.7161.1.4.19 NAME 'inetIpv6NetworkMatch' SYNTAX
inetIpv6NetworkSyntax )
The assertion value MUST be an IPv6 address, using the
inetIpv6NetworkSyntax defined in section 5.4. Clients MUST provide
assertion values in this syntax. If an input string does not match
this syntax, the client MAY manipulate the input string to form a
valid assertion value. For example, if a user provides a zero-
compressed IPv6 address such as 3ffe:ffff::, the client MAY
convert the input value to the inetIpv6NetworkSyntax form of
"3ffe:ffff:0000:0000:0000:0000:0000:0000/32".
The server MUST compare the assertion value against the RDN of all
entries in the inetResources container which have an object class
of inetIpv6Network. Any entry for an IPv6 network resource which
is clearly superior to the IPv6 address provided in the input
string MUST be returned to the client. Entries which do not
encompass the queried address MUST NOT be returned. Entries which
do not have an object class of inetIpv6Network MUST NOT be
returned.
Using the notation format described in RFC 2254, the search filter
expression for the inetDnsDomainMatch query above would be written
as "(1.3.6.1.4.1.7161.1.4.19:=
3ffe:ffff:0000:0000:0000:0000:0000:0000/32)".
Response entries MAY be fully-developed inetIpv6Network entries,
or MAY be referrals generated from entries which have the
inetIpv6Network and referral object classes defined. Any attribute
values which are received MUST be displayed by the client. If a
subordinate reference referral is received, the client MUST
restart the query, using the provided data as the new search base.
If any continuation reference referrals are received, the client
SHOULD start new queries for each reference, and append the output
of those queries to the original query's output.
6.2.4. inetResources, inetAsNumber and inetOrgPerson equalityMatch
DNS domains and IP addresses have specific subordinate delegation
properties which require special processing rules as described
above. Conversely, the inetResources, inetAsNumber and
Hall & Newton I-D Expires: August 2002 [page 61]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetOrgPerson object classes do not have this inheritance problem,
and these entries can be searched using relatively simple
equalityMatch filters.
In order to ensure that all of the relevant entries (including any
referrals) are found, the search filters for these resources MUST
specify two distinct elements: the object class of the resource
being queried, and the naming element of the resource specified as
a distinguished name attribute.
For example, using the notation format described in RFC 2254, the
search filter expression for the inetOrgPerson entry associated
with "cn=admins,ou=admins,dc=example,dc=com" would be structured
as "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", using
"ou=admins,dc=example,dc=com" as the search base. This would find
all entries with the object class of inetOrgPerson (including all
of the referral entries for inetOrgPerson entries) where the
distinguished name contained the "cn" attribute of "admins".
Similarly, a query for "(&(objectclass=inetAsNumber)(cn:dn:1))"
with a search base of "cn=inetResources,dc=example,dc=com" would
find all of the inetAsNumber object class entries associated with
AS number "1" in the LDAP-WHOIS branch of "dc=example,dc=com".
The input source and search base for these matches will vary
according to the query being processed, but whenever an
equalityMatch is called for during query processing, the above
methods MUST be used in order to ensure that all of the related
entries are located.
Response entries MAY be fully-developed entries, or MAY be
referrals generated from entries which have the referral object
class defined. Any attribute values which are received MUST be
displayed by the client. If a subordinate reference referral is
received, the client MUST restart the query, using the provided
data as the new search base. If any continuation reference
referrals are received, the client SHOULD start new queries for
each reference, and append the output of those queries to the
original query's output.
7. Query Processing Models
The LDAP-WHOIS service uses three different query-processing
models. These are the "top-down" model which initiates the query
process at the top-level of a DNS delegation hierarchy, a "bottom-
Hall & Newton I-D Expires: August 2002 [page 62]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
up" model which directs queries to user-managed servers, and a
"targeted" search model which is functionally identical to
traditional LDAP searches. Furthermore, any of these mechanisms
may be redirected to other servers, either through simple DNS
query processing, or by way of LDAP redirections (including
subordinate reference referrals, continuation reference referrals,
attribute references, or labeledURI attributes).
Each of the three query models are appropriate to different usage
environments. For example, the top-down model is best suited for
searches about global resources which are centrally managed and
delegated (such as IP addresses and DNS domains), and where
delegation information is a critical element of the resource data.
Meanwhile, the bottom-up model is most appropriate for those
resources which are managed by the end-users directly, and which
are not managed from a centralized delegation authority (this
includes information such as private keys, mail servers, and other
leaf-node resources). Finally, the targeted model is best suited
for explicit queries where a particular resource is supposed to
exist with a known DN (such as with contact pointers).
LDAP-WHOIS clients and servers MUST implement all three models.
Clients MUST default to using the top-down model, but clients MUST
also provide a user-selectable option for the disposition of
individual queries.
7.1. Top-Down Processing
The top-down model is primarily suited for locating Internet
resources which are centrally managed and delegated. The top-down
model is similar to other distributed WHOIS protocols in this
regard, with the principle difference being the use of LDAP for
standardized syntaxes, data and referrals, rather than using a
specialized protocol specifically for this application.
The top-down model uses an input string to construct an LDAP
assertion value and search base, with DNS queries being used to
locate the LDAP servers associated with the appropriate top-level
delegation entity. Once this process completes, an extensible
match query is issued to the specified servers. The query may also
be redirected through the use of LDAP referrals, if additional
data is known to exist elsewhere.
For example, a top-down search for the domain name of
"www.example.com" would result in the client building an
Hall & Newton I-D Expires: August 2002 [page 63]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetDnsDomainMatch extensible match query with the search base of
"cn=inetResources,dc=com", and with the client issuing a DNS query
for the LDAP servers associated with "com" domain. If the queried
server had information about the "www.example.com" resource, it
would be returned as answer data. If the server knew of other
sources of information about the resource (such as the registrar
for the domain, or the entity operating the domain, or both),
continuation reference referrals could be returned. Any of the
subsequent queries could return additional answers and/or
referrals, according to the data they had.
IP address blocks and AS numbers are processed in a similar
fashion. If a client needed to locate information about the
"192.0.2.14/32" IPv4 address, it would begin the process by
building a reverse-lookup DNS domain name from the input string,
and then issuing a DNS query for the LDAP servers associated with
the "arpa" top-level domain. Once a server had been located, an
LDAP query with the assertion value of "192.0.2.14/32" would be
submitted with a search base of "cn=inetResources,dc=arpa". The
server would return data and/or referrals, with this process
repeating until the query string had been completely processed.
Note that entries for the inetResources and inetOrgPerson object
classes are not searchable with this model, since they do not have
centralized delegation authorities. One of the other search models
MUST be used for those resource types.
7.1.1. Processing steps
The steps for processing top-down queries are described below:
a. Determine the input type (DNS Domain, IPv4 Address, etc.)
b. Determine the authoritative domain name for the query.
1. Separate the input string into discrete elements where
this is possible. For a DNS domain name of
"www.example.com", this would be "www", "example" and
"com". For the IPv4 network number of "192.0.2.14",
this would be "192", "0", "2" and "14". AS numbers
only have a single value and require no separation. Do
not discard the original query string.
2. IP addresses and AS numbers require additional
conversion. For IPv4 addresses, strip off the prefix
Hall & Newton I-D Expires: August 2002 [page 64]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
and convert the input string into a reverse-lookup DNS
domain name by reversing the order of the octets and
appending "in-addr.arpa" to the right of the domain
name. For IPv6 addresses, strip off the prefix and
reverse the nibble order of the address (where each
nibble is represented by a single hexadecimal
character), and append "ip6.arpa". For AS numbers,
append only the "arpa" domain name.
c. Form the LDAP search base for the query.
1. Convert the right-most element from the domain name
formed in step 7.1.1.b above into a domainComponent DN
(such as "dc=com" or "dc=arpa"). This represents the
DIT for the current query.
2. Append the "cn=inetResources" RDN to the front of the
domainComponent syntax ("cn=inetResources,dc=com").
This will form the fully-qualified search base for the
LDAP query.
d. Locate the LDAP servers associated with the resource by
processing the domain name formed in step 7.1.1.b above
through the SRV query steps provided in section 7.4.5.
e. If the SRV lookup succeeds:
1. Choose the best LDAP server, using the weighting
formula described in RFC 2782.
2. Construct the LDAP search filter according to the
rules specified in section 6.1, using the appropriate
matching rule from section 6.2.
3. Formulate the LDAP search using the search base and
search filter constructed above. For example, if the
input query string was for "www.example.com", then the
client would begin the process by submitting an
inetDnsDomainMatch extensibleMatch search with the
assertion value of "www.example.com", and with a
search base of "dc=inetResources,dc=com". Similarly,
if the input query string was "192.0.2.14", then the
client would begin the process by submitting an
inetIpv4NetworkMatch extensibleMatch search with the
assertion value of "192.0.2.14/32", and with the
search base of "cn=inetResources,dc=arpa".
Hall & Newton I-D Expires: August 2002 [page 65]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
4. Submit the search operation to the chosen server and
port number. If the operation fails, report the
failure to the user and exit. Otherwise, display any
answer data which is returned.
5. If the answer data contains a subordinate reference
referral or a continuation reference referral, new
query processes MUST be spawned.
For subordinate reference referrals, process the URLs
according to the rules described in section 7.4.1 and
restart the query process at step 7.1.1.e.2. For each
continuation reference referral, display the answer
data received so far, process the LDAP URLs according
to the rules described in section 7.4.3 and start new
query processes for each referral at step 7.1.1.e.2,
appending the output from these searches to the
current output.
Any additional subordinate reference referrals or
continuation reference referrals which are encountered
from any subsequent searches will need to be processed
in the same manner as specified above, until no
additional referrals are received.
f. If the SRV lookup fails (where failure is defined as any
DNS response message other than an answer), report the
failure to the user and exit the current search operation.
7.1.2. Top-Down example
In the example below, the user has entered a search string of
"www.example.com" and has indicated that the query is for a DNS
domain name.
a. The input string is broken into the discrete label
components ("www", "example" and "com").
b. The right-most label ("com") is used to form the DNS SRV
lookup ("_ldap._tcp.com"), in order to find the LDAP
servers authoritative for the delegation hierarchy.
c. One of the LDAP servers is contacted, and an
inetDnsDomainMatch search filter is submitted with the
Hall & Newton I-D Expires: August 2002 [page 66]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
assertion value of "www.example.com" and a search base of
"cn=inetResources,dc=com".
d. The server responds with a continuation reference referral
URL of "ldap://ldap.netsol.com/cn=example.com,
cn=inetResources,dc=netsol,dc=com", indicating that the
domain delegation is managed under the "dc=netsol,dc=com"
DIT, and is hosted at the "ldap.netsol.com" server. The
client uses this information to start a new query. No
additional data was provided for the client to display.
e. An inetDnsDomainMatch extensibleMatch search is submitted
to "ldap.netsol.com", using the search base of
"cn=example.com,cn=inetResources,dc=netsol,dc=com".
f. The queried server returns the information that it has. No
additional referrals are provided. The client displays the
data and exits the query.
7.2. Bottom-Up Processing
The bottom-up model is best used when a leaf-node resource needs
to be queried, and where an LDAP-WHOIS server is expected to be
able to answer the query. In this case, navigating down through a
delegation hierarchy would be either fruitless or inefficient. For
example, information about a mail domain would be more efficient
in the bottom-up model, since there is no global delegation body
for Internet mail (the DNS domains are delegated, but the message
routing is specific to the operational entities responsible for
the domain name). The bottom-up model can also be used for DNS
domain names, IPv4 addresses, and IPv6 addresses, although this
will generally prove to be less useful than top-down queries,
given the limited number of user-managed servers deployed.
The bottom-up model uses an input string to construct an LDAP
assertion value and search base, with DNS queries being used to
locate the LDAP servers which are associated with the management
entity that is directly responsible for the resource in question.
Once this process completes, an extensible match query is issued
to the specified servers. The query may also be redirected through
the use of LDAP referrals, if additional data is known to exist
elsewhere.
For example, a bottom-up search for the domain name of
"www.example.com" would result in the client building an
Hall & Newton I-D Expires: August 2002 [page 67]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetDnsDomainMatch extensible match query with the search base of
"cn=inetResources,dc=www,dc=example,dc=com", and with the client
issuing a DNS query for the LDAP servers associated with
"www.example.com" domain. If the DNS lookup failed, the client
would issue a subsequent query for the LDAP servers associated
with the "example.com" domain, and so forth, until a server had
been located. If the queried server had information about the
"www.example.com" resource, it would be returned as answer data.
If the server knew of other sources of information about the
resource (such as the registrar for the domain, or the entity
operating the domain, or both), continuation reference referrals
could be returned. Any of the subsequent queries could return
additional answers and/or referrals, according to the data they
had.
IP address blocks are processed in a similar fashion. If a client
needed to locate information about the "192.0.2.14" IPv4 address,
it would begin by issuing a DNS query for the LDAP servers
responsible for the "14.2.0.192.in-addr.arpa" domain name, with
the left-most labels being truncated as the search for an
authoritative server was broadened. Once a server had been
located, an inetIpv4NetworkMatch extensibleMatch search with the
assertion value of "192.0.2.14/32" would be submitted. If the
server knew of any information about that resource, it would
return data or a referral, with this process repeating until the
query string had been processed as completely as possible.
Note that entries for inetAsNumber and inetOrgPerson object
classes are not searchable with this model, since they are not
represented in the DNS delegation hierarchy. One of the other
search models MUST be used for those resource types.
7.2.1. Processing steps
The steps for processing bottom-up queries are described below:
a. Determine the input type (DNS Domain, IPv4 Address, etc.)
b. Determine the authoritative DNS domain for the resource.
1. Separate the input string into discrete elements where
this is possible. For a DNS domain name of
"www.example.com", this would be "www", "example" and
"com". For the IPv4 network number of "192.0.2.14",
Hall & Newton I-D Expires: August 2002 [page 68]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
this would be "192", "0", "2" and "14". Do not discard
the original query string.
2. IP addresses require additional conversion. For IPv4
addresses, strip off the prefix and convert the input
string into a reverse-lookup DNS domain name by
reversing the order of the octets and appending
"in-addr.arpa" to the right of the resulting sequence.
For IPv6 addresses, strip off the prefix and reverse
the nibble order of the address (where each nibble is
represented by a single hexadecimal character), and
append "ip6.arpa" to the right of the resulting
sequence.
c. Form the LDAP search base for the query.
1. Convert the domain name formed in step 7.2.1.b above
into a domainComponent DN (such as
"dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192,
dc=in-addr,dc=arpa"). This represents the DIT for the
current query.
2. Append the "cn=inetResources" RDN to the left of the
domainComponent syntax (perhaps resulting in
"cn=inetResources,dc=www,dc=example,dc=com"). This
will become the search base for the LDAP query.
d. Locate the LDAP servers associated with the resource by
processing the domain name formed in step 7.2.1.b above
through the SRV query steps provided in section 7.4.5.
e. If the SRV lookup fails with an NXDOMAIN response code (as
described in RFC 2308), then the domain name used for the
SRV lookup does not exist, and a substitute LDAP server and
search base must be identified. This process involves
determining the parent zone for the domain name in
question, issuing an SRV lookup for that zone, and using
the domain name of the zone as the new LDAP search base,
with this process repeating until a search base can be
located, or until a critical failure forces an exit.
1. Remove the left-most label from the domain name formed
in step 7.2.1.b.
2. If this process has already resulted in a query domain
name at a top-level domain such as "com" or "arpa",
Hall & Newton I-D Expires: August 2002 [page 69]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
convert the query domain name to "." (to signify the
root domain).
3. If the queried domain name is already set to ".", the
query can go no higher (this most likely indicates a
malformed DNS configuration, a connectivity problem,
or a typo in the query). Exit and report the failure
to the user.
4. Restart the process at step 7.1.1.c, using the domain
name formed above. Repeat until a server is located or
a critical failure forces an exit.
For example, if the original input string of
"www.example.com" resulted in a failed SRV lookup for
"_ldap._tcp.www.example.com", then the first fallback
SRV query would be for "_ldap._tcp.example.com", and
the next fallback query would be for "_ldap._tcp.com",
possibly being followed by "_ldap._tcp.", and possibly
resulting in failure after that.
f. If the SRV lookup succeeds:
1. Choose the best LDAP server, using the weighting
formula described in RFC 2782.
2. Construct the LDAP search filter according to the
rules specified in section 6.1, and choose the
appropriate matching rule from section 6.2.
3. Formulate the LDAP search using the search base and
search filter constructed above. For example, if the
input query string was for "www.example.com", then the
client would begin the process by submitting an
inetDnsDomainMatch extensibleMatch search with the
assertion value of "www.example.com", with the search
base of "cn=inetResources,dc=www,dc=example,dc=com".
4. Submit the search operation to the chosen server and
port number. If the operation fails, report the
failure to the user and exit. Otherwise, display any
answer data which is returned.
5. If the answer data contains a subordinate reference
referral or a continuation reference referral, new
query processes MUST be spawned.
Hall & Newton I-D Expires: August 2002 [page 70]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
For subordinate reference referrals, process the URLs
according to the rules described in section 7.4.1 and
restart the query process at step 7.2.1.f.2. For each
continuation reference referral, display the answer
data received so far, process the LDAP URLs according
to the rules described in section 7.4.3 and start new
query processes for each referral at step 7.2.1.f.2,
appending the output from these searches to the
current output.
Any additional subordinate reference referrals or
continuation reference referrals which are encountered
from any subsequent queries will need to be processed
in the same manner as specified above, until no
additional referrals are received.
g. If a fatal DNS error condition occurs, report the error to
the user and stop processing the current query. A fatal DNS
error is any response message with an RCODE of FORMERR,
SERVFAIL, NOTIMPL, or REFUSED, or where a query results in
NODATA (implying that an "_ldap._tcp" domain name exists
but it doesn't have an SRV resource record associated with
it, which is most likely a configuration error).
7.2.2. Bottom-Up example
In the example below, the user has entered a search string of
"www.example.com" and has indicated that the query is for a DNS
Domain Name.
a. The query string is used to form the DNS SRV lookup
("_ldap._tcp.www.example.com"), in order to find the LDAP
servers authoritative for that domain name.
b. The SRV lookup fails with NXDOMAIN, indicating that the
queried domain name does not exist.
c. The client creates a new query for the parent domain
("_ldap._tcp.example.com"), which succeeds.
d. The client contacts one of the servers, and issues an
inetDnsDomainMatch extensibleMatch search with the
assertion value of "www.example.com", and with the search
base of "cn=inetResources,dc=example,dc=com".
Hall & Newton I-D Expires: August 2002 [page 71]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
e. The server returns a continuation reference referral of
"ldap://ldap.example.net/cn=server1.example.net,
cn=inetResources,dc=example,dc=net", indicating that the
queried resource is a referral for a web hosting server at
Example Networks. The client uses this information to start
a new query. No additional data was provided for the client
to display.
f. An inetDnsDomainMatch extensibleMatch search is submitted
to the "ldap.example.net" server, using the search base of
"cn=server1.example.net,cn=inetResources,dc=example,dc=net"
g. The queried server returns the information that it has. No
additional referrals are provided. The client displays the
data and exits the query.
7.3. Targeted Search Processing
The targeted search model is similar to the bottom-up query model
described in the preceding section, except that it does not
provide fallback processing of DNS domain names. In this regard,
the targeted search model is closely similar to the traditional
LDAP searching model, in that a client queries a specified LDAP
server for a specific entry, under the assumption that the
resource exists at that location. If the server or resource does
not exist, the entire query fails.
For this reason, the targeted search model is not suitable for
search operations against generic Internet resources, but instead
is mostly suitable for searches against known entries which are
presumed to exist at a known location. In terms of the LDAP-WHOIS
service in particular, this includes inetOrgPerson entries which
are provided in contact-related attributes. However, the targeted
search model can be used for any resource type, and it can be
useful for diagnosing problems with resource types. For this
reason, clients SHOULD support this model for use with all known
resource types.
The targeted search takes an LDAP URL as the query input (along
with the resource-type identifier), and uses the URL to determine
the query server, the search base, and the assertion value.
Hall & Newton I-D Expires: August 2002 [page 72]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
7.3.1. Processing steps
The steps for processing targeted search queries are described
below:
a. Process the LDAP URLs according to the continuation
reference referral handling rules described in section
7.4.3. This process will determine the servers, search base
and assertion value of the query.
b. If this process succeeds:
1. Construct the LDAP search filter according to the
rules specified in section 6.1, and choose the
appropriate matching rule from section 6.2.
2. Submit the search operation to the chosen server and
port number. If the operation fails, report the
failure to the user and exit. Otherwise, display any
answer data which is returned.
3. If the answer data contains a subordinate reference
referral or a continuation reference referral, new
query processes MUST be spawned.
For subordinate reference referrals, process the URLs
according to the rules described in section 7.4.1 and
restart the query process at step 7.3.1.b. For each
continuation reference referral, display the answer
data received so far, process the LDAP URLs according
to the rules described in section 7.4.3 and start new
query processes for each referral at step 7.3.1.b.
Any additional subordinate reference referrals or
continuation reference referrals which are encountered
from any subsequent queries will need to be processed
in the same manner as specified above, until no
additional referrals are received.
c. If this process fails, report the failure to the user and
exit the current search operation.
7.3.2. Targeted search example
Hall & Newton I-D Expires: August 2002 [page 73]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
In the example below, the user has provided an LDAP URL of
"ldap://ldap.example.com/cn=admins,ou=admins,dc=example,dc=com",
and has indicated that the query is for an inetOrgPerson entry.
a. The query string is used to form a DNS lookup of the
specified server ("ldap.example.com").
b. The client contacts the servers, and issues a search for
"(&(objectclass=inetOrgPerson)(cn:dn:=admins))", with a
search base of "ou=admins,dc=example,dc=com".
c. The queried server returns the information that it has. No
additional referrals are provided. The client displays the
data and exits the query.
7.4. Supplemental Query Processing Mechanisms
During the course of normal query processing, an LDAP-WHOIS client
may need to use additional mechanisms to complete an operation,
such as processing a URL received from a redirect operation, or
issuing DNS SRV lookups against a provided domain name.
7.4.1. URL processing
URL processing in this specification is a function of both content
and context. Different attributes and result codes provide
different types of URLs, and the disposition of these URLs will
depend on the query-resolution process currently being executed.
On the content front, this specification allows three different
forms of URLs to appear throughout this service: labeledURI
attribute values, attribute references, and referral messages.
Each of these usage scenarios have slightly different restrictions
and formats.
* The labeledURI attribute is included with the inetResources
object class for the purpose of informing end-users of a
generic resource associated with an entry (such as an
organization's home page). The labeledURI attribute is
defined in RFC 2079 for the purpose of storing generic URLs
as attribute values, and uses a two-part syntax of
"url://any.host:port/any/path description", with the
"description" string providing a free-text description of
the target specified by the URL.
Hall & Newton I-D Expires: August 2002 [page 74]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
* Attribute references also use the two-part format of the
labeledURI attribute, but with some additional restrictions
as described in section 4.5 of this document.
* Subordinate and continuation reference referrals use URLs
for the purpose of providing referral targets. The URL
format specified in [namedref] is also an explicit subset
of the labeledURI format, but without the "description"
free-text block. When used with the LDAP-WHOIS service,
subordinate and continuation referrals are subject to some
additional rules as described in section 4.5 of this
document.
Non-compliance with the requirements provided in section 4.5
amounts to an error, and is sufficient cause for a client to stop
processing a query.
7.4.2. Subordinate reference referrals
Subordinate reference referrals and their schema are defined in
[namedref]. Subordinate reference referrals use the
SearchResultDone response with a Referral result code, which is
defined and described in section 4.1.11 of RFC 2251. Subordinate
reference referrals use a subset of the labeledURI syntax as
defined in RFC 2079, and use the syntax definitions from RFC 2255
when LDAP URLs in particular are provided, although section 4.5 of
this document also defines additional restrictions on the
allowable URL syntax.
In the context of the LDAP-WHOIS service, subordinate reference
referrals are returned when the search base specified in a search
operation exists as a referral object class with the ref attribute
pointing to some other entry, resulting in queries with that
search base being answered with a SearchResultDone referral
response. This condition means that the current search operation
cannot proceed past this point, and the search MUST be restarted.
This will most often occur when the inetResources entry for a DIT
has been redirected to another DIT, but it can also happen after
continuation reference referrals have been followed or after
targeted searches have been issued, and where the queried entry
exists as a referral to some other entry.
The procedure for processing URLs returned in a subordinate
reference referral is as follows:
Hall & Newton I-D Expires: August 2002 [page 75]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
a. RFC 2251 allows multiple URLs to be provided, although the
URLs are not provided with any "preference" or "weighting"
values. If a set of URLs are provided, only one of the URLs
need to be tried (implementations MAY perform additional
queries in an attempt to recover from temporary failures,
although this is not required). Select one of the URLs at
random ("round-robin"), and continue to the next step in
the process.
b. Extract and discard any description text which may have
been provided with the URL.
c. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are to be treated as malformed.
d. Extract the host identifier element and perform any DNS
lookups which may be required. URLs without host
identifiers are to be treated as malformed.
e. Extract the port number provided with the URL, and set it
aside for use with the subsequent connection attempt. If no
port number has been provided in the URL, use the default
port numbers associated with the protocol, as discovered in
step 7.4.2.c.
f. Extract the path element from the URL for use as the search
base of the subsequent search operation. URLs without path
elements are to be treated as malformed.
g. Restart the current search operation, using the LDAP server
from step 7.4.2.d, the port number from step 7.4.2.e, and
the search base formed in step 7.4.2.f.
7.4.3. Continuation reference referrals
Continuation reference referrals and their schema are defined in
[namedref]. Continuation reference referrals use the
SearchResultReference response, which is defined and described in
section 4.5.3 of RFC 2251. Continuation reference referrals use a
subset of the labeledURI syntax as defined in RFC 2079, and use
the syntax definitions from RFC 2255 when LDAP URLs in particular
are to be provided, although section 4.5 of this document also
defines additional restrictions on the allowable URL syntax.
Hall & Newton I-D Expires: August 2002 [page 76]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
For this service, continuation reference referrals are returned
when the search base specified in a search operation exists, but
one or more of the answer elements exist as referral object
classes, resulting in one or more SearchResultReference responses.
This condition means that the current search operation has
partially succeeded, but that additional searches SHOULD be
started in order for all of the answer data to be retrieved (in
many cases, no answer data will be provided, and in those
situations, new queries will be required for any data to be
retrieved). This will occur whenever the assertion value of a
search has matched a resource entry which is being managed by
another DIT, and can occur with any of the search operations
described in this document.
Multiple continuation reference referrals MAY be returned in
response to a search, and each of them MUST be processed in order
for all of the answer data to be retrieved.
The procedure for processing the URLs returned in a continuation
reference referral is as follows:
a. RFC 2251 allows multiple URLs to be provided, although the
URLs are not provided with any "preference" or "weighting"
values. If a set of URLs are provided, only one of the URLs
need to be tried (implementations MAY perform additional
queries in an attempt to recover from temporary failures,
although this is not required). Select one of the URLs at
random ("round-robin"), and continue to the next step in
the process.
b. Extract and discard any description text which may have
been provided with the URL.
c. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are to be treated as malformed.
d. Extract the host identifier element and perform any DNS
lookups which may be required. URLs without host
identifiers are to be treated as malformed.
e. Extract the port number provided with the URL, and set it
aside for use with the subsequent connection attempt. If no
port number has been provided in the URL, use the default
Hall & Newton I-D Expires: August 2002 [page 77]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
port numbers associated with the protocol, as discovered in
step 7.4.3.c.
f. Extract the path element from the URL for use as the search
base of the subsequent search operation. URLs without path
elements are to be treated as malformed.
g. Extract the left-most RDN from the search base constructed
in step 7.4.3.e, and delete the naming attribute label. The
resulting string will be used as the assertion value for
the subsequent search operation. For example, if the path
element from a URL provided a distinguished name of
"cn=example.com,cn=inetResources,dc=example,dc=com", then
the "cn=example.com" RDN would be used to form an assertion
value of "example.com".
h. Start a new search operation, using the LDAP server from
step 7.4.3.d, the port number from step 7.4.3.e, the search
base formed in step 7.4.3.f, and the assertion value formed
in step 7.4.3.g.
7.4.4. Attribute references
Attribute references are defined in this document as attributes
which provide URLs as pointers to contextually related
information. These are not referrals, but instead are simple URLs
returned as attribute values. In particular, this document defines
multiple contact-related attributes which provide these URLs.
Other documents may also define attributes which reuse the URL
format defined here, or may define their own URL rules, as needed.
For this service, attribute reference URLs are returned when an
entry has an attribute defined which uses them. Attribute
references are not referrals, and do not require additional
processing. Clients MAY automatically start new search operations
when an attribute reference is encountered, or they MAY delay
processing until a user requests the action.
The procedure for processing the URLs returned in an attribute
reference is as follows:
a. RFC 2251 allows multiple URLs to be provided, although the
URLs are not provided with any "preference" or "weighting"
values. If a set of URLs are provided, only one of the URLs
need to be tried (implementations MAY perform additional
Hall & Newton I-D Expires: August 2002 [page 78]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
queries in an attempt to recover from temporary failures,
although this is not required). Select one of the URLs at
random ("round-robin"), and continue to the next step in
the process.
b. Extract and discard any description text which may have
been provided with the URL.
c. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are to be treated as malformed.
d. Extract the host identifier element and perform any DNS
lookups which may be required. URLs without host
identifiers are to be treated as malformed.
e. Extract the port number provided with the URL, and set it
aside for use with the subsequent connection attempt. If no
port number has been provided in the URL, use the default
port numbers associated with the protocol, as discovered in
step 7.4.4.c.
f. Extract the path element from the URL for use as the search
base of the subsequent search operation. URLs without path
elements are to be treated as malformed.
g. Extract the left-most RDN from the search base constructed
in step 7.4.4.e, and delete the naming attribute label. The
resulting string will be used as the assertion value for
the subsequent search operation. For example, if the path
element from a URL provided a distinguished name of
"cn=example.com,cn=inetResources,dc=example,dc=com", then
the "cn=example.com" RDN would be used to form an assertion
value of "example.com".
h. Determine the object class filter to be used with the
assertion value. This will depend on the attribute which
provided the attribute reference. The contact-related
attributes defined in this document refer to inetOrgPerson
object class entries.
i. Start a new search operation, using the LDAP server from
step 7.4.4.d, the port number from step 7.4.4.e, the search
base formed in step 7.4.4.f, the assertion value formed in
step 7.4.4.g, and the new object class filter formed in
step 7.4.4.h.
Hall & Newton I-D Expires: August 2002 [page 79]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
7.4.5. SRV processing
The query models described in this document make use of DNS SRV
resource records whenever a new query process is started, as a way
to locate the LDAP servers associated with a DIT.
The procedure for constructing this SRV lookup is as follows:
a. Construct an SRV-specific label pair for the service type.
For LDAP queries, this will be "_ldap._tcp", while LDAPS
will use "_ldaps._tcp".
b. Append the SRV label pair to the left of the input domain
name. In the case of an LDAP query for "example.com", this
would result in an SRV-specific domain name of
"_ldap._tcp.example.com".
c. Issue a DNS query for the SRV resource records associated
with the domain name formed in step 7.4.5.b.
Multiple SRV resource records may be returned in response to a
query. Each resource record identifies a different connection
target, including the domain name of a server, and a port number
for that server. The port number specified in a SRV resource
record MUST be used for any subsequent bind and search operations.
SRV resource records provide "priority" and "weight" values which
MUST be used to determine the preferred server. If a server is
unavailable or unreachable, a connection attempt must be made to
the next-best server in the answer set.
Refer to RFC 2782 for a detailed explanation of SRV resource
records and their handling.
8. Internationalization and Localization
The LDAP-WHOIS model uses the internationalization and
localization services provided by LDAPv3. In this regard, LDAP-
WHOIS clients do not need to implement any special services in
order to process and display internationalized attribute data,
since the attribute types already provide direct support for
internationalized data.
Hall & Newton I-D Expires: August 2002 [page 80]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
LDAP-WHOIS clients may have some localization or language-specific
presentation issues with regards to attribute names, in that the
names of the attributes may need to be localized for specific
markets. However, these services are outside the scope of the
protocol operations. Any such requirements must be dealt with
according to the services available on the client platform.
In the case of legacy WHOIS servers which gateway requests between
TCP port 43 and the LDAP-WHOIS service, the input and output
language and/or locale codes MAY be specified by server-specific
options, although these mechanisms must be defined as part of the
WHOIS protocol for any widespread consistency to be possible, and
are therefore beyond the scope of this document.
9. DIT Replication
All DITs which provide data for global Internet resources SHOULD
be replicated across two or more servers. Each of the
authoritative LDAP servers for the managed resource MUST be
specified with a unique DNS SRV resource record for the domain
name associated with the top-level resource assignment space.
For example, the top-level "com" delegation space SHOULD have two
or more SRV resource records associated with the "_ldap._tcp.com"
domain name, with each entry referring to separate LDAP servers,
and with each of those servers maintaining accurate copies of the
"dc=com" DIT (within reasonable timeliness). Similarly, the top-
level " arpa" domain which is used by the IPv4 and IPv6 delegation
trees SHOULD provide two or more SRV resource records for the
"_ldap._tcp.arpa" domain name, as should the "in-addr.arpa" and
"ip6.arpa" domain hierarchies.
DITs which serve multiple organizations SHOULD also be replicated.
For example, an ISP which provides LDAP-WHOIS services for their
customers SHOULD also follow these same rules, since outages of
those servers will affect multiple parties. Leaf-node DITs
associated with an user-managed resource MAY be replicated, and
are encouraged to do so.
Similarly, any referrals which present URLs as answer data SHOULD
provide multiple URLs, each of which reference different hosts on
different networks. For leaf-node referrals, attribute references,
and labeledURI references, this behavior MAY be relaxed, although
it is still encouraged.
Hall & Newton I-D Expires: August 2002 [page 81]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
Note that the most effective replication strategy will be for
entities to replicate their DITs with the delegation parents, as
this will allow queries for those resources to be processed by the
parent servers (thereby eliminating the need for referral
queries). In many cases, this will not be feasible (the servers
for the "dc=com" DIT cannot be expected to host replicas of every
subordinate DIT), but it is encouraged where practical.
10. Transition Issues
There are a handful of areas where the proposed service does not
fully match with all of the existing WHOIS service offerings.
These areas are discussed in more detail below.
10.1. NIC Handles
NIC handles represent a historical method of WHOIS lookups, tying
unique identifiers to a specific record in a specific database.
Given that the model proposed in this document uses a distributed
lookup system rather than isolated databases, the NIC handle model
is no longer necessary. Furthermore, given the limited global
usability of NIC handles, they should be deprecated.
However, NIC handles are an important part of the legacy service,
and their continued usage is likely to be desired in at least some
instances. There are two possible workarounds for this problem:
* NIC handle output in legacy WHOIS systems SHOULD be replaced
with an LDAP URL for the contact entries. This option
facilitates faster coalescence around the LDAP-WHOIS system.
* Referral entries MAY be defined for each existing NIC handle
if the explicit NIC handle is still required for an
application or usage, and queries for NIC handles MAY be
processed through these referral entries. For example, the
NIC handle of EH26 on Network Solutions' WHOIS server can be
represented as "cn=EH26,cn=inetResources,dc=netsol,dc=com",
with the inetOrgPerson and referral object classes defined,
and with the ref attribute value pointing to an entry named
"cn=Eric A. Hall,cn=inetResources,dc=ntrg,dc=com".
Of the two mechanisms described above, the former is preferred.
Hall & Newton I-D Expires: August 2002 [page 82]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
10.2. Change-Logs
Several WHOIS services provide pseudo change-logs in their
response data, listing each unique modification event which has
occurred for a particular resource. For example, RIPE and some of
its member ccTLDs provide WHOIS output which includes a series of
"changed" fields that itemize every modification event ("updated",
"added", etc.), the modifier, and the modification date, which
cumulatively act as a change-log for the resource in question.
While this service is useful and informative to the delegating
bodies, this information is not as useful to external entities.
Furthermore, the principle use of this information is for the
purpose of internal audits, rather than external information.
Finally, a subset of this kind of information is already provided
in the *modified* operational attributes, which are always
available for public review.
Organizations are certainly free to maintain this information on
their internal systems (and are even encouraged to do so).
However, this information is not necessary for public view of the
data in the LDAP-WHOIS service. Where the auditing information
will be required, a format which is more suitable to legal review
will be required and more appropriate.
For these reasons, this service is not supported in the LDAP-WHOIS
service. However, if this information is absolutely required,
implementers MAY provide it as additional unstructured data via
the inetGeneralComments attribute (perhaps using an
"event:modifier:date" format).
10.3. Open Issues
The following issues require additional analysis:
* inetIpv6Network entries will likely benefit from
certificate-related data, although the extent and nature of
this information (minimum requirements, preferred
attributes, pre-existing schema, etcetera) is currently
unknown by the authors.
* The RIPE database v3 has several additional attributes:
domain: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
Hall & Newton I-D Expires: August 2002 [page 83]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
tech-c: [mandatory] [multiple] [inverse key]
zone-c: [mandatory] [multiple] [inverse key]
nserver: [optional] [multiple] [inverse key]
sub-dom: [optional] [multiple] [inverse key]
dom-net: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
refer: [optional] [single] [ ]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
see http://www.ripe.net/ripe/docs/databaseref-manual.html
11. Security Considerations
This document describes an application of the LDAPv3 protocol, and
as such it inherits the security considerations associated with
LDAPv3, as described in section 7 of RFC 2251.
By nature, LDAP is a read-write protocol, while the legacy WHOIS
service has always been a read-only service. As such, there are
significant risks associated with allowing unintended updates by
unauthorized third-parties. Moreover, allowing the LDAP-WHOIS
service to update the underlying delegation databases could result
in network resources being stolen from their lawful operators. For
example, if the LDAP front-end had update access to a domain
delegation database, a malicious third-party could theoretically
take ownership of that domain by exploiting an authentication
weakness, thereby causing ownership of the domain to be changed to
another party. For this reason, it is imperative that the LDAP-
WHOIS service not be allowed to make critical modifications to
delegated resources without ensuring that all possible precautions
have been taken.
The query processing models described in this document make use of
DNS lookups in order to locate the LDAP servers associated with a
particular resource. DNS is susceptible to certain attacks and
forgeries which may be used to redirect clients to LDAP servers
which are not authoritative for the resource in question.
Some operators may choose to purposefully provide misleading or
erroneous information in an effort to avoid responsibility for bad
behavior. In addition, there are likely to be sporadic operator
errors which will result in confusing or erroneous answers.
Hall & Newton I-D Expires: August 2002 [page 84]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
This document provides multiple query models which will cause the
same query to be answered by different servers (one would be
processed by a delegation entity, while another would be processed
by an operational entity). As a result, each of the servers may
provide different information, depending upon the query type that
was originally selected.
For all of the reasons listed above, it is essential that
applications and end-users not make critical decisions based on
the information provided by the LDAP-WHOIS service without having
reason to believe the veracity of the information. Users should
limit unknown or untrusted information to routine purposes.
Finally, there are physical security issues associated with any
service which provides physical addressing and delivery
information. Although organizations are generally encouraged to
provide as much information as they feel comfortable with, no
information is required.
12. IANA Considerations
This document defines an application of the LDAPv3 protocol rather
than a new Internet application protocol. As such, there are no
protocol-related IANA considerations.
However, this document does define several LDAP schema elements,
including object classes, attributes, syntaxes and extensibleMatch
filters, and these elements should be assigned OID values from the
IANA branch, rather than being assigned from a particular
enterprise branch.
Furthermore, this document defines delegation status codes for
four of the resource types described herein, and IANA is expected
to maintain the code-point mapping values associated with these
attribute values. Each resource type may develop its own peculiar
status codes, so each of the mapping tables will need to be
maintained independently.
Finally, this document also describes several instances where
public DNS and LDAP servers are queried. It is expected that IANA
will establish and maintain these LDAP servers (and the necessary
DNS SRV domain names and resource records) required for this
service to operate. This includes providing SRV resource records
Hall & Newton I-D Expires: August 2002 [page 85]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
in the generic TLDs and the root domain, and also includes
administering the referenced LDAP servers.
13. Author's Addresses
Eric A. Hall
ehall@ehsco.com
Andrew Newton
anewton@research.netsol.com
14. References
RFC 1274 - The COSINE and Internet X.500 Schema
RFC 2079 - Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)
RFC 2247 - Using Domains in LDAP/X.500 DNs
RFC 2251 - Lightweight Directory Access Protocol (v3)
RFC 2252 - Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions.
RFC 2253 - Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of DNs
RFC 2254 - The String Representation of LDAP Search Filters
RFC 2255 - The LDAP URL Format
RFC 2256 - A Summary of the X.500(96) User Schema for use
with LDAPv3
RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE)
RFC 2782 - A DNS RR for specifying the location of services
(DNS SRV)
RFC 2798 - Definition of the inetOrgPerson LDAP Object
Class
Hall & Newton I-D Expires: August 2002 [page 86]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
RFC 2849 - The LDAP Data Interchange Format (LDIF) -
Technical Specification
[namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named
Subordinate References in LDAP Directories
[ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
Internet Registry Directory Requirements
On a related note, VeriSign has been working on an RLDAP project
[described in draft-newton-ldap-whois-00.txt (Whois Domain Data in
LDAP)] that uses a query model very similar to the one described
in this document, and which illustrates many of the points
described in this document. The current RLDAP implementation has
three client implementations, multiple distributed servers, and
contains more than 32 million DNS domain entries, and 115 million
resource-specific entries. In many regards, this document is an
extension of RLDAP.
15. Changes from Previous Versions
The following changes were made to the -00 version:
* The ôObjectivesö section has been removed. [ir-dir-req] is
now being used as the guiding document for this service.
* Several typographical errors have been fixed.
* Some unnecessary text has been removed.
* Figures changed to show complete sets of object classes, to
improve inheritance visibility.
* Clarified the handling of reverse-lookup domains (zones
within the in-addr.arpa portion of the DNS hierarchy) in
the inetDnsDomain object class reference text.
* Referrals now use regular LDAP URLs (multiple responses
with explicit hostnames and port numbers). Prior editions
of this specification used LDAP SRV resource records for
all referrals.
* The delegation status codes used by the
inetDnsDelegationStatus, inetIpv4DelegationStatus,
Hall & Newton I-D Expires: August 2002 [page 87]
Internet Draft draft-hall-ldap-whois-01.doc February 2002
inetIpv6DelegationStatus and inetAsnDelegationStatus
attributes have been condensed to a more logical set.
* Added an inetDnsAuthServers attribute for publishing the
authoritative DNS servers associated with a domain. NOTE
THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE
REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND
ATTRIBUTES.
* Added an inetGeneralDisclaimer attribute for publishing
generalized disclaimers.
* Added the inetAssociatedResources auxiliary object class
for defining associated resources, and moved some of the IP
addressing and ASN attributes to the new object class.
* Several attributes had their OIDs changed. NOTE THAT THIS
IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
Hall & Newton I-D Expires: August 2002 [page 88]