One document matched: draft-ietf-crisp-firs-dnsrr-02.txt
Differences from draft-ietf-crisp-firs-dnsrr-01.txt
INTERNET-DRAFT Eric A. Hall
Document: draft-ietf-crisp-firs-dnsrr-02.txt July 2003
Expires: February, 2004
Category: Standards-Track
Defining and Locating DNS Resource Records
in the Federated Internet Registry Service
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines LDAP schema and searching rules for DNS
resource records, in support of the Federated Internet Registry
Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE].
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
Table of Contents
1. Introduction..............................................2
2. Prerequisites and Terminology.............................3
3. Naming syntax.............................................3
4. Object Classes and Attributes.............................3
5. Query Processing..........................................6
6. Security Considerations...................................7
7. IANA Considerations.......................................7
8. Normative References......................................7
9. Changes from Previous Versions............................8
10. Author's Address..........................................8
11. Acknowledgments...........................................8
12. Full Copyright Statement..................................9
1. Introduction
This specification defines the naming syntax, object classes,
attributes, matching filters, and query processing rules for
storing and locating DNS resource records in the FIRS service.
Refer to [FIRS-ARCH] for information on the FIRS architecture and
[FIRS-CORE] for the schema definitions and rules which govern the
FIRS service as a whole.
DNS resource records are intended to be stored in FIRS whenever
the resource record data is useful or necessary. In the common
case, this data will provide the IP addresses which are associated
with a known "nameserver" host. In that scenario, the relative
distinguished name of the entry will be the fully-qualified domain
name of the host, with the multi-valued inetDnsRRData attribute
providing each of the "A" or "AAAA" resource records associated
with that host.
Although that specific information could be provided with narrow-
use attributes, this specification provides a generalized storage
format for DNS resource records so that other kinds of resource
record data may also be stored in FIRS, when desirable. For
example, it is feasible that another application of FIRS may need
to retrieve "MX" resource records or "SOA" resource records
associated with a domain name, and using a generalized format
facilitates these eventual application scenarios. Furthermore,
some DNS servers are known to store zone data in LDAP, and the use
of a generalized format facilitates interoperability.
Hall I-D Expires: February 2004 [page 2]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
Note that these rules and definitions only apply to DNS resource
records in FIRS, and do not apply to domainComponent entries or
any other domain name elements, unless explicitly defined.
The definitions in this specification are intended to be used with
FIRS. Their usage outside of FIRS is not prohibited, but any such
usage is beyond this specification's scope of authority.
2. Prerequisites and Terminology
The complete set of specifications in the FIRS collection
cumulative define a structured and distributed information service
using LDAPv3 for the data-formatting and transport functions. This
specification should be read in the context of that set, which
currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS],
[FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6].
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. Naming syntax
This specification does not define new syntax rules. DNS resource
records are provided as supplemental data to DNS domain name
entries. As such, this data relies on pre-existing entries which
conform to the naming syntax defined in [FIRS-DNS].
4. Object Classes and Attributes
DNS resource record entries in FIRS MUST use the inetDnsRR object
class, in addition to the inetDnsDomain object class defined in
[FIRS-DNS] and the mandatory object classes defined in
[FIRS-CORE]. If an entry exists as a referral source, the entry
MUST also be defined with the referral object class, in addition
to the above requirements.
The inetDnsRR object class is an auxiliary object class which is
subordinate to the inetDnsDomain object class. The inetDnsRR
object class has no mandatory attributes, and has two optional
attributes. The inetDnsRR object class also inherits the
attributes defined in the inetDnsDomain and inetResources object
classes, including the "cn" naming attribute.
Hall I-D Expires: February 2004 [page 3]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
The schema definition for the inetDnsRR object class is as
follows:
inetDnsRR
( 1.3.6.1.4.1.7161.1.8.1
NAME 'inetDnsRR'
DESC 'DNS record records.'
SUP inetDnsDomain
AUXILIARY
MAY inetDnsRRData $ inetDnsRRDirective )
The inetDnsRRData attribute is a structured (SEQUENCE) attribute,
containing multiple subordinate attributes. The layout of the
subordinate attributes is identical to the layout of DNS resource
records in the domain name system data message. The inetDnsRRData
attribute is also multi-valued. This model allows multiple
resource records to be associated with each entry, with each
resource record having different types, classes, time-to-live
values, data values, and so forth.
The inetDnsRRData attribute is described as follows:
inetDnsRRData
( 1.3.6.1.4.1.7161.1.8.2
NAME 'inetDnsRRData'
DESC 'Generic DNS record record data.'
EQUALITY caseIgnoreMatch
SYNTAX inetDnsRRDataSyntax )
The inetDnsRRDataSyntax syntax is defined in ASN.1 as follows:
inetDnsRRDataSyntax ::= SEQUENCE {
RRType INTEGER (0..65535),
RRClass INTEGER (0..65535),
RRTTL INTEGER (0..4294967295),
RRLen INTEGER (0..65535),
RRData OCTET STRING (SIZE (0..65535)) }
Note that the RRType and RRClass values are managed by IANA, and
are stored in the DNS parameter assignment registry.
Domain names which are stored in the RRData element MUST NOT use
the DNS compression mechanism. That compression mechanism relies
on the presence of existing domain names inside a DNS message, and
Hall I-D Expires: February 2004 [page 4]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
this storage system does not use DNS messages, so there would not
be any previous instances to reference.
The inetDnsRRDirective attribute provides a mechanism for storing
zone-file "directive" statements. Directives are textual sequences
which typically provide out-of-band data, such as default time-to-
live value for resource records in the zone. They are accommodated
here so that DNS systems which store and retrieve zone data in the
directory will be able also be able to store common directives.
Directives are not currently used with any FIRS applications.
The inetDnsRRDirective attribute stores a text string, and is
multi-valued.
inetDnsRRDirective
( 1.3.6.1.4.1.7161.1.8.3
NAME 'inetDnsRRDirective'
DESC 'Zone-file directives for this domain name.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
An example of the inetDnsRR object class in use is shown in Figure
1 below. The example includes attributes from the inetDnsRR,
inetDnsDomain, inetResources, and inetAssociatedResources object
classes.
Hall I-D Expires: February 2004 [page 5]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
cn=ns1.example.com,cn=inetResources,dc=example,dc=com
[top object class]
[inetResources object class]
[inetDnsDomain object class]
[inetDnsRR object class]
[inetAssociatedResources object class]
|
+-attribute: description
| value: "The master DNS server for the example.com domain"
|
+-attribute: inetDnsContacts
| value: "hostmaster@example.com"
|
+-attribute: inetDnsRRData
| value: 1, 1, 3600, 4, (0xC0 0x00 0x02 0x0E)
|
+-attribute: inetAssociatedDnsDomain
value: "example.com"
Figure 1: The entry for the ns1.example.com DNS domain name and
its associated resource records.
In the example shown above, the ns1.example.com domain name has a
single inetDnsRRData attribute, which provides a single IPv4
address resource record. The subordinate elements of that
attribute indicate a RRType value of "1" (IPv4 Address), a RRClass
value of "1" (the Internet class), a RRTTL value of 3600 (a TTL of
one hour), a RRLen value of 4 (four octets of data), and four
single-octet data values which mirror the DNS format of IPv4
addresses (in this case, the IPv4 address of "192.0.2.14").
5. Query Processing
This specification does not define new query processing rules. DNS
resource records are provided as supplemental data to DNS domain
name entries. As such, this data relies on the query processing
rules defined in [FIRS-DNS].
Note that the use of bottom-up processing is more likely to
succeed when searching for DNS domain names with resource record
attributes, since these entries are more likely to exist. However,
the default usage of top-down processing is still preferred.
Hall I-D Expires: February 2004 [page 6]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
6. Security Considerations
Security considerations are discussed in [FIRS-ARCH].
7. IANA Considerations
IANA considerations are discussed in [FIRS-ARCH].
8. Normative References
[FIRS-ARCH] Hall, E. "The Federated Internet Registry
Service: Architecture and Implementation
Guide", draft-ietf-crisp-firs-arch-02, July
2003.
[FIRS-ASN] Hall, E. "Defining and Locating Autonomous
System Numbers in the Federated Internet
Registry Service", draft-ietf-crisp-firs-asn-
02, July 2003.
[FIRS-CONTCT] Hall, E. "Defining and Locating Contact
Persons in the Federated Internet Registry
Service", draft-ietf-crisp-firs-contact-02,
July 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp-
firs-core-02, July 2003.
[FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in
the Federated Internet Registry Service",
draft-ietf-crisp-firs-dns-02, July 2003.
[FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource
Records in the Federated Internet Registry
Service", draft-ietf-crisp-firs-dnsrr-02, July
2003.
[FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address
Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv4-02, July
2003.
[FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address
Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv6-02, July
2003.
Hall I-D Expires: February 2004 [page 7]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R.,
and Sataluri, S. "Using Domains in LDAP/X.500
DNs", RFC 2247, January 1998.
[RFC2251] Wahl, M., Howes, T., and Kille, S.
"Lightweight Directory Access Protocol (v3)",
RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille,
S. "Lightweight Directory Access Protocol
(v3): Attribute Syntax Definitions", RFC 2252,
December 1997.
[RFC2254] Howes, T. "The String Representation of LDAP
Search Filters", RFC 2254, December 1997.
9. Changes from Previous Versions
draft-ietf-crisp-firs-dnsrr-02:
* Several clarifications and corrections have been made.
* Several attributes had their OIDs changed. NOTE THAT THIS
IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
draft-ietf-crisp-firs-dnsrr-01:
* Added the inetDnsRRDirective attribute.
* Added explanatory text to the introduction.
* Several clarifications and corrections have been made.
draft-ietf-crisp-firs-dnsrr-00:
* Restructured the document set.
10. Author's Address
Eric A. Hall
ehall@ehsco.com
11. Acknowledgments
Funding for the RFC editor function is currently provided by the
Internet Society.
Hall I-D Expires: February 2004 [page 8]
Internet Draft draft-ietf-crisp-firs-dnsrr-02.txt July 2003
Portions of this document were funded by VeriSign Labs.
Thanks to Stig Venaas for providing constructive feedback during
the early development of this specification.
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hall I-D Expires: February 2004 [page 9] | PAFTECH AB 2003-2026 | 2026-04-24 01:33:45 |