<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
        <!ENTITY RFC1035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
        <!ENTITY RFC1535 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1535.xml">
        <!ENTITY RFC1536 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1536.xml">
        <!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <!ENTITY RFC2131 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
        <!ENTITY RFC2132 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml">
        <!ENTITY RFC3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
        <!ENTITY RFC3396 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml">
        <!ENTITY RFC3397 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml">
        <!ENTITY RFC3646 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml">
        <!ENTITY RFC4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
        <!ENTITY RFC4034 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
        <!ENTITY RFC4035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
        <!ENTITY RFC4704 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704.xml">
        <!ENTITY I-D.ietf-dane-ops PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-ops.xml">
        ]>

<rfc category="std"
     docName="draft-mglt-dnsop-search-list-processing-00.txt"
     ipr="trust200902">
    <front>
        <title abbrev="DNS Search List Processing">DNS Search List Processing</title>
        <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
            <organization>Orange</organization>
            <address>
                <postal>
                    <street>38 rue du General Leclerc</street>
                    <city>92794 Issy-les-Moulineaux Cedex 9</city>
                    <country>France</country>
                </postal>
                <phone>+33 1 45 29 60 52</phone>
                <facsimile/>
                <email>daniel.migault@orange.com</email>
                <uri/>
            </address>
        </author>

        <date/>
        <area>INTERNET</area>

        <workgroup>DNSOP</workgroup>

        <abstract>
        <t>Domain Names can be Qualified or Unqualified Domain Names. Qualified Domain Names are resolved over the public DNS infrastructure, whereas Unqualified Domain Names are resolved using search lists. How search lists are generated and interpreted varies from one application to another and from one operating system to another. This makes Unqualified Domain Name resolution unpredictable, non deterministic, and as such neither reliable nor stable. </t>

        <t>In addition, there is neither clear rules to define whether a name is a Qualified or an Unqualified Domain Name. This also contributes in making the naming resolution unreliable, as the resolution of a given name can result in different responses.</t>

        <t>As a consequence, most resolution systems currently end with a "try and error" strategy. More specifically, according to some system dependent heuristics, a resolver initiates an Unqualified (resp. Qualified) Domain Name resolution, and, in case of a NXDOMAIN response, fails back in a Qualified (resp. Unqualified) Domain Name resolution. Such strategies were acceptable as the probability of collision between domains within search list and those published in the public DNS infrastructure remains low. In the context of the generalization of Top Level Domain, this assumption is not acceptable anymore, resulting in an unreliable and unstable naming resolution.</t> 

        <t>This document describes how search list should be generated and interpreted. Then, it describes how resolvers distinguish between Qualified and Unqualified Domain Names as well as how to resolve them.</t>   
        </abstract>
    </front>

    <middle>

        <section title="Requirements notation">
            <t>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 <xref target="RFC2119"/>.
            </t>
        </section>
        <section title="Introduction">

        <section title="Qualified and Unqualified Domain Names">

        <t>Until recently, the root zone had only a restricted number of well known Top-Level Domain (TLDs). These TLDs had a specific format of a few letters (generally two or three), and had remained almost unchanged for a long time. Simultaneously, end users and applications used for convenience Unqualified Domain Names for local scope resolutions. More specifically, suppose "host1.example" wants to establish a communication with "foo.example". As both host belong to the same Domain "example", simply specifying "foo" should be sufficient. The mechanism to auto-complete "foo" with "foo.example" is performed using search list mechanisms. In most cases, the use of Unqualified Domain Names was used in a local scope context, that is to say, when "example" was used for convenience, but not registered in the public DNS infrastructure.</t>

        <t>As a result, there are two ways to express the names of the nodes within a Domain: A Fully Qualified Domain Name ("host2.example") and an Unqualified Domain Name ("host2"). Each of these names requires a different resolving mechanisms. Fully Qualified Domain Names (FQDN) are resolved on the public DNS infrastructure and Unqualified Domain Names are resolved using search lists.</t>

        <t>As there are different ways to express a name, a resolver may assume the name is a Qualified (resp. Unqualified) Domain Name when in fact the name is an Unqualified (resp. Qualified) Domain Name. In our example, this would lead to a resolution of "foo." over the public DNS infrastructure. If "foo" is being registered in the root zone, then "foo.example." and "foo." will most likely not provide the same responses. The confusion between Unqualified and Qualified Domain Names makes naming resolution unstable and unreliable.</t>

        <t>To indicate a name is a Fully Qualified Domain Name, one should end it with a dot, however, this has never been accurately be used, and the last dot is most of the time omitted. As a result it has always been confusing to distinguish between Qualified Domain Names and Fully Qualified Domain Names. </t>
        </section>

        <section title="Domain Names Collision">

        <t>Even though it has always been confusing, since the number of TLD was very limited, collision would not happen as "foo" differs from existing TLDs. As a result, evaluating "foo" as Fully Qualified Domain Name, would result in resolving "foo." over the public DNS. When the NXDOMAIN response is received, the resolver understands the name is an Unqualified, and use the search list. Overall the impact was quite limited.</t>

        <t>Similarly, a company may use multiple Domains for its local scope Domain, and provisions its devices with the search list "example example.com". All devices, and network administrators have always considered that the resolution of "foo.example" is either of local scope or fails. As a result, if "foo.example" cannot be resolved, "foo.example.com" is resolved instead. As "example" was not part of the root zone, network administrators have never considered that "foo.example" could actually been resolved on the public DNS infrastructure and provide a response that is different from the one the private Domain. In the context of gTLDs, "example" is likely to be registered in the root zone, and this by another administrative entity than the company using "example" for its private network.</t>

        <t>As the probability of collision was rather small, multiple ways have been implemented to handle the resolution of names including the way to handle search lists -- as with the implicit expansion mechanism. All of these non standard mechanisms provides a variety of ways a resolution is performed which differs from application to application and from operating systems to operating systems. The collision between private domain names and public domain name makes naming resolution unstable and unreliable.</t>
       </section>

        <section title="Structure of the Document">
        <t>With the introduction of generic TLDs (gTLDs), one cannot assume anymore the probability of collision can be ignored.  In order to guarantee the stability and reliability of the naming resolution, this document defines in <xref target="sec:sl-gen"/> how search lists MUST be generated and in <xref target="sec:sl-int"/> how search lists MUST be interpreted. <xref target="sec:dist"/> defines how Qualified and Unqualified Domain Names MUST be distinguished and <xref target="sec:resol"/> defines how resolution for each category of Domain Name MUST be proceeded.</t>

        <t>The expected outcome of such rules are 1) a more reliable and stable naming resolution and 2) a resolution process that is not impacted by the introduction of new gTLDs.</t>

        <t>This document is largely based on <xref target="SAC064"/></t>
        </section>
        </section>

        <section anchor="sec:terminology" title="Terminology">
            <t>
                <list hangIndent="3" style="hanging">
                    <t hangText="-">Qualified Domain Names or Fully Qualified Domain Name (FQDN) or Absolute Domain
Name, is a domain name as defined in <xref target="RFC1035"/> that specifies its exact location in the DNS tree hierarchy, including the public top-level domain and the root zone. By convention, most operating systems treat domain names that include the terminating "." as an FQDN. For example, www.corporation.example.com. specifies an FQDN.</t>

                    <t hangText="-">Unqualified Domain Names is a Domain Name that is not expected to be resolved in the public DNS. In other words, such names is not a FQDN. It is usually an internally used domain name (such as "www.corporation") that only becomes an absolute domain name once expanded as a result of search list processing. The ambiguity of such domains is to define whether it is a FQDN or an Unqualified Multi-label Domain Name. If "example.com" is in the search list and if corporation becomes a gTLD, "www.corporation" can be resolved on the public DNS and "www.corporation.example.com" can also be resolved.</t>

                    <t hangText="-">Multi-label Domain Name or Relative Multi-label Domain Name, is a domain name that consists of more than one label.</t>

                   <t hangText="-">Single Label Domain Name or Dotless Domain Name in some contexts, is a domain name that consists of a single label that is 63 characters or less, starts with a letter, ends with a letter or digit, and has as interior characters only letters, digits, and hyphen as defined by <xref target="RFC1035"/>.</t>  
 <!--
                   <t hangText="-">Partial Domain Name is an Unqualified Multi-label Domain Name or an
Unqualified Single Label Domain Name.</t>
-->
                   <t hangText="-">Generic Top Level Domain (gTLD) is a top level domain. If the list of these top level domain has been quite stable over the years, this list of top level is not any more restricted. As a result, resolving a name cannot be based anymore on the existence or non-existence of the top level domain as it may evolves over time.</t>

                   <t hangText="-">Domain part of a FQDN, is everything after the first dot.</t>
                </list>
            </t>
        </section>

        <section anchor="sec:sl-gen" title="Search List Generation">

       <t>A search lists is an ordered lists of Domains. When a naming resolution involves a search list for a given name, a resolution is performed for each Domain. Suppose "D1.example.com", "D2.foo", "D3.foo" is a search list and "X" is the name to be resolved. Then, the resolver attempts to resolve successively "X.D1.example.com", "X.D2.foo" and "X.D3.foo" until a response is provided.</t>

       <t>To guarantee a reliable and stable way to resolve names, one must also determine a deterministic way to build the search list as well as a deterministic way to handle the search list. To our knowledge the search list may be populated by:
            <list  hangIndent="3" style="hanging">
                <t hangText="- 1)"> An explicit manual search list configuration by the end user. Typically this means the user has manually edit the /etc/resolv.conf file on a Linux platform, or the suffix field in various applications.</t>
                <t hangText="- 2)"> The Domain part of the FQDN assigned to the host. More specifically, the FQDN assigned to the host consists in a Domain appended to a hostname. With DHCPv4 <xref target="RFC2131"/> the Domain is assigned using the DHCP Domain Name Option <xref target="RFC2132"/>. With DHCPv6 <xref target="RFC3315"/>, the Domain is derived from the DHCPv6 Client FQDN Option <xref target="RFC4704"/>.</t>
                <t hangText="- 3)">A search list assigned to the host via the DHCPv4 Domain Search Option <xref target="RFC3397"/> or the DHCPv6 Domain Search Option <xref target="RFC3646"/>.</t>    
                <t hangText="- 4)">Implicit expansion of the search list which consists in expanding the search prefix "corporation.example.com" into the list "corporation.example.com" "example.com" "com".</t>    
            </list>
        </t>

       <t>In order to make systems end up with the same search list, here are our recommendations:
            <list  hangIndent="3" style="hanging">
                <t hangText="- 1)"> If the search list results from a manual configuration, then DHCP Options MUST NOT automatically affect the search list. More specifically, Domain Name derived from DHCPv4 Domain Name Option <xref target="RFC2132"/> or DHCPv6 Client FQDN Option <xref target="RFC4704"/> and DHCP Domain Search Option <xref target="RFC3397"/>, <xref target="RFC3646"/> are ignored for the concerned of search list generation. This follows the recommendations of  <xref target="RFC3397"/> and <xref target="RFC3646"/>.</t>

                <t hangText="- 2)"> If the search list is not manually configured, then DHCP Options MAY be considered. DHCP Domain Search Option <xref target="RFC3397"/>, <xref target="RFC3646"/> are considered. If considered, the search list is only defined by these options and only these options.</t>

                <t hangText="- 3)"> In the absence of DHCP Domain Search Options, the search list is derived from the Domain that is the DHCPv4 Domain Name Option <xref target="RFC2132"/> or DHCPv6 Client FQDN Option <xref target="RFC4704"/>. If so, the search list is only constituted of the Domain name of the host.</t>

                <t hangText="- 4)"> If none of these options are provided, then the search list is empty and resolution are directly performed over the public DNS.</t>
            </list>
       </t>

    </section>

        <section anchor="sec:sl-int" title="Search List Interpretation">

       <t>Here is our recommendations to make search list be handled in the same way across systems:
        <list  hangIndent="3" style="hanging">
        
           <t hangText="- 1)"> Implicit expansion of search domain name MUST NOT be performed. In fact implicit expansion exposes the resolver to security flaws as described in <xref target="RFC1535"/> and <xref target="RFC1536"/>. As a consequence of not using implicit expansion of search list, search list MUST be explicitly expressed. Suppose a resolver is expected to resolve a hostname within "paris.corporation.example.com" and then "corporation.example.com". In this case, the associated search list MUST be "paris.corporation.example.com" "corporation.example.com" and MUST NOT be "paris.corporation.example.com". Avoiding implicit expansion addresses the <xref target="RFC1535"/> requirements of indicating the BOUNDARIES of the local scope. Note that indicating explicitly the search list does not significantly increase the size of the DHCP Domain Search Option if the option follows the compression method of domain name encoding in section 4.1.1 of <xref target="RFC1035"/>. However, if the Option length exceeds 255 bytes, <xref target="RFC3396"/> describes how to use long options.</t>
        </list>
        </t>
    </section>

    <section anchor="sec:dist" title="Distinction of Unqualified and Qualified Domain Names">

        <t>This section defines how the resolver unequivocally considers a name is an Unqualified Domain Name or a Fully Qualified Domain Name. This distinction leads to different resolution process described in <xref target="sec:resol"/>.</t>

        <t>Any name - that is to say a Single-Label Domain Name or a Multi-Label Domain Names - ending with a dot "." is considered as a Fully Qualified Domain as defined in <xref target="RFC1035"/> and <xref target="RFC1535"/>. </t>

        <t>A Single-Label Domain Name not ending with a dot is considered as an Unqualified Domain Name as recommended by <xref target="RFC3397"/> and <xref target="RFC3646"/>.</t>

        <t>A Multi-Label Domain Names is considered as a Qualified Domain Name as recommended by <xref target="RFC3397"/> and <xref target="RFC3646"/>.</t>
        </section>

    <section anchor="sec:resol" title="Resolution of Unqualified and Qualified Domain Names">
        <t>This section defines how the resolver MUST proceed for a resolution for Qualified Domain Names and Unqualified Domain Names.</t> 

        <t>For Qualified Domain Names, the resolver MUST proceed to the resolution over the DNS public infrastructure. If the resolution fails, returning a NXDOMAIN, no attempt SHOULD be done to resolve it as an Unqualified Domain Name.</t>

        <t>For Unqualified Domain Names, the resolver MUST proceed to the resolution using search list. If the resolution fails, returning a NXDOMAIN, no attempt SHOULD be done to resolve it as an Qualified Domain Name.</t>
    
        <t>Rules defined above to differentiate Unqualified and Qualified Domain Names are similar as in <xref target="RFC3397"/> and <xref target="RFC3646"/>. However, the resolution process described in this document differs as we do not permit fall backs to resolution on Qualified or Unqualified Domain Names. In fact, <xref target="RFC3397"/> and <xref target="RFC3646"/> defines the resolution as a best guess whether the name is an Unqualified (resp. Qualified) Domain Name. Then, if the resolution fails with an NXDOMAIN, response, the resolver falls back and considers the name as a Qualified (resp. Unqualified) Domain Name.</t>
       <t>The main purpose at that time was to limit the number of round trips. Processing resolution this way is not any more acceptable in a gTLD context, as it affects the stability and reliability of the naming resolution. Our primary goal in defining how resolution proceeds is to guarantee resolution remains independent of the newly inserted or removed TLD. More specifically, a name that is considered Unqualified must be resolved using search lists, and if the resolution fails, no fall back to Qualified name should be performed. If fall backs are permitted, then the output of the resolution depends on the content of the root zone. Similarly, if a name is considered qualified, no fall back to unqualified should be done.</t> 

       <t>These rules do not make possible the resolution of TLD as Single-Label Domain Name. In this case, the TLD to be resolved SHOULD explicitly mention the resolution MUST be performed over the DNS public infrastructure by appending a dot at the end. <xref target="sec-TLD-A-AAAA"/> shows that some TLDs have already associated A/AAAA records.</t>
        </section>
 

        <section title="IANA Considerations">
            <t>There are no IANA consideration for this document.</t>
        </section>

        <section anchor="sec-security-considerations" title="Security Considerations">
            <t>The whole document is about security, more especially naming reliability and stability.</t>

            <t>The document defines rules to handle search list so a naming resolution remains stable over time. This is done in different ways. First by defining how search lists are generated, and how search lists are interpreted by resolver. Then we designates rules to define in a deterministic manner whether a name to be resolved SHOULD be considered as a Qualified Domain Name or as a Unqualified Domain Name. Each kind of Domain name has its associated resolution process, and we do not permit resolution fall backs. </t>

            <t>These rules are intended to address the flaws described in <xref target="RFC1535"/> and <xref target="RFC1536"/>. The reason for the late fixing is the gTLD program of the ICANN that make now possible to insert new TLDs in the root zone.</t>

            <t>As these rules are not currently deployed, most devices will not have clearly defined boundaries between Qualified and Unqualified resolutions. In addition, fall backs resolution between these two categories will happen and MUST be address by administrator before any new gTLD. </t>

             <t>DNSSEC <xref target="RFC4033"/>, <xref target="RFC4034"/> and <xref target="RFC4035"/> is not designed to distinguish Qualified and Unqualified Domain Names. In fact DNSSEC has been designed to provide a proof of integrity and a proof of ownership. In the case of name collision, if "foo." is in the signed root zone and "foo.example.com" is also signed with DNSSEC, then DNSSEC validates both names. DNSSEC can however help to distinguish between "foo." and "foo.exmaple.com" if the application knows the Key Signing Key (KSK) associated to the expected Domain "example.com". In other words, the KSK will be considered as the Trust Anchor for the requested names.</t>

             <t>DANE <xref target="I-D.ietf-dane-ops"/> uses DNSSEC to provide the cryptographic material, used by the above application or transport layer. If the applications know the certificate or the key used by the layers above, then DANE can be used to distinguish between the expected Names, and the one returned by the resolver.</t>    
        </section>

        <section title="Acknowledgment">
        <t></t>
        </section>

    </middle>

    <back>
        <references title="Normative References">
            &RFC1035;
            &RFC2119;
            &RFC2131;
            &RFC2132;
            &RFC3315;
            &RFC3396;
            &RFC3397;
            &RFC3646;
            &RFC4033;
            &RFC4034;
            &RFC4035;
            &RFC4704;
        </references>


        <references title="Informational References">
            &RFC1535;
            &RFC1536;
            &I-D.ietf-dane-ops;
        <reference anchor="SAC064">      
        <front>
            <title>SAC064: SSAC Advisory on DNS "Search List" Processing</title>
            <author initials="SSAC" fullname="ICANN Security and Stability Advisory Committee"/>
            <date day="13" month="February" year="2014" />
        </front>
        <seriesInfo name="" value="An Advisory from the ICANN Security and Stability Advisory Committee"/>
        <seriesInfo name="URL:" value="http://www.icann.org/en/groups/ssac/documents/sac-064-en.pdf" />
        </reference>
        </references>

        <section title="Document Change Log">
            <t>[draft-mglt-dnsop-search-list-processing-00.txt]: First version published.</t>
        </section>

        <section anchor="sec-TLD-A-AAAA" title="TLDs with A/AAAA">
            <t>This section provides a small command line that tests which TLD has an A or a AAAA RRset.</t>
             <figure anchor="fig-code" title="Command Line to test TLD with A/AAAA">
        <artwork><![CDATA[
wget http://data.iana.org/TLD/tlds-alpha-by-domain.txt 
for i in `cat tlds-alpha-by-domain.txt`; 
    do 
    a=`dig +short -t A $i.`; 
    aaaa=`dig +short -t AAAA $i.`; 
    if [ "${a}" != "" ] || [ "${aaaa}" != "" ]; 
        then 
        echo $i - A:${a}, AAAA:${aaaa}; 
    fi; 
    sleep 1; 
    done
         ]]></artwork>
             </figure>
       <figure anchor="fig-output" title="output">
        <artwork><![CDATA[
AC - A:193.223.78.210, AAAA:
AI - A:209.59.119.34, AAAA:
CM - A:195.24.205.60, AAAA:
DK - A:193.163.102.24, AAAA:2a01:630:0:40:b1a:b1a:2011:1
GG - A:87.117.196.80, AAAA:
IO - A:193.223.78.212, AAAA:
JE - A:87.117.196.80, AAAA:
PN - A:80.68.93.100, AAAA:
SH - A:193.223.78.211, AAAA:
TK - A:217.119.57.22, AAAA:
TM - A:193.223.78.213, AAAA:
TO - A:216.74.32.107, AAAA:
UZ - A:91.212.89.8, AAAA:
WS - A:64.70.19.33, AAAA:

         ]]></artwork>
             </figure>

        </section>

    </back>
</rfc>
