One document matched: draft-ietf-ipngwg-dns-reverse-lookup-00.txt
Internet-Draft O. Gudmundsson
IPng Working Group TIS
<draft-ietf-ipng-dns-reverse-lookup-00.txt> November 1997
Reverse Address lookup in DNS for IPng.
<draft-ietf-ipngwg-dns-reverse-lookup-00.txt>
Status of this Memo
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited.
Abstract
This document proposes a new mechanism to represent inverse address
mapping in the Domain Name System (DNS) for IP version 6 (IPv6).
Documented in here are the changes needed for securing the binding
and delegation of address ranges, to facilitate queries for the
binding of address to host name. This document also defines a
mechanism for dumb resolvers to query directly for the binding.
The changes include a new resource record to delegate the address
space in segments based on arbitrary bit boundaries. This proposal
provides a mechanism that is self checking and can be traversed
from both top and bottom. Additional processing requirements on
IPv6 aware resolvers and servers are defined.
Gudmundsson Expires May 1998 [Page 1]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
1. Introduction
Current support for the storage of Internet addresses in the Domain
Name System (DNS)[RFC1034,RFC1035,RFC2181] cannot easily be
extended to support IPv6 addresses[HD97] since applications assume
that address queries return 32-bit IPv4 addresses only.
A proposal to store IPv6 address was proposed[RFC1886] but that
proposal does not scale well to the new IPv6 address
architecture[HD97]. The main drawbacks are that there has to be a
AAAA record for all routing prefixes for every host. If one routing
prefix changes, all AAAA records affected need to be changed and,
if DNSSEC[RFC2065] is used, then all affected AAAA sets need to be
resigned. A new proposal[HT97] addresses a how IPv6 address lookup
can be accomplished while avoiding the above problems.
To support the lookup of the mapping from address to host name
(reverse lookup) for IPv6 addresses this document defines the
following extensions:
* A new domain is defined to support lookups based on address.
* A new resource record type to represent delegations in the
reverse map.
This memo proposes an incompatible extension to the specification
in RFC 1886, and a departure from current implementation practices,
but is as compatible with current practices as possible. The
structure defined in here can also be extended to other address
types, such as IPv4.
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 [RFC2119].
2. Motivation and Design criteria
Reverse address maps are used to identify what computer is trying
to connect to another computer. This is an essential tool for
network services providers, this is also used to debug network
problems.
Gudmundsson Expires May 1998 [Page 2]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
This document proposes a radical new way to handle reverse mapping
of addresses for IPng. The main motivations for this proposal are
to meet the following requirements:
* IPng new addressing architecture
* Support for rapid renumbering with minimal cost to DNS servers
* Allow the reverse address map to be maintained in a
distributed way similar to the forward address map
* Provide verifiable binding of addresses to names when
DNSSEC is used.
This design takes into account many of the lessons learned from the
problems in IPv4 reverse address maps when classless delegations
where introduced.
This proposal requires that the domain names in the reverse map be
binary values. This is done to save space and time. If the
community does not think this is a good idea it is possible to
encode the binary values in Base64 or Hex, but given that most
reverse lookups are performed by computers without any human
interaction this should not be a problem and will reduce DNS server
overhead.
This proposal allows delegations to occur on any bit boundary in
the address. This could in theory lead to the problem where a
reverse address has 130 labels (128 bits + 2 for IP6.INT.). In
practice this is impossible as the bottom delegation is in most
cases 64 bits. It is also expected that the high level delegations
will be larger than one bit, somewhere in the range of 4-16 bits,
but at this point in time there is no guarantee that all
delegations will take place on boundaries that are a multiple of 4.
Thus in practice the number of labels in the reverse map is quite
limited.
This proposal encodes each label as a length followed by bit field,
this differs from the previous RFC[RFC1886] in which reverse
address labels were on nibble boundaries.
3. Inverse queries
Inverse queries are performed by looking for DBIT (Delegated BITs)
records in the IP6.INT domain. A DBIT record contains the last bit
in the next delegation and a domain name that prefix is delegated
to. The domain name of the DBIT record encodes the delegation
hierarchy of the IPv6 address.
The DBIT record is specially designed to allow distributed
maintenance of the reverse mapping and to fit well with
DNSSEC[RFC2065]. This draft requires all address allocation
Gudmundsson Expires May 1998 [Page 3]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
authorities and network providers to maintain an accurate
reflection of their delegations in the DBIT records. It is further
assumed that the DBIT records are signed to protect the data
contents[RFC2065].
3.1 DBIT record type
The DBIT resource record type is a new record specific to the
Internet class that stores a single IPv6 address.
The value of the type is TBD (decimal).
3.2 IP6.INT Domain
A special domain is defined to look up a record given an address.
The intent of this domain is to provide a way of mapping an IPv6
address to a host name, although it may be used for other purposes
as well. The domain is rooted at IP6.INT.
3.2.1 Encoding of domain names for DBIT records
Domain names in the IP6.INT. domain encode each label in the
following way:
+-----------------+------------------------------+
| number of bits | bit field padded from left |
| (1 octet) | (variable, 0..128) |
+-----------------+------------------------------+
Thus a full domain name can be expressed as follows:
<bits><bitfield>.<bits><bitfield>*.IP6.INT.
Length of bit field is the smallest number of octets that the
<bits> bits can fit in, the bit field is right justified and padded
from left if necessary with bits set to zero. Suppression of
leading bytes with value of zero, MUST NOT take place.
Each label corresponds to a delegation, each delegation is at least
1 bit. The labels are in the inverse order of delegation. The top
level delegation is closest to the IP6 label and the lowest
delegation is the left most.
Gudmundsson Expires May 1998 [Page 4]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
Domain names in the IP6.INT. domain are BINARY values. (This can
be changed to hex or base64 encoding but at significant cost in
server processing overhead and name size.)
Calculating how many bits have been delegated is done by adding up
the first octet of all but the two right most labels (IP6.INT.).
There is no direct mapping between IPv6 address such as
4321:0:1:2:3:4:567:89ab and an IP6.INT. name. The name depends on
the delegations of address space. Section 3.6.2 describes how to
support "dumb resolvers".
3.3 DBIT rdata format
The data portion of the DBIT record contains two fields:
+------------+---------------------+
| Last bit | Name delegated to |
| (2 octets) | (variable, 1..256) |
+------------+---------------------+
* The last bit in the next delegation. (Counted from the first
bit in an IPv6 address.) Size of this field is set to 2
octets for compatibility reasons with similar records such
as NS and MX.
* the domain name of the authority to which the delegation
size bits has been delegated to, encoded as a domain name.
Name compression is not allowed.
There are two special values that resolvers need to be aware of in
the last bit field. Value of 128 delegates all remaining bits in
the address. Value of 0 indicates that a host name is represented
in the domain name.
DBIT records in the IP6.INT. domain are self checking, so that
records reflect correct delegation sizes. If a resolver has the
whole chain of DBIT records from the IP6.INT. root, this allows the
resolver to perform full verification of the delegations. Similarly
if a resolver gets a random DBIT record it can derive which bits
have been delegated and at which boundaries, from the domain name.
Gudmundsson Expires May 1998 [Page 5]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
When a resolver gets a DBIT record with value 128 it sends the next
DBIT query to a name in the zone defined in the name delegated
field. This is done for the following reasons:
* The same DBIT 0 record can be used for all routing prefixes of
a site and to avoid resigning all DBIT 0 records at a site when
prefixes change.
* EID records at a site are random and do not reflect routing in
any way.
When a resolver gets a DBIT record with the value 0 it has reached
the end. It can now verify all the responses.
In all cases where the value of ``Last bit'' is greater than 0,
there MUST be one and only one DBIT record. When the value of
``Last bit'' is 0 there MAY be multiple DBIT records, each
reflecting different host name for that address.
3.4 DBIT query
A DBIT query for a specified domain name in the Internet class
returns all associated DBIT resource records in the answer section
of a response.
A successful DBIT query MAY contain the NS records for the domain
name in the DBIT record in the additional data section and MAY
contain the address records for these name servers in as well as
the KEY record for the domain name[RFC2065].
3.5 Textual presentation of DBIT records
Textual encoding the binary names on the DBIT records can be
accomplished in hex or base64, or using standard \nnn octet
notation for each byte, this draft uses hex for clarity reasons.
The textual representation of the data portion of the DBIT resource
record used in a master database file is composed of two fields
separated by white space:
* last delegated bit as a decimal number,
* a domain name.
Gudmundsson Expires May 1998 [Page 6]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
3.6 Processing of inverse queries
In the following section the word ``resolver'' is used to denote
both DNS server and a smart DNS resolver that can process multiple
DBIT records and verify that bindings are correct. A DNS resolver
that does not understand or does not want to perform or know about
DBIT processing is called a "dumb resolver".
The DBIT request may result in one of the four following
possibilities:
* an error, either in RCODE or the answer does not contain a
DBIT record.
* the return of a DBIT record with delegation value of 1-127
* the return of a DBIT record with delegation value of 128.
* the return of a DBIT record with delegation value of 0.
In the first case the server is stating that the delegation
requested does not exist. The second case is a valid delegation.
The third case indicates that all remaining bits are delegated to
the next level and the domain name should be queried about the
remaining bits as EID. The fourth is the host name corresponding
to the address.
3.6.1 Smart Resolver query
A DNS server or Smart Resolver will walk the IP6.INT. delegation
tree to find the correct DBIT records. It will start at the top of
the IP6.INT. tree and work its way down the delegation tree.
As an example, a find reverse mapping of the following address
aa2f:34:1::3fff:1234
To find the top delegation in IP6.INT. the server for INT. is
queried for
IP6.INT. DBIT
In this example the numbering authority is delegated 8 bits, thus
the answer is:
IP6.INT. DBIT 8 iana.org.
Gudmundsson Expires May 1998 [Page 7]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
Resolver now encodes the top eight bits of the address into a name
08aa.IP6.INT. and queries the name server for iana.org. The answer
is:
08aa.IP6.INT. DBIT 20 ripe.org.
Now the resolver knows that the next 12 bits (bits 8-19) are
delegated to ripe.org. Next query is sent to the name server for
ripe.org.
0c2f0.08aa.IP6.INT. DBIT 32 isnet.is.example.
and this is followed up with a query for
0c034.0c2f0.08aa.IP6.INT. DBIT 64 ismennt.is.example.
and followed by a query for name
2000010000.0c034.0c2f0.08aa.IP6.INT.
with answer:
2000010000.0c034.0c2f0.08aa.IP6.INT. DBIT 128 \
thorshofn.ismennt.is.example.
As this is a delegation for all the remaining bits the query moved
from the IP6.INT. domain and is issued for 40000000003fff1234. in
the domain pointed to. Now query is issued for
40000000003fff1234.thorshofn.isment.is.example.
with answer:
40000000003fff1234.thorshofn.isment.is.example. DBIT 0 \
sia.thorshofn.ismennt.is.example.
3.6.2 Dumb resolver query
Resolver that that does not want to process DBIT query issues a
query for 80aa2f003400010000000000003fff1234.IP6.INT.
DNS Server that gets this in a query MUST know to break it down
into components as defined in previous section. The DNS server
returns back to the resolver an answer that is synthesized from the
responses it got in the answer section.
The server MUST return the relevant DBIT records and their
signatures in the additional data section.
Gudmundsson Expires May 1998 [Page 8]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
In the above example DBIT aware server would have returned in the
answer section
80aa2f003400010000000000003fff1234.IP6.INT. DBIT 0 \
sia.thorshofn.ismennt.is.example.
The answer SHOULD have contained in the additional data section the
DBIT records used to derive this answer from, along with their
signatures. In the example above the answer would have looked like
IP6.INT. DBIT 8 iana.org.
08aa.IP6.INT. DBIT 20 ripe.org.
0c2f0.08aa.IP6.INT. DBIT 32 isnet.is.example.
0c034.0c2f0.08aa.IP6.INT. DBIT 64 ismennt.is.example.
2000010000.0c034.0c2f0.08aa.IP6.INT. DBIT 128 \
thorshofn.ismennt.is.example.
40000000003fff1234.thorshofn.isment.is.example. DBIT 0 \
sia.thorshofn.ismennt.is.example.
If a DNS server receiving a dumb DBIT query is authoritative for
part of the delegation or if it has DBIT records in its cache that
provide prefix match it MAY start from the longest correct prefix
DBIT record. For example if the above dumb query has been asked of
ripe.org. or someone that had the 0c02f3.08aa.IP6.INT. DBIT record.
In any case the resolver expects to get the 80..... DBIT 0 record
back.
4. Security Considerations
This proposal does not address security per se. Correct verifiable
operation of this model assumes that DNSSEC will be used in the
IP6.INT. tree and the leaf notes. If DNSSEC is not used, it is
possible to get verifiable answers if secure transmission channels
are used to ALL authoritative name servers queried and no data is
retrieved from untrusted caching servers. In the absence of those
two secured communication mechanisms DNS data can be spoofed.
5. Acknowledgments
Many of the ideas here were developed during a discussion between
the author, Jim Bound, and Bill Manning. Further evolution of the
idea has been taken place in conversations with Robert Elz,
Christian Huitema, Susan Thompson, and Karen Tracy.
Gudmundsson Expires May 1998 [Page 9]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997
6. References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation
and Specification,'' RFC 1034, ISI, November
1987.
[RFC1886] S. Thomson, Huitema, ``DNS Extensions to support
IP version 6,'' RFC 1886, Bellcore, December
1995.
[RFC2065] D. Eastlake , C Kaufman, ``Domain Name System
Security Extensions,'' RFC 2065, CyberCash &
Iris, January 1997.
[RFC2119] S. Bradner, ``Key words for use in RFCs to Indi-
cate Requirement Level,'' RFC 2119, Harvard,
March 1997.
[RFC2137] D. Eastlake 3rd, ``Secure Domain Name System
Dynamic Update,'' CyberCash, April 1997.
[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS
Specification.'', RFC 2181, Univeristy of Mel-
borne, RGnet, July 1997.
[HD97] R. Hinden, S. Deering, ``IP Version 6 Addressing
Architecture'', Internet Draft, draft-ietf-
ipngwg-addr-arch-v2-05.txt, Ipsilon, Cisco.
[HT97] C. Huitema, S. Thomson, ``DNS Extensions to sup-
port IP version 6'', Internet Draft, draft-ietf-
ipngwg-aaaa-00.txt, Bellcore.
7. Authors Address
Olafur Gudmundsson
Trusted Information Systems
3060 Washington Road, MD 21738
(301) 854-5700 (301)-854-5363 FAX.
ogud@tis.com.
Gudmundsson Expires May 1998 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 06:23:06 |