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

Versions: 00 01 02 03 RFC 2672

DNSIND Working Group                                       Matt Crawford
Internet Draft                                                  Fermilab
                                                           March 6, 1998

                     Non-Terminal DNS Name Redirection

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

    Distribution of this memo is unlimited.

1.  Introduction

    This document defines a new DNS Resource Record called ``DNAME'',
    which provides the capability to map an entire subtree of the DNS
    name space to another domain.  It differs from the CNAME record
    which maps a single node of the name space.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in [KWORD].

2.  Motivation

    This Resource Record and its processing rules were conceived as a
    solution to the problem of maintaining address-to-name mappings in a
    context of network renumbering.  Without the DNAME mechanism, an
    authoritative DNS server for the address-to-name mappings of some

Expires September 11, 1998      Crawford                        [Page 1]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

    network must be reconfigured when that network is renumbered.  With
    DNAME, the zone can be constructed so that it needs no modification
    when renumbered.  DNAME can also be useful in other situations, such
    as when an organizational unit is renamed.

3.  The DNAME Resource Record

    The DNAME RR has mnemonic DNAME and type code TBA (decimal).

    DNAME has the following format:

       <owner> <ttl> <class> DNAME <target>

    The format is not class-sensitive.  All fields are required.  The
    RDATA field <target> is a <domain-name> [DNSIS].

    The DNAME RR causes type NS additional section processing.

    The effect of the DNAME record is the substitution of the record's
    <target> for its <owner> as a suffix of a domain name.  Two limiting
    rules govern the use of DNAMEs.

    Rule One
      If a DNAME RR is present at a node N, there may be other data at N
      (except a CNAME or another DNAME), but there MUST be no data at
      any descendant of N, except for the wildcard node *.N which MAY
      have data intended to help old DNS clients which do not understand
      the DNAME record.  These restrictions apply only to records of the
      same class as the DNAME record.

    Rule Two
      When resolving a query, it is valid to encounter more than one
      DNAME record along the way ONLY IF every DNAME record encountered
      has fewer labels in its <target> than in its <owner>.  (Note that
      in the bit-string label [BITLBL], each bit is a separate label.)
      If a single DNAME is encountered there is no special restriction
      on the number of labels in its <target>.

    Rule One assures predictable results when a DNAME record is cached
    by a server which is not authoritative for the record's zone.  Rule
    Two prevents DNAME loops.

    Rule One MUST be enforced when authoritative zone data is loaded.
    Rule Two MUST be enforced during query processing.

Expires September 11, 1998      Crawford                        [Page 2]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

4.  Query Processing

    To exploit the DNAME mechanism the name resolution algorithms
    [DNSCF] must be modified slightly for both servers and resolvers.
    In both cases a conceptual per-query variable DFLAG is introduced to
    enforce Rule Two.  Implementations MAY use other means to enforce
    the rule.  DFLAG DFLAG's value is

    0   when processing of a query begins and whenever no DNAME has been

    1   when one or more DNAME records have been encountered, and each
        had fewer labels in its <target> than in its <owner>;

    2   when a DNAME record has been encountered which had at least as
        many labels in its <target> as in its <owner>.

    Both modified algorithms incorporate the operation of making a
    substitution on a name (either QNAME or SNAME) under control of a
    DNAME record.  For conciseness, this operation is elaborated here
    and will be referred to as "procedure S".

    S1. If DFLAG = 2, Rule Two is violated.  Go to step S4.

    S2. If DFLAG = 1 and the DNAME record's <target>'s does not have
        fewer labels than its <owner>, Rule Two is violated.  Go to step

    S3. If substituting the DNAME's <target> for its <owner> in the name
        being operated on would overflow the legal size for a <domain-
        name>, go to step S4.  Otherwise make the substitution.

        If the <target> has fewer labels than the <owner>, set DFLAG to
        1, otherwise set DFLAG to 2.  Return.

    S4. In a resolver, return an implementation-dependent error to the
        application.  In a server, copy the DNAME record to the answer
        section, set RCODE to YXDOMAIN [DNSUPD], and exit.

4.1.  Processing by Servers

    For a server performing non-recursive service steps 3.c and 4 of
    section 4.3.2 [DNSCF] are changed to check for a DNAME record before
    checking for a wildcard ("*") label, and to return certain DNAME
    records from the cache.  The revised algorithm is:

    1.  Set or clear the value of recursion available in the response

Expires September 11, 1998      Crawford                        [Page 3]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

        depending on whether the name server is willing to provide
        recursive service.  If recursive service is available and
        requested via the RD bit in the query, go to step 5, otherwise
        step 2.

    2.  Search the available zones for the zone which is the nearest
        ancestor to QNAME.  If such a zone is found, go to step 3,
        otherwise step 4.

    3.  Start matching down, label by label, in the zone.  The matching
        process can terminate several ways:

        a.  If the whole of QNAME is matched, we have found the node.

            If the data at the node is a CNAME, and QTYPE doesn't match
            CNAME, copy the CNAME RR into the answer section of the
            response, change QNAME to the canonical name in the CNAME
            RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the answer
            section and go to step 6.

        b.  If a match would take us out of the authoritative data, we
            have a referral.  This happens when we encounter a node with
            NS RRs marking cuts along the bottom of a zone.

            Copy the NS RRs for the subzone into the authority section
            of the reply.  Put whatever addresses are available into the
            additional section, using glue RRs if the addresses are not
            available from authoritative data or the cache.  Go to step

        c.  If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see whether the  |
            last label matched has a DNAME record.                        |

            If a DNAME record exists at that point, copy that record      |
            into the answer section, substitute its <target> for its      |
            <owner> in QNAME according to procedure S, and go back to     |
            step 1.                                                       |

            If there was no DNAME record, look to see if the "*" label    |

            If the "*" label does not exist, check whether the name we
            are looking for is the original QNAME in the query or a name
            we have followed due to a CNAME.  If the name is original,
            set an authoritative name error in the response and exit.

Expires September 11, 1998      Crawford                        [Page 4]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

            Otherwise just exit.

            If the "*" label does exist, match RRs at that node against
            QTYPE.  If any match, copy them into the answer section, but
            set the owner of the RR to be QNAME, and not the node with
            the "*" label.  Go to step 6.

    4.  Start matching down in the cache.  If QNAME is found in the
        cache, copy all RRs attached to it that match QTYPE into the
        answer section.  If QNAME is not found in the cache but a DNAME   |
        record is present at an ancestor of QNAME, copy that DNAME        |
        record into the answer section.  If there was no delegation from  |
        authoritative data, look for the best one from the cache, and
        put it in the authority section.  Go to step 6.

    5.  Using the local resolver or a copy of its algorithm (see
        resolver section of this memo) to answer the query.  Store the
        results, including any intermediate CNAMEs and DNAMEs, in the     |
        answer section of the response.

    6.  Using local data only, attempt to add other RRs which may be
        useful to the additional section of the query.  Exit.

    Note that there will be at most one ancestor with a DNAME as
    described in step 4 unless some zone's data is in violation of Rule

4.2.  Processing by Resolvers

    A resolver or a server providing recursive service must be modified
    to treat a DNAME as somewhat analogous to a CNAME.  The resolver
    algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
    as 4.e and insert a new 4.d.  The complete algorithm becomes:

    1.  See if the answer is in local information, and if so return it
        to the client.

    2.  Find the best servers to ask.

    3.  Send them queries until one returns a response.

    4.  Analyze the response, either:

        a.  if the response answers the question or contains a name
            error, cache the data as well as returning it back to the

Expires September 11, 1998      Crawford                        [Page 5]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

        b.  if the response contains a better delegation to other
            servers, cache the delegation information, and go to step 2.

        c.  if the response shows a CNAME and that is not the answer
            itself, cache the CNAME, change the SNAME to the canonical
            name in the CNAME RR and go to step 1.

        d.  if the response shows a DNAME the DNAME, substitute the       |
            DNAME's <target> for its <owner> in the SNAME according to    |
            procedure S and go to step 1.                                 |

        e.  if the response shows a server failure or other bizarre       |
            contents, delete the server from the SLIST and go back to
            step 3.

5.  Examples of Use

    If an organization with domain name FROBOZZ.TLD became part of an
    organization with domain name ACME.TLD, it might ease transition by
    placing information such as this in its old zone.

            frobozz.tld.      DNAME    frobozz-division.acme.tld.
                              MX       mailhub.acme.tld.
            *.frobozz.tld.    CNAME    www.frobozz-division.acme.tld.

    If IPv4 network renumbering were common, maintenance of address
    space delegation could be simplified by using DNAME records instead
    of NS records to delegate.

            $ORIGIN new-style.in-addr.arpa.
            189.190           DNAME    in-addr.example.net.

            $ORIGIN in-addr.example.net.
            188               DNAME    in-addr.customer.xy.

            $ORIGIN in-addr.customer.xy.
            1                 PTR      www.customer.xy.
            2                 PTR      mailhub.customer.xy.
            ; etc ...

    This would allow the address space assigned to the ISP "example.net"
    to be changed without the necessity of altering the zone files
    describing the use of that space by the ISP and its customers.

Expires September 11, 1998      Crawford                        [Page 6]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

6.  Discussion (in draft only)

    Why does [DNSCF] section 4.3.2 step 3.a say "go back to step 1"
    rather than "go back to step 2"?

    Would a DNAME with a special <target> be of any use in securely
    denying anything in a subtree below its <owner>?  If so, a special
    rule could be added about a null label in the <target>, or

    The meaning of NS and DNAME records together at the same node is
    unclear.  Perhaps this ought to be forbidden.

    YXDOMAIN seems like a reasonable error code to overload for name-
    length overflow due to DNAME substitution.  But a case for NXDOMAIN
    could be made on the grounds that the resulting too-long name is
    sure not to exist.

    Rule Two could be modified to allow up to one (or any fixed finite
    number) of DNAMEs which don't decrease the label count AND any
    number of DNAMEs which do decrease it.  Would that help anything?

7.  Acknowledgments

    Donald Eastlake 3rd suggested the wildcard subdomain to help old
    clients get something useful.

8.  References

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

    [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
            RFC 1034.

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

    [DNSUPD]P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
            Updates in the Domain Name System", RFC 2136.

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

Expires September 11, 1998      Crawford                        [Page 7]

Internet Draft           Non-Terminal Nicknames            March 6, 1998

9.  Author's Address

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

    Phone: +1 630 840-3461

    EMail: crawdad@fnal.gov

Expires September 11, 1998      Crawford                        [Page 8]

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