Eric A. Hall
Consultant
INTERNET-DRAFT Andrew Newton
Document: draft-hall-ldap-whois-00.txt VeriSign, Inc.
Expires: May, 2002 November 2001
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 processing rules for four
Internet resource types: DNS domains, IPv4 addresses, IPv6
address, and AS numbers. The framework specified in this document
allows additional documents to define additional Internet resource
types and their handling rules.
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
Table of Contents
1. Abstract..................................................1
2. Definitions and Terminology...............................3
3. Background, Objectives and Overview.......................4
3.1. Background.............................................4
3.2. Objectives.............................................6
3.3. Overview...............................................8
4. Resource Naming Syntax....................................9
4.1. Namespace Example.....................................10
4.2. The domainComponent LDAP hierarchy....................12
4.3. The inetResources Container...........................13
4.4. Resource-Specific Entries.............................13
4.5. Redirects and Referrals...............................14
5. The LDAP-WHOIS Object Classes and Attributes.............19
5.1. The inetResources Object Class........................20
5.2. The inetDnsDomain Object Class........................26
5.3. The inetIpv4Network Object Class......................32
5.4. The inetIpv6Network Object Class......................37
5.5. The inetAsNumber Object Class.........................43
5.6. The inetOrgPerson Object Class........................49
5.7. The referral Object Class.............................50
5.8. Object Class and Attribute Permissions................50
6. Search and Match Filters.................................52
6.1. Search Filter Expressions.............................52
6.2. Matching Filter Definitions...........................54
7. Query Processing Models..................................60
7.1. Top-Down Processing...................................60
7.2. Bottom-Up Processing..................................65
7.3. Targeted Search Processing............................70
7.4. Supplemental Query Processing Mechanisms..............72
8. Internationalization and Localization....................80
9. DIT Replication..........................................80
10. Security Considerations..................................81
11. IANA Considerations......................................82
12. References...............................................82
13. Author's Addresses.......................................83
14. Transition Issues........................................83
14.1. NIC Handles...........................................84
14.2. Nameserver Attributes.................................84
14.3. Change-Logs...........................................85
14.4. Open Issues...........................................86
Hall & Newton I-D Expires: May 2002 [page 2]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
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
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")
Hall & Newton I-D Expires: May 2002 [page 3]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
networked 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 and users, with each server offering information
associated with a specific resource allocation group.
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 which 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.
There are also WHOIS servers which are operated by service
providers, with these servers providing information about the
network 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
Hall & Newton I-D Expires: May 2002 [page 4]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
information in only one language and charset, while others support
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.
This wide variety has made programmatic processing somewhat
difficult, which has in turn reduced the effectiveness of the
information which is provided.
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 queries to
other WHOIS servers, nor can clients be redirected to other
servers for additional information. As a result, end-users must
have prior knowledge of the management entity which is responsible
for a particular network resource, must know the domain name of
the WHOIS server which provides information about that resource,
and must know the syntax for that server. Users are often required
to query multiple servers in order to locate the appropriate
server for a specific resource (particularly when a resource has
been delegated through multiple entities), or to obtain details
about a related entity (such as querying for DNS information
related to a previously-queried IPv4 address), so these demands
can be encountered frequently, raising significant hurdles towards
the acquisition of public operational data.
Finally, the WHOIS services being operated today offer no means of
client authentication, requiring that server operators publish all
data with a single "world-readable" permission. However, this
single permission conflicts with the privacy and security
restrictions within different governmental jurisdictions. A more
flexible mechanism for defining and controlling the release of
physical and personal information is required in order to meet the
demanding requirements of these 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 WHOIS-like service, using DNS as the directed-lookup
protocol and LDAP as the transfer protocol.
Hall & Newton I-D Expires: May 2002 [page 5]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
3.2. Objectives
The primary design objectives addressed by this document are:
* Structured data formats. This service provides structured
data in the form of standardized naming and schema in order
to facilitate the programmatic access of operational data.
This service reuses some existing object classes and
attributes where feasible, and also introduces some new
schema definitions.
* Structured redirects. This document defines a distributed
service in order to facilitate programmatic redirects
between participating servers. This model is closer in
concept to the distributed management model used by DNS
than the centralized management model traditionally used by
the legacy WHOIS service, in that queries may be directed
between resource hierarchies according to the information
provided by a queried server.
* Distributed management. As part of the above, this document
also defines a delegated administrative model whereby data
that relates to a specific entity is managed and maintained
by that entity. A delegation body can provide delegation
data about a resource, while an operational body can
provide operational data about that resource, and the two
views are independently maintained as independent entries.
Moreover, organizations can leverage common security
mechanisms for the purpose of inter-organizational resource
management, such that a delegation entity can choose to
allow the operational entity to change the delegation data
independently, as required by the operational entity.
* Privacy and physical security controls. Organizations can
provide as much or as little information as they wish, as
dictated by local security policies, government regulations
or personal privacy concerns. Implementers can also
restrict the amount of information which is returned for
anonymous queries, while providing greater amounts of
information to authenticated and authorized users.
* Internationalization and localization. Given the widespread
use of the Internet and its resources in international
markets, the need for a service which is capable of
supporting internationalized and localized data is
Hall & Newton I-D Expires: May 2002 [page 6]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
paramount. The service model described by this document
leverages the data formats which are already provided by
the LDAP service to achieve this objective, and also
provides additional guidance on the presentation of this
information to the user.
* Consistent architecture. In support of the above, this
document defines an architecture which is consistent for
all of the participating organizations, regardless of the
role they play in the community (whether registry,
registrar or operator), and regardless of the size of their
resource pool.
* Reuse of known technology. One of the basic objectives for
this specification is to reuse existing technology wherever
possible, if that technology has been proven to be
functionally usable for this service. To that end, this
document does not define any new transport layer
mechanisms, data transfer services, schema languages, or
directory service technology, but instead reuses existing
technologies for each of these elements. This specification
also reuses schema definitions for base objects and common
practices for data management, where applicable.
* Extensibility. This document defines a set of schema which
are required for use with some common core services, but
also allows for the creation and use of additional
services. For example, it would be possible to layer a
public-key lookup service on top of the provided
architecture, or to define any number of application-
specific data storage and retrieval mechanisms.
In short, the primary objective of this service is to facilitate a
distributed and highly structured WHOIS-like service. This is
achieved by using LDAP as a rich and highly structured
query/response transfer mechanism, using the existing DNS domain
delegation hierarchy for the purposes of a fast and lightweight
server-locator service, and using well-defined common schema for
the search inputs, answer data, and redirection mechanisms. This
approach satisfies all of the objectives stated above, and also
provides an extensible framework that allows for programmatic
queries regarding all types of network resources, including future
uses which are not defined in this document.
Hall & Newton I-D Expires: May 2002 [page 7]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
In addition, this approach also provides at two notable ancillary
benefits, which are:
* Replication. The service model described by this document
benefits from the standardized replication mechanisms which
are already provided by the LDAP service, and which are
supported by DNS. This allows information stores to be
replicated across multiple servers, and for the clients to
locate a preferred server for any given query.
* Common access. The service described in this document is
intended to be used with service-specific clients and
servers which implement the necessary LDAP features and
extensions. However, this service is also usable with
traditional LDAP clients and servers, with the caveat that
these systems will exhibit less functionality (particularly
in the area of searching). It is also expected that LDAP-
WHOIS gateways will be developed in the form of proxy
servers which gateway between TCP port 43 and the LDAP
data, thereby providing legacy WHOIS clients with access to
the data.
3.3. 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 Naming Syntax. This document implicitly defines
a virtual LDAP namespace which leverages the existing DNS
delegation hierarchy, and is supplemented by a layered
namespace consisting of service-specific containers and
resource-specific entries. This namespace and the
associated naming rules facilitate the programmatic
formation of queries and answer sets.
* 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.
Hall & Newton I-D Expires: May 2002 [page 8]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
* 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 also 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 locating centrally-administered and delegated
global Internet resources, a "bottom-up" model which is
designed for locating user-managed resources, and a
"targeted search" model which is designed for issuing
directed searches for known resources at known servers.
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 usage models.
4. Resource Naming Syntax
A key part of this service is the use of a predictable naming
syntax, both for storing resource data and for programmatically
creating searches for that data. Because of these two factors,
predictability is of the utmost importance to this service. In
order to ensure this predictability, this document defines a
multi-layered standardized distinguished name (DN) syntax which
MUST be used in all compliant implementations.
This architecture uses three distinct elements within a DN. The
right-most components of a DN use the domainComponent ("dc=") RDN
syntax to map between DNS zones and LDAP directory information
trees (DITs), such that the LDAP servers which are authoritative
for a particular portion of the DNS hierarchy can be easily
located, and so that the scope of the DIT can be easily
determined. Within each distinct DIT is a service-specific
container entry with an RDN of "cn=inetResources", which further
contains resource-specific entries named according to resource-
specific rules. The combination of these three structural elements
Hall & Newton I-D Expires: May 2002 [page 9]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
results in a fully-formed DN which refers to an explicit Internet
resource in an explicit DIT.
In addition to the structured and predictable naming syntax, the
LDAP-WHOIS service also makes provisions for the use of multiple
referral services for the purpose of redirecting LDAP clients to
foreign DITs. This allows organizations to consolidate DITs when
beneficial, allows foreign objects to exist 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,
which will be used throughout this document to illustrate many of
the concepts and mandates of this specification. Each of these
elements are described throughout the remainder of this document.
Figure 1: Namespace for Example Widgets' domain and network.
DIT: dc=example,dc=com
|
+-cn=inetResources,dc=example,dc=com
[inetResources object class]
|
+-attribute: o
| [inherited from inetResources]
| value: "Example Widgets, Inc."
|
+-attribute: inetSecurityContacts
| [inherited from inetResources]
| value: "ldap://example.com/cn=security,
| ou=admins,dc=example,dc=com"
|
+-cn=example.com,cn=inetResources,dc=example,dc=com
| [inetDnsDomain object class]
| |
| +-attribute: inetDnsContacts
| [inherited from inetDnsDomain]
| value: "ldap://example.com/cn=hostmaster,
| ou=admins,dc=example,dc=com"
|
Hall & Newton I-D Expires: May 2002 [page 10]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
+-cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com
| [inetDnsDomain object class]
| |
| +-attribute: inetDnsContacts
| [inherited from inetDnsDomain]
| value: "ldap://example.com/cn=hostmaster,
| ou=admins,dc=example,dc=com"
|
+-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
[inetIpv4Network object class]
[referral object class]
|
+-attribute: ref
[inherited from referral]
value: "ldap://example.com/cn=192.0.2.0%2F24,
cn=inetResources,dc=example,dc=net"
DIT: dc=0,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa
|
+-cn=inetResources
[inetResources object class]
[referral object class]
|
+-attribute: ref
[inherited from referral]
value: "ldap://example.com/cn=inetResources,
dc=example,dc=com"
In the example shown in Figure 1, there are two DITs providing
LDAP-WHOIS services: one for the "example.com" DNS domain
("dc=example,dc=com"), and another for the "192.0.2.0/24" IPv4
network ("dc=0,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"). Both DITs
have container entries called "cn=inetResources", although the
container entry for the reverse-lookup hierarchy is a subordinate
reference referral which points back to the "cn=inetResources,
dc=example,dc=com" hierarchy.
Within the "cn=inetResources,dc=example,dc=com" branch are
subentries for the locally-managed resources, including the DNS
domains and IPv4 networks. These entries also use strict naming
syntaxes in order to facilitate the use of predictable queries.
Figure 1 also shows an example of recursive referrals, where the
"cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" entry is
being redirected to an entry on the "dc=example,dc=net" DIT. Also
note that the LDAP URL for this referral escapes the "/" prefix
Hall & Newton I-D Expires: May 2002 [page 11]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
separator (replacing it with "%2F") in order to comply with the
URL notation rules.
4.2. The domainComponent LDAP hierarchy.
For the top-level of the namespace, this document embraces the
domainComponent naming syntax specified in RFC 2247, which maps
DNS domain names to domainComponent ("dc=") relative distinguished
names (RDNs). Therefore, this document requires that every LDAP DN
which is to be specified by an LDAP-WHOIS operation MUST map to a
DNS domain name. Examples of this syntax are shown in Figure 2.
Note that the root DNS domain is specified with a "dc=."
Figure 2: The LDAP-WHOIS domainComponent Namespace.
dc=.
|
+----------------+---------------+
/ | \
dc=arpa dc=com dc=[...]
| |
+--+--+ dc=example
/ \
dc=in-addr dc=ip6
The complete sequence of domainComponent RDNs represents the scope
of the DIT. For example, a DIT with the DN of "dc=com" is
authoritative for all of the LDAP resources within the "com" DNS
domain, while a DIT with the DN of "dc=example,dc=com" is
authoritative for resources within the "example.com" DNS domain.
Similarly, the "dc=0,dc=2,dc=192,dc=in-addr,dc=arpa" DN is
authoritative for resources within the "0.2.192.in-addr.arpa" DNS
domain (including the IPv4 addresses in that subnet and the
reverse-lookup domain name entries; the specific resources are
indicated by the object class of each LDAP entry).
"Authority" for a DIT and its associated resources is assigned
through the use of DNS SRV resource records, meaning that the
authority to process LDAP searches for the "dc=com" portion of the
LDAP namespace hierarchy comes from the authority to process DNS
queries for the "com" portion of the DNS hierarchy.
What this also means is that DNS SRV query operations can be
redirected to LDAP servers in a different DNS zone, which allows
LDAP servers outside of a DIT to be authoritative for a DIT, where
Hall & Newton I-D Expires: May 2002 [page 12]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
this is desirable. For example, the SRV resource records for the
"0.2.192.in-addr.arpa" DNS domain can point to LDAP servers in the
"example.com" hierarchy if the administrators choose to do so,
although a "dc=0,dc=2,dc=192,dc=in-addr,dc=arpa" DIT would still
need to exist on those servers (as a referral, at the least) in
order for searches to succeed.
4.3. The inetResources Container
Towards the principle objective of predictable naming, this
specification requires the use of a mandatory LDAP entry with the
well-known 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 inetResources container.
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 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
referral operation. 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, and each of
these resource types have their own naming rules. However, each
resource type has a consistent naming principle, in that the
Hall & Newton I-D Expires: May 2002 [page 13]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
specific managed resource has an RDN component which uniquely
identifies that explicit resource, with this RDN residing within
the inetResources container entry.
For example, an entry for the DNS domain resource type associated
with the "www.example.com" domain name might have a DN of
"cn=www.example.com,cn=inetResources,dc=example,dc=com".
Similarly, an IPv4 network resource type associated with the IPv4
network address of "192.0.2.0" might have a DN of
"cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although the
exact naming syntax is different for each resource, the position
of the name within a DIT is predictable.
Most resource types cannot be located through simple LDAP browsing
and equality matching search operations. 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, so finding the entry associated with a specific IPv4
address will require the client to use the inetIpv4NetworkMatch
extensible matching search operation, and this matching rule
locates such entries by analyzing the DNs of resource-specific
entries. In this regard the use of predictable naming is still
extremely important, even though the client may not be able to
locate an entry programmatically based on a search value alone.
The naming rules associated with each resource type are described
in section 5.
4.5. Redirects and Referrals
A critical objective for this service is the ability for servers
to redirect clients to other DITs or entries when necessary.
Towards this goal, 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
in order for the original query to be completely processed.
Hall & Newton I-D Expires: May 2002 [page 14]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 with this service are
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 URLs which are subject to a series of
service-specific formatting restrictions that are somewhat tighter
than the source specifications allow.
Among these rules:
* Sources and targets 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, and target entries MUST comply
with the naming rules for the target resource type.
* Referral sources and targets MUST have the same resource-
specific object classes defined (a referral source and
target for a DNS domain resource would both have the
inetDnsDomain object class defined, for example). 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.
* Targets MAY be referrals for other resources, but
excessively recursive referrals are discouraged.
* [namedref] and RFC 2079 specify that URLs are multi-valued.
However, the redirection mechanisms supported in this
specification are limited to one URL.
* The protocol identifier of a URL MUST specify either the
LDAP or LDAPS (LDAP over TLS/SSL) service types.
Hall & Newton I-D Expires: May 2002 [page 15]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
* The host identifier MUST specify a domain name which is
resolvable with a DNS SRV resource record lookup.
* Port numbers SHOULD NOT be specified in the URL, and MUST
be ignored if they present (SRV resource records provide
port numbers for the servers associated with the queried
domain name).
* If a URL contains extended characters which must be escaped
in order for the character to be sent in a URL, the URL
must be stored in the escaped form. For example, the IPv4
and IPv6 addressing syntaxes defined for this document
require the use of a "/" character in order to indicate an
associated network prefix. If such an address needs to be
specified in a URL, the URL must be stored with the "/"
character already escaped (using "%2F" in this example).
* Implementations MUST NOT restrict the URL values to known
entries from local partitions. Implementations MAY validate
targets, and they are encouraged to prevent errors where
the target partition is known, but a lack of knowledge
regarding a target MUST NOT be cause to prevent the entry
from being specified.
Each of the supported redirection mechanisms are discussed in more
detail below.
4.5.1. Subordinate reference referrals
Subordinate reference referrals are returned when the search base
for an operation exists as a referral object class, pointing to
some other entry in some other DIT.
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 another DIT for the purpose of consolidated
resource management.
Hall & Newton I-D Expires: May 2002 [page 16]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 object class MUST be defined in conjunction with the
object class definition which is appropriate to the resource type
in question. For example, a "cn=inetResources" entry which was
implemented as a subordinate reference referral would need to have
the inetResources and referral object classes defined, while a DNS
domain resource-specific entry such as "dc=example.com" would need
to have the inetDnsDomain and referral object classes defined
(among the other object class definitions which were inherited by
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.
To illustrate this point, assume that a reverse-lookup DNS domain
DIT is being referenced to a forward-lookup DNS domain DIT, in
order to allow for consolidated resource management. In such a
scenario, "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"
could have the inetDnsDomain and the referral object classes
defined, with the value of the ref attribute carrying an LDAP URL
for "ldap://example.com/cn=inetResources,dc=example,dc=com".
Whenever a query was received that specified the inetResources
container entry of the reverse-lookup DIT, a referral would be
returned which informed the client that the query needed to be
restarted, using the "cn=inetResources,dc=example,dc=com"
container entry as the new search base.
Client rules for processing subordinate reference referrals are
given in section 7.4.1.
4.5.2. Continuation reference referrals
Continuation reference referrals are returned when a search
operation has been successfully initiated, but the answer data
includes referrals to other entries in some other DITs. These
referrals are often provided as supplemental data to an answer
set, although this is not required (a continuation reference
referral MAY be the only response, but it won't be the only
response in the most common case).
Hall & Newton I-D Expires: May 2002 [page 17]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 resource in question, and MAY include
data from user-definable attributes (such as "mail" and
"description"), but one or more entries are required 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.
For example, a domain registrar may have an entry for the
"example.com" DNS domain resource, with this entry possibly having
the DN of "cn=example.com,cn=inetResources,dc=netsol,dc=com". Such
an entry would most likely contain information related to the
delegation status of the "example.com" domain. However, if the
administrators of that DIT knew of a DN which was managed by the
"example.com" organization directly, that information could be
provided as a continuation reference referral by creating another
entry underneath the primary entry (perhaps with a DN of
"cn=cref1,cn=example.com,cn=inetResources,dc=netsol,dc=com"), with
this entry containing a ref attribute that pointed to the remote
DN (such as "ldap://example.com/cn=example.com,cn=inetResources,
dc=example,dc=com" in this case).
Client rules for processing continuation reference referrals are
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
currently being viewed. Attribute references use the same basic
syntax as the labeledURI attribute defined in RFC 2079 (with some
additional restrictions, as provided 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
URL in order to locate and read the inetOrgPerson entries,
although such actions are secondary to the original query process,
and are typically only performed at the user's request. Additional
Hall & Newton I-D Expires: May 2002 [page 18]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
documents may reuse the attribute reference format and URLs or
define their own URL handling rules, as necessary.
The attribute reference URL uses 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. This syntax is useful for human
consumption, and is encouraged where appropriate. For example, a
URL of "ldap://example.com/cn=admins,ou=admins,dc=example,dc=com
Network administration role account" SHOULD result in that text
description being displayed to the user, presumably as useful and
potentially informative data.
Client rules for processing attribute references are given in
section 7.4.4.
5. The LDAP-WHOIS Object Classes and Attributes
This document defines a general framework for locating resource
data in a distributed environment, and a part of this definition
includes schema definitions for global objects such as the
inetResources container. This document also defines four resource-
specific applications of this model (collectively referred to as
the LDAP-WHOIS service), which also have naming and schema
definitions that are designed to facilitate locating and searching
global Internet resources (such as DNS domains, IPv4 addresses,
and so forth).
The following schema are defined 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 network resources, 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.
Hall & Newton I-D Expires: May 2002 [page 19]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
* 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.
* Autonomous system (AS) identifiers. IPv4 and IPv6 networks
can also 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 number assignments, and is also subordinate to the
inetResources object class.
In addition to these object class definitions, this document also
makes explicit use of some pre-existing schema. In particular,
this document makes extensive use of the inetOrgPerson object
class, and dictates the use of this object class in the context of
the LDAP-WHOIS service.
Each of the attributes and object classes listed above represent
the Internet-wide network resources which MAY be offered by an
LDAP-WHOIS server or client. The mechanisms defined in this
document are designed to be extended with additional network
resource definitions.
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: May 2002 [page 20]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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: May 2002 [page 21]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 )
)
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: May 2002 [page 22]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 mast 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 mast 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: May 2002 [page 23]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetResourceComments
( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC
'General comments about this entry' EQUALITY
caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{1024} )
inetSecurityContacts
( 1.3.6.1.4.1.7161.1.0.8 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.9 NAME
'inetSecurityContactsModifiedBy' DESC 'Person who last mast
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.10 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.11 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.12 NAME 'inetTechContactsModifiedBy'
DESC 'Person who last mast modified the inetTechContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetTechContactsModifiedDate
( 1.3.6.1.4.1.7161.1.0.13 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 )
Hall & Newton I-D Expires: May 2002 [page 24]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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.
Figure 3: The Example Widgets inetResources container entry.
cn=inetResources,dc=example,dc=com
[inetResources object class]
|
+-attribute: o
| value: "Example Widgets' network resources"
|
+-attribute: inetGeneralContacts
| value: "ldap://example.com/cn=admins,ou=admins,
| dc=example,dc=com"
|
Hall & Newton I-D Expires: May 2002 [page 25]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
+-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.
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 network
resource MUST have a dedicated entry in each of the DITs which
provide public LDAP-WHOIS data regarding that domain name. 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
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
Hall & Newton I-D Expires: May 2002 [page 26]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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), 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 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 and to minimize
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.
For example, STD 13 and RFC 2253 both use a common method of
escaping special characters with a reverse solidus (backslash)
character, and by following the escape character with the special
character itself, or with a two-digit decimal code for the
character which has been escaped. If a user needs to specify a
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 provided to 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.
Hall & Newton I-D Expires: May 2002 [page 27]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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. The
maximum size of a valid DNS domain name is 255 characters (this
limit applies to the unescaped domain name, and does not include
escape sequences). Clients MUST restrict assertion values to this
range on input, 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
syntax would also be used to form the RDN for the associated
inetDnsDomain entry.
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.
Hall & Newton I-D Expires: May 2002 [page 28]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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.
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 ) )
The attributes from the inetDnsDomain object class are described
below:
inetDnsContacts
( 1.3.6.1.4.1.7161.1.1.2 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 )
Hall & Newton I-D Expires: May 2002 [page 29]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetDnsContactsModifiedBy
( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContactsModifiedBy'
DESC 'Person who last mast 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.4 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.5 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.6 NAME 'inetDnsDelegationModifiedBy'
DESC 'Person who last mast 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.7 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.8 NAME 'inetDnsDelegationStatus' DESC
'Current delegation status code for this domain.' EQUALITY
numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2}
SINGLE-VALUE )
Hall & Newton I-D Expires: May 2002 [page 30]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 Temporarily inactive (pending dispute resolution)
4 Revocation pending (database purge pending)
5 Revoked but still active (database purged)
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
[inetDnsDomain and inetResources object classes]
|
+-attribute: description
| [inherited from inetResources]
| value: "The example.com DNS domain"
|
Hall & Newton I-D Expires: May 2002 [page 31]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
+-attribute: inetDnsContacts
| [inherited from inetDnsDomain]
| value: "ldap://example.com/cn=hostmaster,ou=admins,
| dc=example,dc=com"
|
+-attribute: inetGeneralContacts
[inherited from inetResources]
value: "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 each sub-component being separated by a full-stop
(period) character, and with the four-part sequence being followed
Hall & Newton I-D Expires: May 2002 [page 32]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
by a "/" character and a three-digit decimal "prefix" value. An
augmented BNF for this syntax is as follows:
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 numeric value of "0".
Note that the use of "/" as data in LDAP URLs is illegal. This
character MUST be escaped as "%2F" when an inetIpv4Network entry
is specified 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: May 2002 [page 33]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 $
inetAssociatedAsNumber ) )
The attributes from the inetIpv4Network object class are described
below:
inetAssociatedAsNumber
( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAssociatedAsNumber' DESC
'The autonomous system number directly associated with this
network.' EQUALITY caseIgnoreMatch SYNTAX
inetAsNumberSyntax SINGLE-VALUE )
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 )
Hall & Newton I-D Expires: May 2002 [page 34]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetIpv4ContactsModifiedBy
( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy'
DESC 'Person who last mast modified the inetIpv4Contacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
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 mast 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: May 2002 [page 35]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 Temporarily inactive (pending dispute resolution)
4 Revocation pending (database purge pending)
5 Revoked but still active (database purged)
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
mast 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 )
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.' )
Hall & Newton I-D Expires: May 2002 [page 36]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
[inetIpv4Network and inetResources object classes]
|
+-attribute: description
| [inherited from inetResources]
| value: "The example.com network"
|
+-attribute: inetIpv4Contacts
| [inherited from inetIpv4Network]
| value: "ldap://example.com/cn=hostmaster,ou=admins,
| dc=example,dc=com"
|
+-attribute: inetGeneralContacts
[inherited from inetResources]
value: "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
often used to represent the starting address of an IPv6 network,
but can also be used to identify a specific host).
Hall & Newton I-D Expires: May 2002 [page 37]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
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
Hall & Newton I-D Expires: May 2002 [page 38]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 "/" as data in LDAP URLs is illegal. This
character MUST be escaped as "%2F" when an inetIpv6Network entry
is specified 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.
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: May 2002 [page 39]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 $
inetAssociatedAsNumber ) )
The attributes from the inetIpv6Network object class are described
below:
inetAssociatedAsNumber, see section 5.3
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 mast 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 )
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 )
Hall & Newton I-D Expires: May 2002 [page 40]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetIpv6DelegationModifiedBy
( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy'
DESC 'Person who last mast 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 Temporarily inactive (pending dispute resolution)
4 Revocation pending (database purge pending)
5 Revoked but still active (database purged)
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.
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 )
Hall & Newton I-D Expires: May 2002 [page 41]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetIpv6RoutingContactsModifiedBy
( 1.3.6.1.4.1.7161.1.3.10 NAME
'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last
mast 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.
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
[inetIpv6Network and inetResources object classes]
|
+-attribute: description
| [inherited from inetResources]
| value: "The example.net top-level network"
|
Hall & Newton I-D Expires: May 2002 [page 42]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
+-attribute: inetIpv6Contacts
| [inherited from inetIpv6Network]
| value: "ldap://example.com/cn=hostmaster,ou=admins,
| dc=example,dc=net"
|
+-attribute: inetGeneralContacts
[inherited from inetResources]
value: "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. 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
Hall & Newton I-D Expires: May 2002 [page 43]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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, the status of the
delegation, and the IPv4 and IPv6 networks which are directly
associated with the AS number. 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.
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);
Hall & Newton I-D Expires: May 2002 [page 44]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 $ inetAsnIpv4Networks $
inetAsnIpv4NetworksModifiedBy $
inetAsnIpv4NetworksModifiedDate $ inetAsnIpv6Networks $
inetAsnIpv6NetworksModifiedBy $
inetAsnIpv6NetworksModifiedDate ) )
The attributes from the inetIpv4Network object class are described
below:
inetAsnContacts
( 1.3.6.1.4.1.7161.1.4.3 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.4 NAME 'inetAsnContactsModifiedBy'
DESC 'Person who last mast modified the inetAsnContacts
attribute.' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
distributedOperation )
inetAsnContactsModifiedDate
( 1.3.6.1.4.1.7161.1.4.5 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 )
Hall & Newton I-D Expires: May 2002 [page 45]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetAsnDelegationDate
( 1.3.6.1.4.1.7161.1.4.6 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.7 NAME 'inetAsnDelegationModifiedBy'
DESC 'Person who last mast 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.8 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.9 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 )
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 Temporarily inactive (pending dispute resolution)
4 Revocation pending (database purge pending)
5 Revoked but still active (database purged)
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: May 2002 [page 46]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetAsnIpv4Networks
( 1.3.6.1.4.1.7161.1.4.10 NAME 'inetAsnIpv4Networks' DESC
'The IPv4 networks directly associated with this AS number'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX inetIpv4NetworkSyntax )
inetAsnIpv4NetworksModifiedBy
( 1.3.6.1.4.1.7161.1.4.11 NAME
'inetAsnIpv4NetworksModifiedBy' DESC 'Person who last mast
modified the inetAsnIpv4Networks attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetAsnIpv4NetworksModifiedDate
( 1.3.6.1.4.1.7161.1.4.12 NAME
'inetAsnIpv4NetworksModifiedDate' DESC 'Last modification
date of the inetAsnIpv4Networks attribute.' EQUALITY
generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
distributedOperation )
inetAsnIpv6Networks
( 1.3.6.1.4.1.7161.1.4.13 NAME 'inetAsnIpv6Networks' DESC
'The IPv6 networks directly associated with this AS number'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX inetIpv6NetworkSyntax )
inetAsnIpv6NetworksModifiedBy
( 1.3.6.1.4.1.7161.1.4.14 NAME
'inetAsnIpv6NetworksModifiedBy' DESC 'Person who last mast
modified the inetAsnIpv6Networks attribute.' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE USAGE distributedOperation )
inetAsnIpv6NetworksModifiedDate
( 1.3.6.1.4.1.7161.1.4.15 NAME
'inetAsnIpv6NetworksModifiedDate' DESC 'Last modification
date of the inetAsnIpv6Networks 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: May 2002 [page 47]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
inetAsnRoutingContacts
( 1.3.6.1.4.1.7161.1.4.16 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.17 NAME
'inetAsnRoutingContactsModifiedBy' DESC 'Person who last
mast 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.18 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.' )
5.5.3. Example
An example of the inetAsNumber 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 associated
with the "arin.net" domain.
Hall & Newton I-D Expires: May 2002 [page 48]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
Figure 7: The inetAsNumber delegation entry for AS 65535.
cn=65535,cn=inetResources,dc=arin,dc=net
[inetAsNumber and inetResources object classes]
|
+-attribute: description
| [inherited from inetResources]
| value: "The example.net network"
|
+-attribute: inetAsnContacts
| [inherited from inetAsNumber]
| value: "ldap://example.com/cn=hostmaster,ou=admins,
| dc=example,dc=net"
|
+-attribute: inetGeneralContacts
[inherited from inetResources]
value: "ldap://example.com/cn=admins,ou=admins,
dc=example,dc=net"
5.6. The inetOrgPerson Object Class
This document provides several contact-related attributes which
use LDAP URLs to refer to 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, and MUST refer to an entry in a DIT
which uses the domainComponent object class syntax ("dc=").
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
Hall & Newton I-D Expires: May 2002 [page 49]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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.7. The referral Object Class
This document allows the use of the referral object class to
define subordinate reference referrals and continuation reference
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.
5.8. 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-
Hall & Newton I-D Expires: May 2002 [page 50]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
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 read-
only 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.
Hall & Newton I-D Expires: May 2002 [page 51]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 should be returned, the type of comparison
operation that needs to be performed, and other details. In order
to promote interoperability, many of these elements are defined
with default settings for use with the LDAP-WHOIS service.
In particular, this document defines several suggested and
mandatory search filter qualifiers, which are described in detail
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-
Hall & Newton I-D Expires: May 2002 [page 52]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
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 such clients MUST
be prepared to issue the necessary subsequent queries.
Hall & Newton I-D Expires: May 2002 [page 53]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
* 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),
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.
Hall & Newton I-D Expires: May 2002 [page 54]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 )
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)".
Hall & Newton I-D Expires: May 2002 [page 55]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 data which
is received MUST be displayed by the client. If a subordinate
reference referral is received as part of the answer set, 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 to the original operation's output.
6.2.2. inetIpv4NetworkMatch
The inetIpv4NetworkMatch filter provides an identifier and search
string format which collectively inform a queried server that a
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.
Hall & Newton I-D Expires: May 2002 [page 56]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
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 as part of the answer
set, 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 to the original operation's output.
Hall & Newton I-D Expires: May 2002 [page 57]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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.
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)".
Hall & Newton I-D Expires: May 2002 [page 58]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 as part of the answer
set, 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 to the original operation'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
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.
Hall & Newton I-D Expires: May 2002 [page 59]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 as part of the answer set, 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 to the
original operation's output.
7. Query Processing Models
The LDAP-WHOIS service uses three different query-processing
models. These are the "top-down" model which uses service-specific
delegation hierarchies to direct queries through a tree, a
"bottom-up" model which uses DNS delegation data to direct queries
to user-managed servers, and a "targeted" search model which is
functionally identical to traditional LDAP searches. Furthermore,
each of these mechanisms may require additional search operations
as a result of subordinate reference referrals, continuation
reference referrals, or attribute references.
Each of the 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,
although clients MUST default to using the top-down model, but
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
Hall & Newton I-D Expires: May 2002 [page 60]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 DNS lookups to map a queried string to a
delegation entity's LDAP servers. Once this process completes,
additional LDAP search operations are processed in order to
produce supplemental answer sets.
For example, a search operation with the assertion value of
"www.example.com" would result in the client attempting to locate
the LDAP servers responsible for the "com" domain. Once a server
had been located, the client would issue an extensibleMatch search
for "www.example.com", using "cn=inetResources,dc=com" as the
search base. If the queried server had data about that resource,
it could 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 or a referral, 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. The bottom-up or targeted
search models MUST be used for those resource types.
The top-down model uses DNS delegation data in many of the
operations, although it is not strictly tied to the DNS delegation
hierarchy. For example, when the first query is issued, the client
would use DNS to locate the LDAP servers for the top-level domain
associated with the resource name and type. However, a referral
could point to an LDAP entry which was outside of the delegation
hierarchy (possibly returning a referral for a domain registry
Hall & Newton I-D Expires: May 2002 [page 61]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
entity such as "dc=netsol,dc=com", or an IPv4 assignment body such
as "dc=arin,dc=net"). Although those entries are also subject to
DNS lookups for their SRV resource records, the query chain will
have diverged from the original DNS delegation hierarchy, meaning
that each resource type has a namespace which is different from
the underlying DNS namespace.
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 DNS domain names, this would be
"www", "example" and "com". For an IPv4 network
number, 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
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.
Hall & Newton I-D Expires: May 2002 [page 62]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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".
4. Submit the search operation. 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. 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,
appending the output from these searches to the
current output.
Any additional subordinate reference referrals or
continuation reference referrals which are encountered
Hall & Newton I-D Expires: May 2002 [page 63]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
assertion value of "www.example.com" and a search base of
"cn=inetResources,dc=com".
d. The server responds with a continuation reference referral
with the LDAP URL of "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. The client uses the continuation reference information
to start a new query process. No additional data was
provided for the client to display.
e. The "netsol.com" host identifier in the URL is used to form
a new DNS SRV query for the LDAP servers associated with
the domain name of "_ldap._tcp.netsol.com".
f. An inetDnsDomainMatch extensibleMatch search is submitted
to one of the LDAP servers, using the search base of
"cn=example.com,cn=inetResources,dc=netsol,dc=com".
g. The queried server returns the information that it has. No
additional referrals are provided. The client displays the
data and exits the query.
Hall & Newton I-D Expires: May 2002 [page 64]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 through a
delegation hierarchy would be either fruitless or inefficient.
The bottom-up model uses DNS lookups to map a queried string to an
LDAP server which is directly responsible for that resource. In
case of failure, the query is incrementally broadened until a
server is located (or until a non-recoverable error occurs). Once
this process completes, additional LDAP search operations are
processed in order to produce supplemental answer sets.
The bottom-up approach relies almost exclusively on DNS delegation
authority, and this makes it appropriate for locating resources
which are not delegated by centralized management authorities. For
example, some private keys are created and managed by end-users
directly, and those resources would be most effectively queried
for in a bottom-up model. Similarly, retrieving mail-routing data
associated with 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 approach is predominately useful for resources which
are managed by the operational entities responsible for those
resources. This includes entries which have unique attributes
within an organization (such as web servers or mail-routing hosts,
each of which may have unique operational contacts),
infrastructure devices which are leased from third-parties (and
which have different organizational attributes, even though they
"reside in" the end-user's DIT), and private keys or other user-
managed resources which would benefit from being queried
individually, rather than being queried as globally unique,
centrally delegated resource.
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.
Hall & Newton I-D Expires: May 2002 [page 65]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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. The top-down or
targeted search models MUST be used for those resource types.
In the bottom-up model, a query with the assertion value of
"www.example.com" would result in the client attempting to locate
the LDAP servers responsible for the "www.example.com" domain
name. If this lookup failed, a subsequent DNS query might attempt
to locate the LDAP servers responsible for the "example.com"
domain, which might be followed by yet another DNS query for the
LDAP servers associated with the "com" domain.
If an LDAP for the "example.com" domain were located, the client
would issue an inetDnsDomainMatch extensibleMatch search for
"www.example.com", using "cn=inetResources,dc=example,dc=com" as
the search base. If the queried server had data about that
resource, it would be returned. If the server knew of other
sources of information about the resource, referrals to those
entries would be returned for the client to process.
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.
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 DNS domain names, this would be
"www", "example" and "com". For an IPv4 network
Hall & Newton I-D Expires: May 2002 [page 66]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
number, 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: May 2002 [page 67]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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. 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: May 2002 [page 68]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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. 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,
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: May 2002 [page 69]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
e. The server returns a continuation reference referral of
"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. The "example.net" host identifier in the URL is used to
form a new DNS SRV query for the LDAP servers associated
with the domain name of "_ldap._tcp.example.net".
g. An inetDnsDomainMatch extensibleMatch search is submitted
to one of the LDAP servers, using the search base of
"cn=server1.example.net,cn=inetResources,dc=example,dc=net"
h. 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: May 2002 [page 70]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 search base and
assertion value of the query, and will also generate DNS
SRV lookups for the LDAP servers associated with the URL.
b. 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. Submit the search operation. If the operation fails,
report the failure to the user and exit. Otherwise,
display any answer data which is returned.
4. 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.
Hall & Newton I-D Expires: May 2002 [page 71]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
c. 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.3.2. Targeted search example
In the example below, the user has provided an LDAP URL of
"ldap://example.com/cn=hostmaster,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 the DNS SRV lookup
("_ldap._tcp.example.com"), in order to find the LDAP
servers authoritative for that domain name.
b. The client contacts one of the servers, and issues a search
for "(&(objectclass=inetOrgPerson)(cn:dn:=hostmaster))",
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.
Hall & Newton I-D Expires: May 2002 [page 72]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
* 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.
* 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.
In order to facilitate multi-tiered searching, the use of URLs
with subordinate and continuation reference referrals and
attribute references MUST be limited to single-valued responses,
MUST specify the LDAP or LDAPS protocols, MUST specify domain
names which are resolvable with DNS SRV lookups, and MUST NOT
specify port numbers. All of the URLs provided as part of LDAP-
WHOIS service (regardless of their type) MUST specify a domain
name and a path. Relative URLs without a domain identifier are
explicitly forbidden by this specification, as are URLs that do
not contain a path specification.
Non-compliance with these requirements amounts to an error, and is
sufficient cause to stop processing a query.
Clients MAY implement support for additional protocol identifiers,
and MAY attempt to resolve the IP address of a host part
identifier if an SRV lookup fails (these may be useful features
for browsing traditional LDAP servers or DITs). 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 sections 7.1, 7.2, and 7.3).
Hall & Newton I-D Expires: May 2002 [page 73]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 to be 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 output from processing a subordinate reference referral URL
consists of a set of SRV resource records associated with a domain
name, and a search base. These elements are used to restart a
current search operation.
The procedure for processing the URL returned in a subordinate
reference referral is as follows:
a. Validate that the attribute value only contains a single
URL. This specification explicitly requires that only one
URL be provided with subordinate reference referrals.
b. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are treated as malformed.
c. Extract the host identifier element and prepare to issue an
SRV lookup against the provided domain name. This
specification explicitly requires that host identifiers
provide domain names which are usable for SRV lookups, and
Hall & Newton I-D Expires: May 2002 [page 74]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
does not support the use of host-specific identifiers. URLs
without host identifiers are to be treated as malformed.
d. Extract and discard the port number identifier, if one has
been provided in the URL. SRV resource records provide port
numbers as answer data.
e. 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.
f. Extract and discard any description text which may have
been provided with the URL.
g. Process the domain name from step 7.4.2.c with an SRV
lookup, as described in section 7.4.5.
h. Restart the current search operation, using the path from
step 7.4.2.e as the new search base.
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.
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.
Hall & Newton I-D Expires: May 2002 [page 75]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
The output from processing a continuation reference referral URL
consists of a set of SRV resource records associated with a domain
name, a search base, and an assertion value. These elements are
used to start new search operations.
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 URL returned in a continuation
reference referral is as follows:
a. Validate that the attribute value only contains a single
URL. This specification explicitly requires that only one
URL be provided with continuation reference referrals.
b. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are treated as malformed.
c. Extract the host identifier element and prepare to issue an
SRV lookup against the provided domain name. This
specification explicitly requires that host identifiers
provide domain names which are usable for SRV lookups, and
does not support the use of host-specific identifiers. URLs
without host identifiers are to be treated as malformed.
d. Extract and discard the port number identifier, if one has
been provided in the URL. SRV resource records provide port
numbers as answer data.
e. 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.
f. Extract the left-most RDN from the search base constructed
in step 7.4.3.e, and remove the naming attribute label from
the resulting value. This string will be used as the
assertion value for the subsequent search operation. For
example, if the path element 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 the new
assertion value of "example.com".
g. Extract and discard any description text which may have
been provided with the URL.
Hall & Newton I-D Expires: May 2002 [page 76]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
h. Process the domain name from step 7.4.3.c with an SRV
lookup, as described in section 7.4.5.
i. Start a new search operation, using the new search base
formed in step 7.4.3.e, and the new assertion value formed
in step 7.4.3.f.
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.
Attribute references use the "url://domain.name/distinguished/name
description" two-part URL syntax from RFC 2079, although section
4.5 of this document also defines additional restrictions on the
allowable URL syntax.
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 output from processing a continuation reference referral URL
consists of a set of SRV resource records associated with a domain
name, a search base, an assertion value, and an object class
filter. These elements are used to start new search operations.
The procedure for processing the URL returned in an attribute
reference is as follows:
a. Validate that the attribute value only contains a single
URL. This specification explicitly requires that only one
URL be provided with attribute references.
b. Validate the protocol label. This specification only
supports the use of LDAP and LDAPS service types. URLs with
other protocol identifiers are treated as malformed.
Hall & Newton I-D Expires: May 2002 [page 77]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
c. Extract the host identifier element and prepare to issue an
SRV lookup against the provided domain name. This
specification explicitly requires that host identifiers
provide domain names which are usable for SRV lookups, and
does not support the use of host-specific identifiers. URLs
without host identifiers are to be treated as malformed.
d. Extract and discard the port number identifier, if one has
been provided in the URL. SRV resource records provide port
numbers as answer data.
e. 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.
f. Extract the left-most RDN from the search base constructed
in step 7.4.4.e, and remove the naming attribute label from
the resulting value. This string will be used as the
assertion value for the subsequent search operation. For
example, if the path element 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 the new
assertion value of "example.com".
g. 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.
h. Extract and discard any description text which may have
been provided with the URL.
i. Process the domain name from step 7.4.4.c with an SRV
lookup, as described in section 7.4.5.
j. Start a new search operation, using the new search base
formed in step 7.4.4.e, the new assertion value formed in
step 7.4.4.f, and the new object class filter formed in
step 7.4.4.g.
Hall & Newton I-D Expires: May 2002 [page 78]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
7.4.5. SRV processing
The query models described in this document make extensive use of
DNS SRV resource records in order to locate the LDAP servers which
are authoritative for a particular resource (as specified by an
input search string or a response URL).
In both cases, a DNS domain name is constructed from the input,
and a DNS SRV lookup is issued. The SRV resource records returned
in response to such a query will identify the LDAP servers
responsible for the queried domain name.
The procedure for constructing this SRV lookup is as follows:
a. Determine the service type associated with the request. For
URLs, this will be indicated by a protocol identifier of
either LDAP or LDAPS (for LDAP over SSL/TLS). For input
queries, no identifier will be available, and the default
assumption is LDAP.
b. Construct an SRV-specific label pair for the service type.
For LDAP queries, this will be "_ldap._tcp", while LDAPS
will use "_ldaps._tcp".
c. 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".
d. Issue a DNS query for the SRV resource records associated
with the domain name formed in step 7.4.5.c.
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.
Hall & Newton I-D Expires: May 2002 [page 79]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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 attribute data, since the attribute
types already provide direct support for internationalized data.
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.
Branching 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
Hall & Newton I-D Expires: May 2002 [page 80]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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.
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 an additional
query). 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. 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.
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.
Furthermore, some operators may purposefully choose to provide
misleading or erroneous information in an effort to avoid or
escape responsibility for abusive behavior.
In addition to the above, there are likely to be sporadic operator
errors which will result in confusing or erroneous answers.
For the reasons listed above, it is important that applications
not make critical decisions based on the information provided
without having reason to believe the veracity of the information.
Clients and users should limit the use of 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.
Hall & Newton I-D Expires: May 2002 [page 81]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
11. 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
in the generic TLDs and the root domain, and also includes
administering the referenced LDAP servers.
12. 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
Hall & Newton I-D Expires: May 2002 [page 82]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
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
RFC 2849 - The LDAP Data Interchange Format (LDIF) -
Technical Specification
[namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named
Subordinate References in LDAP Directories
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.
13. Author's Addresses
Eric A. Hall
ehall@ehsco.com
Andrew Newton
anewton@research.netsol.com
14. 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.
Hall & Newton I-D Expires: May 2002 [page 83]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
14.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. Given its limited global usability, it is
implicitly deprecated in this document and is replaced with a
model that uses DNs for the lookup function. DNs provide the same
basic functionality, but they work in a global distributed multi-
server environment.
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 server could 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.
14.2. Nameserver Attributes
WHOIS servers for DNS domains have historically provided
information about the DNS servers associated with a domain, such
as providing the hostnames and IP addresses of the DNS servers
which have been delegated authority over a particular domain.
One problem with providing this information in the LDAP-WHOIS
model is that it is difficult to integrate the data cleanly. The
best design for such a service would entail an auxiliary object
class for the inetDnsDomain object class which provided resource
record attributes, and which stored NS and the associated A
Hall & Newton I-D Expires: May 2002 [page 84]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
resource records as directory objects. While such a structure
would provide multiple benefits to multiple problems, it seems
imprudent to pursue this approach for the single short-term
objective of caching delegation name servers.
For this reason, attributes for this information are not provided
in the LDAP-WHOIS service. Instead, users and application
developers are encouraged to develop practices for querying the
DNS zones for information related to DNS. However, if this
information is absolutely required, server operators MAY provide
it as unstructured data in the inetGeneralComments free-text
attribute (possibly using a name:address pair for each server).
14.3. 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 necessarily useful to external
entities. 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 the public
view of the data via the LDAP-WHOIS service.
Furthermore, it is difficult to mimic this usage in an LDAP-based
WHOIS service in a form which can be easily parsed. Even though it
would be possible to provide multi-value free-text fields which
provide a similar service, the data would not be subject to
referential integrity or programmatic parsing.
For these reasons, this service is not provided 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).
Hall & Newton I-D Expires: May 2002 [page 85]
INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001
14.4. 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]
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] [ ]
http://www.ripe.net/ripe/docs/databaseref-manual.html
* The URL processing defined in this document does not follow
"normal" URL processing rules. This is due to a strong
desire to leverage the load-distribution functionality
provided by SRV resource records, although URLs and SRV
resource records overlap in some areas, yet both of them
provide critical information to the referral process. In
order for these two services to work together, the URL
syntax has been optimized for use with this service (this
practice is not entirely uncommon). However, this problem
will not be completely resolved until a standards-track
effort confronts the issue globally.
Hall & Newton I-D Expires: May 2002 [page 86]