draft-sullivan-dbound-problem-statement-02.xml

<?xml version="1.0" encoding="UTF-8"?>


<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

  <!ENTITY rfc2119 PUBLIC '' 
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> 

  <!ENTITY RFC.3986     PUBLIC ""  
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">

]>


  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <?rfc subcompact="no"?>
  <?rfc comments="yes"?>
  <?rfc inline="yes"?>


<rfc category="std" ipr="trust200902" docName="draft-sullivan-dbound-problem-statement-02">

  <front>

    <title abbrev="DNS Boundaries Problem">
       DBOUND: DNS Administrative Boundaries Problem Statement
    </title>

    <author initials="A." surname="Sullivan" fullname="Andrew Sullivan">
      <organization>Dyn, Inc.</organization>
      <address>
        <postal>
          <street>150 Dow St</street>
          <city>Manchester</city>
          <region>NH</region>
          <code>03101</code>
          <country>U.S.A.</country>
        </postal>
        <email>asullivan@dyn.com</email>
      </address>
    </author>

    <author initials="J." surname="Hodges" fullname="Jeff Hodges">
      <organization>PayPal</organization>
      <address>
        <postal>
          <street>2211 North First Street</street>
          <city>San Jose</city>
          <region>California</region>
          <code>95131</code>
          <country>US</country>
        </postal>
        <email>Jeff.Hodges@KingsMountain.com</email>
      </address>
    </author>
    
          <author fullname="John Levine" initials="J." surname="Levine">
    <organization>Taughannock Networks</organization>

    <address>
       <postal>
          <street>PO Box 727</street>
          <city>Trumansburg</city>
          <code>14886</code>
          <region>NY</region>
       </postal>
       <phone>+1 831 480 2300</phone>
       <email>standards@taugh.com</email>
       <uri>http://jl.ly</uri>
    </address>
      </author>
 <!---
     I _think_ Casey wants to be left off this, because he has an
     alternative.  Confirming.  ajs
     
<author initials="C." surname="Deccio" fullname="Casey Deccio">
      <organization>Verisign</organization>
      <address>
        <email>casey@deccio.net</email>
      </address>
    </author>
-->

    <date />

    <workgroup>DBOUND</workgroup>

    <abstract>
      <t>
        Some Internet client entities on the Internet make inferences
        about the administrative relationships among services on the
        Internet based on the domain names at which they are offered.
        At present, it is not possible to ascertain organizational
        administrative boundaries in the DNS, therefore such
        inferences can be erroneous in various ways.  Mitigation
        strategies deployed so far will not scale.  This memo outlines
        what issues are to be addressed.
      </t>
    </abstract>

  </front>


  <middle>
  
      <section title="Prerequisites, Terminology, and Organization of this Memo"
     anchor="sect-prereqs">

      <t>The reader is assumed to be familiar with the DNS (<xref
      target="RFC1034" /> <xref target="RFC1035"
      />) and the Domain Name System Security Extensions (DNSSEC) (<xref
      target="RFC4033"  /> <xref target="RFC4034"  /> <xref
      target="RFC4035"  /> <xref target="RFC5155"
       />).</t>

      <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" >RFC 2119</xref>.</t>

      <t>To begin, <xref target="motivation"
      /> describes introduces the problem space and motivations for this work. 
      Then, <xref target="usecases" /> discusses the cases
      where a there are needs for discerning administrative boundaries in the DNS
      domain name space.  
      </t>

    </section>

    <section title="Introduction and Motivation" anchor="motivation">
      <t>Many Internet resources and services, especially at the
      application layer, are identified primarily by DNS domain names
      <xref target="RFC1034"/>. As a result, domain names have become
      fundamental elements in building security policies and also in
      affecting user agent behaviour.  </t>

      <t>For example, domain names are used for defining the scope of
      HTTP state management "cookies" <xref target="RFC6265" />.  In
      addition there is a user interface convention that purports to
      display an "actual domain name" differently from other parts of
      a fully-qualified domain name, in an effort to decrease the
      success of phishing attacks.  In this strategy, for instance, a
      domain name like "www.bank.example.com.attackersite.tld" is
      formatted to highlight that the actual domain name ends in
      "attackersite.tld", in the hope of reducing user's potential
      impression of visiting "www.bank.example.com".</t>

      <t>Issuers of X.509 certificates make judgements about
      administrative boundaries around domains when issuing the
      certificates.  For some discussion of the relationship between
      domain names and X.509 certificates, see <xref target="RFC6125"
      />.</t>

      <t>We can call the interpretation of domain names for these
      security policies a domain-use rule. The simplest rule, and the
      one most likely to work, is to treat each different domain name
      distinctly.  Under this approach, foo.example.org,
      bar.example.org, and baz.example.org are all just different
      domains.  Unfortunately, this approach is too naive to be
      useful.  Often, the real control over domain names is the same
      in several names (in this example, example.org and its
      children).  Therefore, clients have attempted to make more
      sophisticated rules around some idea of such shared control.  We
      call such an area of shared control a "policy realm", and the
      control held by the administrator of policy realm the "policy
      authority".</t>

      <t>Historically, rules were sometimes based on the DNS tree.
      Early rules made a firm distinction between top-level domains
      and everything else; but this was also too naive, and later
      attempts were based on inferences from the domain names themselves.
      That did not work well, because there is no way in the DNS to
      discover the boundaries of policy realms.</t>

      <t> Some have attempted to use the boundary of zone cuts
      (i.e. the location of the zone's apex, which is at the SOA
      record; see <xref target="RFC1034" /> and <xref target="RFC1035"
      />).  That boundary is neither necessary nor sufficient for
      these purposes: it is possible for a large site to have many,
      administratively distinct subdomain-named sites without
      inserting an SOA record, and it is also possible that an
      administrative entity (like a company) might divide its domain
      up into different zones for administrative reasons unrelated to
      the names in that domain.  It was also, prior to the advent of
      DNSSEC, difficult to find zone cuts.  Regardless, the location
      of a zone cut is an administrative matter to do with the
      operation of the DNS itself, and not useful for determining
      relationships among policy realms.</t>

      <t>The different uses of domain names and their related issues
      often appear to be different kinds of problems.  The issue of
      whether two names may set cookies for one another appears to be
      a different matter from whether two names get the same
      highlighting in a browser's address bar, or whether a particular
      name "owns" all the names underneath it.  But the problems all
      boil down to the same fundamental problem, which is that of
      determining whether two different names in the DNS are under the
      control of the same entity and ought to be treated as having an
      important administrative relationship to one another.</t>

      <t>What appears to be needed is a mechanism to determine policy
      realm boundaries in the DNS.  That is, given two domain names,
      one needs to be able to answer whether the first and the second
      are either within the same policy realm or have policy realms
      that are related in some way.  We may suppose that, if this
      information were to be available, it would be possible to make
      useful decisions based on the information.</t>

      <t>A particularly important distinction for security purposes
      has been the one between names that are mostly used to contain
      other domains, as compared to those that are mostly used to
      operate services.  The former are often "delegation-centric"
      domains, delegating parts of their name space to others, and are
      frequently called "public suffix" domains or "effective TLDs".
      The term "public suffix" comes from a site, <xref
      target="publicsuffix.org"/>, that publishes a list of domains

        -- which is also known as the "effective TLD (eTLD) list", and
        henceforth in this memo as the "public suffix list"
        --

        that are used to contain other domains.  Not all, but
      most, delegation-centric domains are public suffix domains; and
      not all public suffix domains need to do DNS delegation,
      although most of them do.  The reason for the public suffix list
      is to make the distinction between names that must never be
      treated as being in the same policy realm as another,
      and those that might be so treated.  For instance, if "com" is
      on the public suffix list, that means that "example.com" lies in
      a policy realm distinct from that of com.
      </t>

      <t>Unfortunately, the public suffix list has several inherent
      limitations.  To begin with, it is a list that is separately
      maintained from the list of DNS delegations.  As a result, the
      data in the public suffix list can diverge from the actual use
      of the DNS.  Second, because its semantics are not the same as
      those of the DNS, it does not capture unusual features of the
      DNS that are a consequence of its structure (see <xref
      target="RFC1034" /> for background on that structure).  Third,
      as the size of the root zone grows, keeping the list both
      accurate and synchronized with the expanding services will
      become difficult and unreliable.  Perhaps most importantly, it
      puts the power of assertion about the operational policies of a
      domain outside the control of the operators of that domain, and
      in the control of a third party possibly unrelated to those
      operators.</t>

      <t>There have been suggestions for improvements of the public
      suffix list,  most notably in <xref
      target="I-D.pettersen-subtld-structure" />. It is unclear
      the extent to which those improvements would help, because they
      represent improvements on the fundamental mechanism of keeping
      metadata about the DNS tree apart from the DNS tree itself.</t>

      <t>Moreover, it is not entirely plain that the public/private
      distinction is really the best framework with which to
      understand the problem.  It is plain that any solution that
      emerges will need, to be useful, to provide a way of making the
      public/private distinction, since so much deployed software
      relies on that distinction.  It seems possible, however, that
      greater nuance would provide distinctions that are currently
      desired but cannot be supported using the public suffix list.
      The best way to figure this out is to enumerate known problems
      and see whether there is something common underlying them all,
      or whether the different problems might at least be grouped into a
      few common cases.</t>

    </section>

    <section title="For the Use Case, Must an Ancestor Impose Policy?"
             anchor="sec_ancestor_impose">
      <t>It is possible to identify two common policy patterns into
      which practical uses fall.  One is a positive policy that will
      necessarily be imposed by an ancestor in case a policy for the
      owner name itself is not available.  The other is a policy that
      need not get inherited from an ancestor.  Negative assertions by
      an ancestor (i.e. that a descendent does not share a policy
      realm) fall into this category, because the descendent does not
      have a positive policy imposed.</t>
      <t>The first pattern we may call the inheritance type.  In this
      use pattern, a client attempting to identify a policy that
      applies at a given name will use a policy found at a name closer
      to the root of the DNS, if need be.  This approach is useful
      when a client must have some kind of policy in order to continue
      processing.  Because the DNS is a hierarchical name system, it
      is always possible for a subordinate name to be permitted only
      in case the superordinate policies are followed.</t>
      <t>The second pattern we may call the orphan type.  In this use
      pattern, if a policy at a name is not specifically offered then
      it is better to assume there is a null policy than to infer some
      inherited policy.  Note that orphan names might be related to
      other names (which makes the term somewhat unfortunate).
      Rather, in these cases policy is assumed to be unshared unless
      there is evidence otherwise.  <cref
      source="ajs@anvilwalrusden.com">Probably something better than
      "orphan" would be good, but I can't think of a better
      name.</cref>
      </t>
      <t>The choice of which pattern is preferable depends largely on
      what the use of a policy seeks to achieve.  Some uses of policy
      require determination of commonality among domains; in such
      cases, the inheritance pattern may be needed.  Other uses are
      attempts to identify differences between domains; in such cases,
      the orphan pattern is useful.</t>
      <t>The public suffix list provides a starting point for both
      patterns, but is neither necessary nor sufficient for either
      case.  Where the inheritance pattern is used, the public suffix
      list provides a minimal starting point whence inheritance can
      start.  Where the orphan pattern is used, the public suffix
      list provides the exclusion needed, but cannot provide either
      evidence that the list is up to date nor evidence that two owner
      names reside in the same policy realm.</t> 
    </section>

    <section title="Use Cases" anchor="usecases">

      <t>This section outlines some questions and identifies some
      known use cases of the public suffix list.</t>

      <t>
        <list style="hanging">
          <t hangText="HTTP state management cookies">
            The mechanism can be used to determine the scope for data
            sharing of HTTP state management cookies <xref
            target="RFC6265" />.  Using this mechanism, it is possible
            to determine whether a service at one name may be
            permitted to set a cookie for a service at a different
            name.  (Other protocols use cookies, too, and those
            approaches could benefit similarly.)  An application has
            to answer in this case the question, "Should I accept a
            cookie for domain X from the domain Y I am currently
            visiting?"</t>
          
          <t hangText="User interface indicators">
            User interfaces sometimes attempt to indicate the "real"
            domain name in a given domain name.  A common use is to
            highlight the portion of the domain name believed to be
            the "real" name -- usually the rightmost three or four
            labels in a domain name string.  An application has to
            answer in this case the question, "What domain name is
            relevant to show the user in this case?"  The answer to
            this must be some portion of the domain name being
            displayed, but it is user- and context-sensitive.</t>

          <t hangText="Setting the document.domain property">
            The DOM same-origin policy might be helped by being able
            to identify a common policy realm.  An application has to
            answer in this case the question, "Is domain X under the
            same control as domain Y?"  It's worth noting that, in
            this case, neither X nor Y need be actually visible to a
            user.</t>

          <t hangText="Email authentication mechanisms">
            Mail authentication mechanisms such as DMARC <xref
            target="I-D.kucherawy-dmarc-base" /> need to be able to
            find policy documents for a given domain name given a
            subdomain.  An application performing DMARC processing
            must answer the question, "Given the domain X currently
            being evaluated, where in the DNS is the DMARC record?"
            DMARC depends on the DNS hierarchical relationship, and
            unlike some other cases wants to find the DMARC record
            that is closest to the root zone.</t>

          <t hangText="SSL and TLS certificates">
            Certificate authorities need to be able to discover
            delegation-centric domains in order to avoid issuance of
            certificates at or above those domains.  There are two
            cases:
            <list style="symbols">
              <t>A certificate authority must answer the question,
              "Should I sign a certificate at this domain name given
              the request before me?"</t> <t>A certificate authority
              must answer the question, "Should I sign a certificate
              for a wildcard at this domain name?"</t> </list><cref
              source="ajs@anvilwalrusden.com">There is another case
              here, noted by Jeffrey Walton, about "verifying the
              end-entity certificate issued by an organizational
              subordinate CA *without* constraints."  I didn't
              understand the issue well enough to write the text
              here.</cref></t>

          <t hangText="HSTS and Public Key Pinning with
                       includeSubDomains flag set">
            Clients that are using HSTS and public key pinning using
            includeSubDomains need to be able to determine whether a
            subdomain is properly within the policy realm of the
            parent.  An application performing this operation must
            answer the question, "Should I accept the rules for using
            X as valid for Y.X?"
          </t>

          <t hangText="Linking domains together for merging
                       operations">
            It is frequently the case that domain names are aliases
            for one another.  Sometimes this is because of an ongoing
            merger (as when one company takes over another and merges
            operations).  A client encountering such a site needs to
            answer the question, "Is domain X just another name for
            domain Y?"</t>
          
          <t hangText="Linking domains together for reporting
                       purposes">
            An application that wants to categorize domains for the
            purposes of reporting must answer the question, "Are these
            two names versions of each other for the purposes of
            reporting statistics?"
          </t>
          
          
          <t hangText="DMARC science fiction use case">
            DMARC's current use of the PSL is to determine the 'Organizational 
            Domain'.. for use when discovering DMARC policy records.  PSL works 
            well enough for production environments in today's world.
            
            However, after hearing about cross-domain requirements of cookies and 
            cross-domain security use cases in the browser, it strikes me that any 
            functionality (policy authority?) that allows domains to be linked would 
            be incredibly useful in the DMARC world, too.  DMARC?s requirement for
            Identifier Alignment between SPF-authenticated domain, DKIM d=domain, 
            and a message?s From: domain could be relaxed to include domains that 
            were somehow associated via a policy authority.
            
            This capability would be *very* nice to have at hand.
            
          </t>
          
          
          
        </list>
      </t>

    </section>


      <section title="Security Considerations" anchor="security">
      <t>A mechanism that satisfied the needs outline above would
      enable publication of assertions about administrative
      relationships of different DNS-named systems on the Internet.
      If such assertions were to be accepted without checking that
      both sides agree to the assertion, it would be possible for one
      site to become an illegitimate source for data to be consumed in
      some other site.  In general, positive assertions about another
      name should never be accepted without querying the other name
      for agreement.</t>
      <t>Undertaking any of the inferences suggested in this draft
      without the use of the DNS Security Extensions exposes the user
      to the possibility of forged DNS responses.</t>
      <t>This memo does not actually specify any mechanisms, so it
      raises no security considerations itself.</t>
    </section>
    <section title="IANA Considerations" anchor="iana">
      <t>This memo makes no requests of IANA.</t>
    </section>
    <section title="Acknowledgements">
      <t>The authors thank Adam Barth, Dave Crocker, Casey Deccio,
      Brian Dickson, Jothan Frakes, Daniel Kahn Gillmor, Phillip
      Hallam-Baker, John Klensin, Murray Kucherawy, Gervase Markham,
      Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric
      Rescorla, Thomas Roessler, Peter Saint-Andre, Maciej Stachowiak,
      and Jeffrey Walton for helpful comments or suggestions. </t>
    </section>
   </middle>
  <back>

<!--  
    <references title="Normative References">


    </references>
 --> 
      
    <references title="Informative References">

<!-- BEGIN INCLUDED references file draft-sullivan-domain-origin-assert-03.xml-informative -->

   <!--  &RFC.3986; --> <!--   <xref target="RFC3986"/>  --> 


<!--
<reference anchor='CABF-BRv1.2.3'>
<front>
<title>CA/Browser Forum Baseline Requirements for the Issuance and 
       Management of Publicly-Trusted Certificates, v.1.2.3</title>

<author>
   <organization>
    CA/Browser Forum
    </organization>
</author>

<date month='Oct' day='16' year='2014' />

</front>
<format type='TXT'
        target='https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf' />
</reference>
-->


<reference anchor='I-D.kucherawy-dmarc-base'>
<front>
<title>Domain-based Message Authentication, Reporting and Conformance (DMARC)</title>

<author initials='M' surname='Kucherawy' fullname='Murray Kucherawy'>
    <organization />
</author>

<date month='March' day='31' year='2013' />

<abstract><t>
     The email ecosystem currently lacks a cohesive mechanism through which email
   senders and receivers can make use of multiple authentication protocols in an
   attempt to establish reliable domain identifiers.  This lack of cohesion
   prevents receivers from providing domain-specific feedback to senders regarding
   the accuracy of authentication deployments.  Inaccurate authentication
   deployments preclude receivers from safely taking deterministic action against
   email that fails authentication checks.  Finally, email senders do not have the
   ability to publish policies specifying actions that should be taken against
   email that fails multiple authentication checks.  This memo presents a proposal
   for a scalable mechanism by which an organization can express, using the Domain
   Name System, domain-level policies and preferences for message validation,
   disposition, and reporting with predictable and accurate results.  The enclosed
   proposal is not intended to introduce mechanisms that provide elevated delivery
   privilege of authenticated email.  The proposal presents a mechanism for policy
   distribution that enables a continuum of increasingly strict handling of
   messages that fail multiple authentication checks, from no action, through
   silent reporting, up to message rejection.
</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-kucherawy-dmarc-base-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-base-00.txt' />
</reference>



<reference anchor='I-D.pettersen-subtld-structure'>
<front>
<title>The Public Suffix Structure file format and its use for Cookie domain validation</title>

<author initials='Y' surname='Pettersen' fullname='Yngve Pettersen'>
    <organization />
</author>

<date month='March' day='6' year='2012' />

<abstract><t>
   This document defines the term "Public Suffix domain" as meaning a domain under
   which multiple parties that are unaffiliated with the owner of the Public Suffix
   domain may register subdomains.  Examples of Public Suffix domains include
   "org", "co.uk", "k12.wa.us" and "uk.com".  It also defines a file format that
   can be used to distribute information about such Public Suffix domains to
   relying parties.  As an example, this information is then used to limit which
   domains an Internet service can set HTTP cookies for, strengthening the rules
   already defined by the cookie specification.  This specification updates RFC
   6265 [RFC6265] by defining the term "Public Suffix domain".
</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pettersen-subtld-structure-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-09.txt' />
</reference>



<reference anchor='RFC1034'> <!--   <xref target="RFC1034"/>  --> 

<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization></author>
<date year='1987' day='1' month='November' /></front>

<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>



<reference anchor='RFC1035'>

<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1987' day='1' month='November' /></front>

<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' octets='125626' target='http://www.rfc-editor.org/rfc/rfc1035.txt' />
</reference>


<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>


<!--
<reference anchor='RFC2181'>

<front>
<title abbrev='DNS Clarifications'>Clarifications to the DNS Specification</title>
<author initials='R.' surname='Elz' fullname='Robert Elz'>
<organization>Computer Science</organization>
<address>
<postal>
<street>Parkville</street>
<street>Victoria</street>
<street>3052</street>
<street>Australia.</street></postal>
<email>kre@munnari.OZ.AU</email>
<uri>e</uri></address></author>
<author initials='R.' surname='Bush' fullname='Randy Bush'>
<organization>RGnet, Inc.</organization>
<address>
<postal>
<street>5147 Crystal Springs Drive</street>
<street>Bainbridge Island</street>
<street>Washington</street>
<street>98110</street>
<street>United States.</street>
<country>NE</country></postal>
<email>randy@psg.com</email></address></author>
<date year='1997' month='July' />
<area>Applications</area>
<keyword>DNS</keyword>
<keyword>domain name system</keyword></front>

<seriesInfo name='RFC' value='2181' />
<format type='TXT' octets='36989' target='http://www.rfc-editor.org/rfc/rfc2181.txt' />
<format type='HTML' octets='54106' target='http://xml.resource.org/public/rfc/html/rfc2181.html' />
<format type='XML' octets='38931' target='http://xml.resource.org/public/rfc/xml/rfc2181.xml' />
</reference>
-->


<!--
<reference anchor='RFC2308'>

<front>
<title abbrev='DNS NCACHE'>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author initials='M.' surname='Andrews' fullname='Mark Andrews'>
<organization>CSIRO - Mathematical and Information Sciences</organization>
<address>
<postal>
<street>Locked Bag 17</street>
<street>North Ryde NSW 2113</street>
<country>AUSTRALIA</country></postal>
<phone>+61 2 9325 3148</phone>
<email>Mark.Andrews@cmis.csiro.au</email></address></author>
<date year='1998' month='March' />
<area>Applications</area>
<keyword>domain name system</keyword>
<keyword>DNS</keyword>
<abstract>
<t>
   [RFC1034] provided a description of how to cache negative responses.
   It however had a fundamental flaw in that it did not allow a name
   server to hand out those cached responses to other resolvers, thereby
   greatly reducing the effect of the caching.  This document addresses
   issues raise in the light of experience and replaces [RFC1034 Section
   4.3.4].
</t>
<t>
   Negative caching was an optional part of the DNS specification and
   deals with the caching of the non-existence of an RRset [RFC2181] or
   domain name.
</t>
<t>
   Negative caching is useful as it reduces the response time for
   negative answers.  It also reduces the number of messages that have
   to be sent between resolvers and name servers hence overall network
   traffic.  A large proportion of DNS traffic on the Internet could be
   eliminated if all resolvers implemented negative caching.  With this
   in mind negative caching should no longer be seen as an optional part
   of a DNS resolver.
</t></abstract></front>

<seriesInfo name='RFC' value='2308' />
<format type='TXT' octets='41428' target='http://www.rfc-editor.org/rfc/rfc2308.txt' />
<format type='HTML' octets='50045' target='http://xml.resource.org/public/rfc/html/rfc2308.html' />
<format type='XML' octets='41491' target='http://xml.resource.org/public/rfc/xml/rfc2308.xml' />
</reference>
-->

<!--
<reference anchor='RFC2782'>

<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date year='2000' month='February' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
   server(s) for a specific protocol and domain.</t></abstract></front>

<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='http://www.rfc-editor.org/rfc/rfc2782.txt' />
</reference>
-->

<!--
<reference anchor='RFC3597'>
   <front>
      <title>Handling of Unknown DNS Resource Record (RR) Types</title>
      <author initials='A.' surname='Gustafsson' fullname='A. Gustafsson'>
      <organization /></author>
      <date year='2003' month='September' />
      <abstract>
      <t>
        Extending the Domain Name System (DNS) with new Resource Record (RR) types
        currently requires changes to name server software.  This document specifies the		
        changes necessary to allow future DNS implementations to handle new RR types
        transparently. [STANDARDS-TRACK]
      </t>
      </abstract>
   </front>
   <seriesInfo name='RFC' value='3597' />
   <format type='TXT' octets='17559' target='http://www.rfc-editor.org/rfc/rfc3597.txt' />
</reference>
-->



<reference anchor='RFC4033'>

<front>
<title>DNS Security Introduction and Requirements</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System.  This document
introduces these extensions and describes their capabilities and limitations.
This document also discusses the services that the DNS security extensions do
and do not provide.  Last, this document describes the interrelationships
between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]
</t></abstract></front>

<seriesInfo name='RFC' value='4033' />
<format type='TXT' octets='52445' target='http://www.rfc-editor.org/rfc/rfc4033.txt' />
</reference>




<reference anchor='RFC4034'>

<front>
<title>Resource Records for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>
This document is part of a family of documents that describe the DNS Security
Extensions (DNSSEC). The DNS Security Extensions are a collection of resource
records and protocol modifications that provide source authentication for the
DNS. This document defines the public key (DNSKEY), delegation signer (DS),
resource record digital signature (RRSIG), and authenticated denial of existence
(NSEC) resource records. The purpose and format of each resource record is
described in detail, and an example of each resource record is
given.&lt;/t>&lt;t> This document obsoletes RFC 2535 and incorporates changes
from all updates to RFC 2535. [STANDARDS-TRACK]
</t></abstract></front>

<seriesInfo name='RFC' value='4034' />
<format type='TXT' octets='63879' target='http://www.rfc-editor.org/rfc/rfc4034.txt' />
</reference>




<reference anchor='RFC4035'>

<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>This document is part of a family of documents that describe the DNS Security
Extensions (DNSSEC). The DNS Security Extensions are a collection of new
resource records and protocol modifications that add data origin authentication
and data integrity to the DNS. This document describes the DNSSEC protocol
modifications. This document defines the concept of a signed zone, along with
the requirements for serving and resolving by using DNSSEC. These techniques
allow a security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications.&lt;/t>&lt;t> This document obsoletes RFC
2535 and incorporates changes from all updates to RFC 2535.
[STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4035' />
<format type='TXT' octets='130589' target='http://www.rfc-editor.org/rfc/rfc4035.txt' />
</reference>



<!--
<reference anchor='RFC4395'>

<front>
<title>Guidelines and Registration Procedures for New URI Schemes</title>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'>
<organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'>
<organization /></author>
<date year='2006' month='February' />
<abstract>
<t>This document provides guidelines and recommendations for the definition of
Uniform Resource Identifier (URI) schemes.  It also updates the process and IANA
registry for URI schemes.  It obsoletes both RFC 2717 and RFC 2718.  This
document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for
improvements.</t></abstract></front>

<seriesInfo name='BCP' value='35' />
<seriesInfo name='RFC' value='4395' />
<format type='TXT' octets='31933' target='http://www.rfc-editor.org/rfc/rfc4395.txt' />
</reference>
-->



<reference anchor='RFC5155'>

<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'>
<organization /></author>
<author initials='G.' surname='Sisson' fullname='G. Sisson'>
<organization /></author>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='D.' surname='Blacka' fullname='D. Blacka'>
<organization /></author>
<date year='2008' month='March' />
<abstract>
<t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC
resource record (RR) for authenticated denial of existence.  This document
introduces an alternative resource record, NSEC3, which similarly provides
authenticated denial of existence.  However, it also provides measures against
zone enumeration and permits gradual expansion of delegation-centric zones.
[STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5155' />
<format type='TXT' octets='112338' target='http://www.rfc-editor.org/rfc/rfc5155.txt' />
</reference>




<reference anchor='RFC6125'>

<front>
<title>Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>Many application technologies enable secure communication between two
entities by means of Internet Public Key Infrastructure Using X.509 (PKIX)
certificates in the context of Transport Layer Security (TLS).  This document
specifies procedures for representing and verifying the identity of application
services in such interactions. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6125' />
<format type='TXT' octets='136507' target='http://www.rfc-editor.org/rfc/rfc6125.txt' />
</reference>




<reference anchor='RFC6265'>

<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'>
<organization /></author>
<date year='2011' month='April' />
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fields.  These
header fields can be used by HTTP servers to store state (called cookies) at
HTTP user agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol.  Although cookies have many historical
infelicities that degrade their security and privacy, the Cookie and Set-Cookie
header fields are widely used on the Internet.  This document obsoletes RFC
2965. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6265' />
<format type='TXT' octets='79724' target='http://www.rfc-editor.org/rfc/rfc6265.txt' />
</reference>



<!--
<reference anchor='RFC6335'>

<front>
<title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'>
<organization /></author>
<author initials='L.' surname='Eggert' fullname='L. Eggert'>
<organization /></author>
<author initials='J.' surname='Touch' fullname='J. Touch'>
<organization /></author>
<author initials='M.' surname='Westerlund' fullname='M. Westerlund'>
<organization /></author>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'>
<organization /></author>
<date year='2011' month='August' />
<abstract>
<t>This document defines the procedures that the Internet Assigned Numbers
Authority (IANA) uses when handling assignment and other requests related to the
Service Name and Transport Protocol Port Number registry. It also discusses the
rationale and principles behind these procedures and how they facilitate the
long-term sustainability of the registry.&lt;/t>&lt;t> This document updates
IANA's procedures by obsoleting the previous UDP and TCP port assignment
procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and
it updates the IANA service name and port assignment procedures for UDP-Lite,
the Datagram Congestion Control Protocol (DCCP), and the Stream Control
Transmission Protocol (SCTP). It also updates the DNS SRV specification to
clarify what a service name is and how it is registered. This memo documents an
Internet Best Current Practice.</t></abstract></front>

<seriesInfo name='BCP' value='165' />
<seriesInfo name='RFC' value='6335' />
<format type='TXT' octets='79088' target='http://www.rfc-editor.org/rfc/rfc6335.txt' />
</reference>
-->


<!--
<reference anchor='RFC6672'>
<front>
<title>DNAME Redirection in the DNS</title>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<author initials='W.' surname='Wijngaards' fullname='W. Wijngaards'>
<organization /></author>
<date year='2012' month='June' />
<abstract>
<t>The DNAME record provides redirection for a subtree of the domain name tree
in the DNS.  That is, all names that end with a particular suffix are redirected
to another part of the DNS.  This document obsoletes the original specification
in RFC 2672 as well as updates the document on representing IPv6 addresses in
DNS (RFC 3363). [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6672' />
<format type='TXT' octets='45704' target='http://www.rfc-editor.org/rfc/rfc6672.txt' />
</reference>
-->

      <reference anchor='publicsuffix.org'> <!--  <xref target="publicsuffix.org"/>  --> 
        <front>
          <title>Public Suffix List</title>

          <author >
            <organization>
              Mozilla Foundation
              </organization>
          </author>
		     <date />
        </front>
        <seriesInfo name='also known as:' value='Effective TLD (eTLD) List' />
        <format type='TXT'  
          target='http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1' />
			<annotation>https://publicsuffix.org/</annotation>
      </reference>

<!-- END INCLUDED references file draft-sullivan-domain-origin-assert-03.xml-informative -->
    </references>

    <section title="Discussion Venue">
      <t>This Internet-Draft is discussed on the applications area
      working group mailing list: dbound@ietf.org.</t>
    </section>

    <section title="Change History">
      <t>[this section to be removed by RFC-Editor prior to publication as an RFC]</t>
      <t><list style="hanging">
        <t hangText="Version 01">Add questions from John Levine
        posting to mailing list.</t>
        <t hangText="Version 00">Initial version.</t>
      
        
        <t>This is a -00 Internet-draft, but borrows from various prior draft works, listed below, as well as from discussions on the mailing list. 
        </t>
        
        
        
        <t><list style="hanging">
          <t hangText="Andrew Sullivan, Jeff Hodges: Asserting DNS Administrative 
                       Boundaries Within DNS Zones">
            <list>
              <t>http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01</t>
              <t>https://github.com/equalsJeffH/dbound/blob/master/draft-sullivan-dbound-problem-statement-00.xml</t>
            </list>
          </t>
          
        </list></t>
        
        <t><list style="hanging">
          <t hangText="John Levine: Publishing Organization Boundaries in the DNS">
            <list>
              <t>https://tools.ietf.org/html/draft-levine-orgboundary-02</t>
              <t>https://github.com/equalsJeffH/dbound/blob/master/draft-levine-orgboundary-02.txt</t>
            </list>
          </t>
          
      </list></t>
      
      
      
      <t><list style="hanging">
        <t hangText="Casey Deccio, John Levine: Defining and Signaling
                     Relationships Between Domains">
          <list>
            <t>http://www.ietf.org/mail-archive/web/dbound/current/pdfwad2AxxkYo.pdf</t>
            <t>http://www.ietf.org/mail-archive/web/dbound/current/msg00141.html</t>
            <t>https://github.com/equalsJeffH/dbound/blob/master/deccio-dbound-problem_statement-v3.pdf?raw=true</t>
            <t>https://github.com/equalsJeffH/dbound/blob/master/deccio-dbound-problem_statement-v3.txt</t>
          </list>
        </t>
        
      </list></t>
      
      </list></t>

      
 <!--
      <t><list style="hanging">
        <t hangText="00 to 01:">
          <list style="symbols">
            <t>Changed foo to bar</t>
            <t>Added barfaz to whatchamacallit</t>

          </list>
        </t>

      </list></t>
    -->  
    </section>

</back>
</rfc>


<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->