[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 2874

IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                          March 13, 1998

                    DNS Lookups Keyed on IPv6 Addresses
                   <draft-ietf-ipngwg-dns-lookups-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 ftp.is.co.za (Africa), ftp.nordu.net (North
    Europe), ftp.nis.garr.it (South Europe), ds.internic.net (US East
    Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

    Distribution of this memo is unlimited.


1.  Abstract

    This document defines a new structure for the zones which support
    DNS lookups keyed on IPV6 addresses.  (Often called reverse
    lookups.)  It allows address space to be delegated on arbitrary
    bit-boundaries.  The delegation information can be be usefully
    cached.  A zone describing delegated space can be used for multiple
    parallel copies of that address space, as for a dual-homed provider
    or site, and need not be modified if the space is renumbered at a
    higher level.

    The new structure can coexist with the old tree under the same name,
    IP6.INT.








Expires September 18, 1998      Crawford                        [Page 1]


Internet Draft                  IPv6 DNS                  March 13, 1998


2.  Background

    To fulfill the grand claims made in the abstract, this document
    relies on new DNS features described in Internet-Drafts designated
    [BITLBL], [DNAME], and [EDNS].  This first draft is a working
    document intended only to sketch the new structure with the
    intention of convincing the reader that the above claims are
    realistic.


3.  Underlying Mechanisms

    This section describes the new proposed new DNS features which this
    document exploits.  The reader is directed to the referenced drafts
    for more details on each.


3.1.  Delegation on Arbitrary Boundaries

    This new scheme for reverse lookups relies on a new type of DNS
    label called the "bit-string label" [BITLBL].  This label compactly
    represents an arbitrary string of bits which is treated as a
    hierarchical sequence of one-bit domain labels.  Resource records
    can be stored on arbitrary bit-boundaries and bit-string label
    processing is subject to a longest-match rule which will return
    records from the nearest ancestor node which has them if the
    requested information cannot be found at the queried name itself.

    Examples in section 4 will employ the following textual format for
    bit-string labels.  A base indicator, either "b" for binary or "x"
    for hexadecimal, and sequence of digits in the indicated base is
    enclosed between "\[x" and "]".  The bits denoted by the digits
    represent a sequence of one-bit domain labels ordered from most to
    least significant.  (This is the opposite of the order they would
    appear if listed one bit at a time, but it appears to be a
    convenient notation.)  The digit string may be followed by a slash
    ("/") and a decimal count.  If omitted, the implicit count is equal
    to the number of binary digits or four times the number of
    hexadecimal digits.

    Consecutive bit-string labels are equivalent (up to the limit
    imposed by the size of the bit count field) to a single bit-string
    label containing all the bits of the consecutive labels in the
    proper order.  As an example, either of the following domain names
    could be used in a QCLASS=IN, QTYPE=PTR query to find the name of






Expires September 18, 1998      Crawford                        [Page 2]


Internet Draft                  IPv6 DNS                  March 13, 1998


    the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.

         \[x3FFE07C0004000090A0020FFFE812B32/128].ip6.int.

         \[x0A0020FFFE812B32/64].\[x0009/16].
                    \[x07C00040/32].\[xFFF0/13].\[b001/3].ip6.int.

    None of the bit counts in the either form are required except the
    "/13".  Note that bits are left-justified in a hexadecimal string.


3.2.  Reusable Zones

    DNS address space delegation is implemented not by zone cuts and NS
    records, but by a new analogue to the CNAME record, called the DNAME
    record [DNAME].  The DNAME record provides alternate naming to an
    entire subtree of the domain name space, rather than to a single
    node.  It causes some suffix of a queried name to be substituted
    with a name from the DNAME record's RDATA.

    For example, a resolver or server providing recursion, while looking
    up a QNAME a.b.c.d.e.tld may encounter a DNAME record

                        d.e.tld.     DNAME     w.xy.

    which will cause it to look for a.b.c.w.xy.


3.3.  Coexistence

    All data supporting the new reverse lookup scheme will be stored at
    DNS nodes whose names include at least one bit-string label.  By
    issuing a query for such a name, a resolver indicates that it
    understands the new label type [EDNS].  Alternatively, a resolver
    can indicate its compliance with EDNS features by inclusion of a new
    OPT RR in a query.


4.  Zone Structure

    Very little of the new scheme's data actually appears under IP6.INT.
    Only the first level of delegation needs to be under that (or
    another fixed and well-known) domain, although more levels of
    delegation could be done under IP6.INT if some top-level delegations
    were done via NS records instead of DNAME records.  This would incur
    a possibly-negligible cost in loss of renumbering ease at the level
    of TLAs [AARCH].  The examples which follow assume that delegations
    by NS records are not done.



Expires September 18, 1998      Crawford                        [Page 3]


Internet Draft                  IPv6 DNS                  March 13, 1998


4.1.  The Top Level

    Supposing that address space assignments in the TLAs with Format
    Prefix (001) binary and IDs 1, 2 and 3 were maintained in zones
    called alpha-registry.tld, bravo.tla.nil and charlie-net.xy, the
    IP6.INT zone would include

                $ORIGIN IP6.INT.
                \[x200100/24]   DNAME   alpha-registry.tld.
                \[x200200/24]   DNAME   bravo.tla.nil.
                \[x200300/24]   DNAME   charlie-net.xy.

    Eight trailing zero bits have been included in each TLA ID to
    reflect the eight reserved bits in the current aggregatable global
    unicast addresses format [AARCH].


4.2.  The TLA level

    Now suppose that Alpha-Registry has assigned the prefixes
    2001:0:4000::0/34, 2001:1:200::0/39 and 2001:2:20::0/43 to a large
    ISP, a medium-sized ISP, and a corporation with a network linking 25
    sites. Its zone could record these assignments as

     $ORIGIN alpha-registry.tld.
     @               TXT     "This domain delegates from a /24 prefix"
     \[x004/10]      DNAME   ip6-addr.big-isp.example.
     \[x0102/15]     DNAME   nla-space.med-isp.example.
     \[x02002/19]    DNAME   site-register.world-wide-widgets.tld.



4.3.  The ISP level

    The medium-sized ISP of the previous section might list a lower-
    level ISP and two customer sites in its zone as follows.

     $ORIGIN nla-space.med-isp.example.
     @               TXT     "This domain delegates from a /39 prefix"
     \[b001/3]       DNAME   customers.small-isp.example.
     \[x800/9]       DNAME   reverse-zone.example.com.
     \[x808/9]       DNAME   sla.example.org.

    The last-listed customer site might be dual-homed to Big-ISP, who
    delegates it another global prefix.






Expires September 18, 1998      Crawford                        [Page 4]


Internet Draft                  IPv6 DNS                  March 13, 1998



     $ORIGIN ip6-addr.big-isp.example.
     @               TXT     "This domain delegates from a /34 prefix"
     \[x1234/14]     DNAME   sla.example.org.

    Note the same domain name in this DNAME record.  The customer will
    use the same zone to map both global prefixes.


4.4.  The Site Level

    Consider the customer Example.Org using sla.example.org for
    address-to-name translations.  This domain is now referenced by two
    different DNAME records held by two different providers.

            $ORIGIN \[x0001/16].sla.example.org.   ; subnet 1
            \[x020855FFFE012345]    PTR     www.example.org.
            \[x020855FFFE345678]    PTR     ns1.example.org.
            $ORIGIN \[x0001/16].sla.example.org.   ; subnet 2
            \[x020855FFFE67890A]    PTR     mailhub.example.org.



5.  Lookups

    A DNS resolver looking for a hostname for the address
    2001:1:301:1:208:55ff:fe01:2345 would acquire certain of the DNAME
    records shown above and would form new queries.  Assuming that it
    began the process knowing servers for IP6.INT, but that no server it
    consulted provided recursion and none had other useful additional
    information cached, the sequence of queried names and responses
    would be:



















Expires September 18, 1998      Crawford                        [Page 5]


Internet Draft                  IPv6 DNS                  March 13, 1998



    To a server for ip6.int:
    QTYPE=PTR QNAME=\[x2001000103010001020855fffe012345/128].ip6.int.

            Answer:
            \[x200100/24].ip6.int. DNAME alpha-registry.tld.

    To a server for alpha-registry.tld:
    QTYPE=PTR QNAME=\[x0103010001020855fffe012345/104].alpha-registry.tld.

            Answer:
            \[x0102/15].alpha-registry.tld. DNAME nla-space.med-isp.example.

    To a server for nla-space.med-isp.example:
    QTYPE=PTR QNAME=\[x80800081042affff0091a28/89].
                                        nla-space.med-isp.example.

            Answer:
            \[x808/9].nla-space.med-isp.example. DNAME sla.example.org.

    To a server for sla.example.org:
    QTYPE=PTR QNAME=\[x0001020855fffe012345].sla.example.org.

            Answer:
            \[x0001020855fffe012345].sla.example.org. PTR www.example.org.

    All the DNAME (and NS) records acquired along the way can be cached
    to expedite resolution of addresses topologically near to this
    address.  And if the other global address of www.example.org were
    resolved within the TTL of the final PTR record, that record would
    not have to be fetched again.


6.  Uniformity

    The examples above assume that organizations conspicuously fail to
    employ any sort of uniform naming convention for the part of their
    DNS space in which they record address delegations and assignments.
    Registries, network providers and sites might benefit from such a
    convention.


7.  Security Considerations

    DNS Security [DNSSEC] is fully applicable to bit-string labels and
    DNAME records.  However, authentication of data in the reverse zones
    is not equivalent to authentication of any "forward" data, such as
    AAAA records.



Expires September 18, 1998      Crawford                        [Page 6]


Internet Draft                  IPv6 DNS                  March 13, 1998


8.  References


    [AARCH]  R. Hinden, S. Deering, "IP Version 6 Addressing
             Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
             06.txt.

    [BITLBL] M. Crawford, "Binary Labels in the Domain Name System",
             currently draft-ietf-dnsind-binary-labels-01.txt.

    [DNAME]  M. Crawford, "Non-Terminal DNS Name Redirection", currently
             draft-ietf-dnsind-dname-00.txt.

    [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
             Extensions", RFC 2065.

    [EDNS]   P. Vixie, "Extensions to DNS (EDNS)" currently draft-ietf-
             dnsind-edns-01.txt.


9.  Author's Address

    Matt Crawford
    Fermilab MS 368
    PO Box 500
    Batavia, IL 60510
    USA

    Phone: +1 630 840-3461

    EMail: crawdad@fnal.gov




















Expires September 18, 1998      Crawford                        [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/