draft-ietf-ipngwg-dns-lookups-08.txt

bind-3.2.

    Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
    name translations.  This domain is now referenced by two different
    DNAME records held by two different providers.

            $ORIGIN IP6.X.EXAMPLE.
            \[x0001/16]                    DNAME   SUBNET-1
            \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
            and so on.

    SUBNET-1 need not have been named in a DNAME record; the subnet bits
    could have been joined with the interface identifier.  But if
    subnets are treated alike in both the A6 records and in the reverse
    zone, it will always be possible to keep the forward and reverse
    definition data for each prefix in one zone.


6.3.  Lookups

    A DNS resolver looking for a hostname for the address
    2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
    DNAME records shown above and would form new queries.  Assuming that
    it began the process knowing servers for IP6.ARPA, 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 (all with QCLASS=IN, QTYPE=PTR):








Expires November 22, 2000   Crawford et al.                    [Page 14]

Internet Draft                  IPv6 DNS                    May 17, 2000



    To a server for IP6.ARPA:
    QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.

         Answer:
         \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.

    To a server for IP6.ALPHA-TLA.ORG:
    QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.

         Answer:
         \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.

    To a server for IP6.C.NET.:
    QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.

         Answer:
         \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.

    To a server for IP6.A.NET.:
    QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.

         Answer:
         \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.

    To a server for IP6.X.EXAMPLE.:
    QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.

         Answer:
         \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
         \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.

    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 another global address of N.X.EXAMPLE were resolved
    within the TTL of the final PTR record, that record would not have
    to be fetched again.


6.4.  Operational Note

    In the illustrations in section 6.1, hierarchically adjacent
    entities, such as a network provider and a customer, must agree on a
    DNS name which will own the definition of the delegated prefix(es).
    One simple convention would be to use a bit-string label
    representing exactly the bits which are assigned to the lower-level
    entity by the higher.  For example, "SUBSCRIBER-X" could be replaced
    by "\[x11/8]".  This would place the A6 record(s) defining the



Expires November 22, 2000   Crawford et al.                    [Page 15]

Internet Draft                  IPv6 DNS                    May 17, 2000


    delegated prefix at exactly the same point in the DNS tree as the
    DNAME record associated with that delegation.  The cost of this
    simplification is that the lower-level zone must update its upward-
    pointing A6 records when it is renumbered.  This cost may be found
    quite acceptable in practice.


7.  Transition from RFC 1886 and Deployment Notes

    When prefixes have been "delegated upward" with A6 records, the
    number of DNS resource records required to establish a single IPv6
    address increases by some non-trivial factor.  Those records will
    typically, but not necessarily, come from different DNS zones (which
    can independently suffer failures for all the usual reasons).  When
    obtaining multiple IPv6 addresses together, this increase in RR
    count will be proportionally less -- and the total size of a DNS
    reply might even decrease -- if the addresses are topologically
    clustered.  But the records could still easily exceed the space
    available in a UDP response which returns a large RRset [DNSCLAR] to
    an MX, NS, or SRV query, for example.  The possibilities for overall
    degradation of performance and reliability of DNS lookups are
    numerous, and increase with the number of prefix delegations
    involved, especially when those delegations point to records in
    other zones.

    DNS Security [DNSSEC] addresses the trustworthiness of cached data,
    which is a problem intrinsic to DNS, but the cost of applying this
    to an IPv6 address is multiplied by a factor which may be greater
    than the number of prefix delegations involved if different
    signature chains must be verified for different A6 records.  If a
    trusted centralized caching server (as in [TSIG], for example) is
    used, this cost might be amortized to acceptable levels.  One new
    phenomenon is the possibility that IPv6 addresses may be formed from
    a A6 records from a combination of secure and unsecured zones.

    Until more deployment experience is gained with the A6 record, it is
    recommended that prefix delegations be limited to one or two levels.
    A reasonable phasing-in mechanism would be to start with no prefix
    delegations (all A6 records having prefix length 0) and then to move
    to the use of a single level of delegation within a single zone.
    (If the TTL of the "prefix" A6 records is kept to an appropriate
    duration the capability for rapid renumbering is not lost.)  More
    aggressively flexible delegation could be introduced for a subset of
    hosts for experimentation.







Expires November 22, 2000   Crawford et al.                    [Page 16]

Internet Draft                  IPv6 DNS                    May 17, 2000


7.1.  Transition from AAAA and Coexistence with A Records

    Administrators of zones which contain A6 records can easily
    accommodate deployed resolvers which understand AAAA records but not
    A6 records.  Such administrators can do automatic generation of AAAA
    records for all of a zone's names which own A6 records by a process
    which mimics the resolution of a hostname to an IPv6 address (see
    section 4.1.4).  Attention must be paid to the TTL assigned to a
    generated AAAA record, which MUST be no more than the minimum of the
    TTLs of the A6 records that were used to form the IPv6 address in
    that record.  For full robustness, those A6 records which were in
    different zones should be monitored for changes (in TTL or RDATA)
    even when there are no changes to zone for which AAAA records are
    being generated.  If the zone is secure [DNSSEC], the generated AAAA
    records MUST be signed along with the rest of the zone data.

    A zone-specific heuristic MAY be used to avoid generation of AAAA
    records for A6 records which record prefixes, although such
    superfluous records would be relatively few in number and harmless.
    Examples of such heuristics include omitting A6 records with a
    prefix length less than the largest value found in the zone file, or
    records with an address suffix field with a certain number of
    trailing zero bits.

    On the client side, when looking up and IPv6 address, the order of
    A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA;
    AAAA, then A6; A6 only; or both in parallel.  The default order (or
    only order, if not configurable) MUST be to try A6 first, then AAAA.
    If and when the AAAA becomes deprecated a new document will change
    the default.

    The guidelines and options for precedence between IPv4 and IPv6
    addresses are specified in [TRANS].  All mentions of AAAA records in
    that document are henceforth to be interpreted as meaning A6 and/or
    AAAA records in the order specified in the previous paragraph.


7.2.  Transition from Nibble Labels to Binary Labels

    Implementations conforming to RFC 1886 perform reverse lookups as
    follows:

        An IPv6 address is represented as a name in the IP6.INT domain
        by a sequence of nibbles separated by dots with the suffix
        ".IP6.INT". The sequence of nibbles is encoded in reverse order,
        i.e. the low-order nibble is encoded first, followed by the next
        low-order nibble and so on. Each nibble is represented by a
        hexadecimal digit. For example, a name for the address



Expires November 22, 2000   Crawford et al.                    [Page 17]

Internet Draft                  IPv6 DNS                    May 17, 2000


        2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in
        section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
        8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."

    Implementations conforming to this specification will perform a
    lookup of a binary label in IP6.ARPA as specified in Section 3.2.
    It is RECOMMENDED that for a transition period implementations first
    lookup the binary label in IP6.ARPA and if this fails try to lookup
    the 'nibble' label in IP6.INT.


8.  Security Considerations

    The signing authority [DNSSEC] for the A6 records which determine an
    IPv6 address is distributed among several entities, reflecting the
    delegation path of the address space which that address occupies.
    DNS Security is fully applicable to bit-string labels and DNAME
    records.  And just as in IPv4, verification of name-to-address
    mappings is logically independent of verification of address-to-name
    mappings.

    With or without DNSSEC, the incomplete but non-empty address set
    scenario of section 4.1.4 could be caused by selective interference
    with DNS lookups.  If in some situation this would be more harmful
    than complete DNS failure, it might be mitigated on the client side
    by refusing to act on an incomplete set, or on the server side by
    listing all addresses in A6 records with prefix length 0.


9.  IANA Considerations

    The A6 resource record has been assigned a Type value of 38.


10.  Acknowledgments

    The authors would like to thank the following persons for valuable
    discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound,
    Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis
    Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob
    Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
    Nordmark, Mike O'Dell, Michael Patton and Ken Powell.









Expires November 22, 2000   Crawford et al.                    [Page 18]

Internet Draft                  IPv6 DNS                    May 17, 2000


11.  References


    [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

    [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
        Global Unicast Address Format".  RFC 2374, July 1998.

    [BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
        RFC 2673, August 1999.

    [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
        August 1999.

    [DNSCLAR] Elz, R and R. Bush, "Clarifications to the DNS
        Specification", RFC 2181, July 1997.

    [DNSIS] Mockapetris, P. V., "Domain names - implementation and
        specification", RFC 1035, November 1987.

    [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
        Security Extensions", RFC 2535, March 1999.

    [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels," RFC 2119.

    [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
        1900, February 1996.

        Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
        Why would I want it and what is it anyway?", RFC 2071, January
        1997.

        Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
        Behaviour Today", RFC 2101, February 1997.

    [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
        IPv6 Hosts and Routers", RFC 1933, April 1996.

    [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
        Wellington, "Secret Key Transaction Authentication for DNS









Expires November 22, 2000   Crawford et al.                    [Page 19]

Internet Draft                  IPv6 DNS                    May 17, 2000


        (TSIG)", work in progress.

12.  Authors' Addresses

    Matt Crawford          Christian Huitema      Susan Thomson
    Fermilab               Telcordia              Telcordia
    MS 368                 MCC 1J236B             MCC 1C259B
    PO Box 500             445 South Street       445 South Street
    Batavia, IL 60510      Morristown, NJ 07960   Morristown, NJ 07960
    USA                    USA                    USA

    [phone]        [phone]        [phone]
    [e-mail]       [e-mail]
                                                  [e-mail]





































Expires November 22, 2000   Crawford et al.                    [Page 20]