draft-sullivan-domain-origin-assert-02.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>


<rfc category="info" ipr="trust200902" docName="draft-sullivan-domain-origin-assert-02">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <?rfc comments="yes"?>
  <?rfc inline="yes"?>
  <front>
    <title abbrev="Asserting DNS Boundaries">Asserting DNS Administrative
    Boundaries Within DNS Zones</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>
    <date year="2012"/>
    <abstract>
      <t>
        Some clients on the Internet make inferences about the
        administrative relationships among servers on the Internet
        based on the domain names of those servers.  Perhaps
        unfortunately, it is not currently possible to detect the real
        administrative boundaries in the DNS, and therefore such
        inferences can go wrong in several ways.  Mitigation
        strategies deployed so far will not scale.  The solution to
        this is to provide a way to make an explicit assertion about
        the relationships between different domain names and perhaps
        the services provided at them.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Motivation" anchor="motivation">
      <t>Many network resources are accessed primarily by name.  DNS
      names make up the bulk of those names.  As a result, DNS names have
      become fundamental elements in building security policies and
      user agent behaviour.  For example, domain names are used in
      attempts to determine the scope for data sharing of HTTP state
      management cookies <xref target="RFC6265" /> .  The idea is to
      foil the attempts of attackers in (for example)
      attackersite.co.tld from setting cookies for everyone in
      co.tld.</t>

      <t>Another example policy is a user interface convention that
      purports to display the "real" domain name differently from
      other parts of the 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 name is inside "attackersite.tld", in the
      hope of thereby reducing the user's 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
      DNS names and X.509 certificates, see <xref target="RFC6125"
      />.</t>

      <t>One way to build a reasonable policy 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.  Such an approach can be awkward,
      however, when (as is often the case) the real administrative
      boundary is a shared one (in this example, example.org).
      Therefore, clients have attempted to make more sophisticated
      policies.</t>

      <t>Historically, policies were sometimes based on the DNS tree.
      Early policies made a firm distinction between top-level domains
      and everything else; but this was too naive, and later attempts
      were based on inferences from the DNS names themselves.  That
      did not work well, because there is no way in the DNS to
      discover the boundaries of administrative control around domain
      names.</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" />).  Unfortunately, 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 purposes of sites named
      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
      services offered at names in the DNS.</t>

      <t>What appears to be needed is a mechanism to determine
      administrative boundaries in the DNS.  That is, given services
      at two domain names, one needs to be able to answer whether the
      first and the second are under the same administrative control
      and same administrative policies.  We may call this state of
      affairs "lying within the same policy realm".  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 is
      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, publicsuffix.org,
      that publishes a list of domains (henceforth, 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>
    </section>

    <section title="Background, terminology, and organization of this memo">
      <t>The reader is assumed to be familiar with the DNS (<xref
      target="RFC1034" /> <xref target="RFC1035"
      />) and 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><xref target="overview" /> describes the mechanism in general
      terms, outlining two different possible approaches and outlining
      the compromises in each case.  Definitions of the new RRTYPE is
      in <xref target="rrdef" />, with two different definitions to
      allow for the two different approaches.  There is some general
      discussion of the use of the RRTYPE is in <xref target="rruse"
      />.  Then, <xref target="eg" /> offers an example portion of a
      DNS tree that can be used to understand the ways in which the
      mechanism can be used to draw inferences about administrative
      relationships.  <xref target="limitations" /> notes some
      limitations of the mechanism.  <xref target="security" />
      outlines how the mechanism might be used securely.</t>

    </section>

    <section title="Overview of mechanism" anchor="overview">
      <t>This memo presents a way to assert a common administrative
      realm by placing a resource record (RR) at DNS names within the
      policy realm.  The mechanism requires a new resource record type
      (RRTYPE) to enable these assertions, called SOPA (for Start Of
      Policy Authority, echoing the Start Of Authority or SOA record).
      While there are reported difficulties in deploying new RRTYPEs,
      the only RRTYPE that could be used to express all the necessary
      variables is the TXT record, and it is unsuitable because it can
      also be used for other purposes.  The use of this mechanism does
      not require "underscore labels" to scope the interpretation of
      the RR, in order to make it possible to use the mechanism where
      the underscore label convention is already in use.  The SOPA
      RRTYPE is class-independent.</t>

      <t>While many policies of the sort discussed in <xref
      target="motivation" /> appear to be based on domain names, they
      are actually only partly based on them.  Usually, there are
      implicit rules that come from the destination port <xref
      target="RFC6335" /> or scheme <xref target="RFC4395" /> (or
      both) in use.</t>

      <t>It is possible to make those assumptions explicit, but at
      the cost of expressing in the resulting record a tighter
      relationship between the DNS and the services offered at DNS
      names.  There are arguments to be made for each approach.
      <xref target="nameonly" /> and <xref target="nameport" />
      explore the two different approaches; this memo does not make
      a decision about which strategy to adopt.  If there are future
      developments of this memo, one strategy will be selected.</t>

      <t>It is worth observing that a policy realm relationship ought
      to be symmetric: if example.com is in the same policy realm as
      example.net, then example.net should be (it would seem) in the
      same policy realm as example.com.  In principle, then, if a SOPA
      RR at example.com provides a target at example.net, there should
      be a complementary SOPA RR at example.net with a target of
      example.com.  Because of the distributed nature of the DNS, and
      because the other administrative divisions need not follow the
      policy realms, the only way to know whether two names are in the
      same policy realm is to query at each name, and to correlate the
      responses.</t>  
      
      <section title="Identifying names as the scope for policy
                      authority" anchor="nameonly">
        <t>The first approach provides, as the RDATA of a SOPA RR, a
        target name that lies in the same policy realm as the owner
        name in the RR.  For convenience, in what follows this is
        sometimes called this the "names-only" strategy.  Such an
        approach is an assertion on the part of the authoritative DNS
        server for the owner name in question that there is a policy
        relationship between that owner name and the target name.  If
        a single name lies in the same policy realm as several other
        target names, an additional RR is necessary for each such
        relationship, with one exception.  It is not uncommon for two
        different names to have policy relationships among all the
        children beneath them.  Using the SOPA RR, it is possible to
        specify that the target is all the names beneath a name, using
        a wildcard target.</t>

        <t>This approach follows the traditional way that
        relationships are expressed in the DNS, which is historically
        mostly between different names.  Aliases, for instance,
        redirect names or trees, and not names or trees for specific
        RRTYPEs.  It has the disadvantage, however, that it may not
        provide enough information about the relationship between two
        names to make all the inferences one might need about the
        relationship.  For instance, the relationship between two
        hosts might depend on the protocol, port, and scheme in use:
        two domains might share policy for the purposes of connections
        on port 80, but for no other connections.  <cref
        source="ajs@anvilwalrusden.com">Could this be capured by using
        SRV or NAPTR records on both sides of the policy
        relationship?  Too slow?</cref></t>
      </section>

      <section title="Identifying names, schemes, and ports as the scope
                      for policy authority" anchor="nameport">
      <t>The second approach provides, as the RDATA of a SOPA RR, a
      target name that lies in the same policy realm as the owner name
      in the RR, but can identify the relationship as pertaining only
      to certain ports and schemes.  In what follows, for convenience
      this is sometimes called the "port-and-scheme" stragegy.  It
      provides a way to cover ranges of ports with a single resource
      record, and to cover all schemes and ports with a single
      resource record.  It does not, however, permit arbitrary
      combinations of destination point and schemes without using more
      than one RR.</t>
      
      <t>This approach offers a mechanism to express relationships
      between services at a domain name instead of merely between
      names.  As a disadvantage, however, it seems to step outside the
      usual scope of the DNS, which concerns itself with names and not
      services offered at those names.  It might be argued that some
      RRTYPEs (notably SRV <xref target="RFC2782" /> and NAPTR <xref
      target="RFC3403" />) do relate to services; but in those cases, it is
      an expression of services available at an already-named host.
      It would be a significant innovation, perhaps in a bad
      direction, to attempt to express these relationships in a single
      RR.  Since the names are under different administration, also,
      it is entirely possible that the operators of the two domains do
      not agree on the port ranges and schemas to be supported,
      creating an intractable comparison problem for a client.</t>
      </section>
    </section>

    <section title="The SOPA Resource Record" anchor="rrdef">
      
      <t>Because of the two approaches outlined in <xref
      target="nameonly" /> and <xref target="nameport" />, this
      section provides two different outlines of the SOPA resource
      record.  This arrangement is pending the decision about which
      strategy to adopt, at which time the discussion below will be
      reduced to reflect that decision.</t>

      <section title="Thr SOPA Resource Record only for names" anchor="rrdefno">
        <t>In this case, the SOPA resource record, type number [TBD1], includes the
        following fields:
        <list style="hanging">
          <t hangText="Name:">The owner name of the RR.</t>
          <t hangText="TTL:">The time to live for the RR.</t>
          <t hangText="Class:">The CLASS for the RR.  As of this
          writing, on the contemporary Internet this is almost always
          "IN", but the SOPA RR is class-independent.</t>
          <t hangText="SOPA:">The RRTYPE field.</t>
          <t hangText="Target:">A DNS name relative to the root that is
          in the same policy realm as the SOPA RR's owner
          name.  The name MUST be a DNS name according to the rules in
          <xref target="RFC1034" /> and <xref target="RFC1035" />, except
          that the left-most label of the target MAY be the wildcard
          character ("*").  In addition, the target may be "."; in that
          case, the RR asserts that there are no other names in the same
          policy realm.  For further discussion, see <xref
          target="specials" />.  The target MUST NOT be an alias <xref
          target="RFC2181" />, such as the owner name of a CNAME <xref
          target="RFC1034" />, DNAME <xref target="RFC6672" />, or other
          similar such resource records.</t>
        </list></t>
        <t>The SOPA RRTYPE's wire format is as follows:</t>
        
        <t><cref source="ajs@anvilwalrusden.com">To follow if this
        idea (and this version of it) turns out worth pursuing.  It
        can be derived from above, however.</cref>
        </t>
      </section>

      <section title="Thr SOPA Resource Record with ports and schemes" anchor="rrdefps">
        <t>In this case, the SOPA resource record, type number [TBD1],
        includes the following fields:
        <list style="hanging">
          <t hangText="Name:">The owner name of the RR.</t>
          <t hangText="TTL:">The time to live for the RR.</t>
          <t hangText="Class:">The CLASS for the RR.  As of this
          writing, on the contemporary Internet this is almost always
          "IN", but the SOPA RR is class-independent.</t>
          <t hangText="SOPA:">The RRTYPE field.</t>
          <t hangText="Starting port:">The port number that begins the
          range to which this SOPA RR applies.  This is a 16 bit
          unsigned integer in network byte order.  The range is
          0-65535.</t>
          <t hangText="Ending port:">The port number that ends the range
          for which this SOPA RR applies.  This is a 16 bit unsigned
          integer in network byte order.  The range is 0-65535.</t>

          <t hangText="Scheme:">The scheme to which the SOPA RR
          applies.  The scheme SHOULD be listed in the <eref
          target="http://www.iana.org/assignments/uri-schemes.html">IANA
          Uniform Resource Identifier (URI) Schemes registry</eref>.
          <cref source="ajs@anvilwalrusden.com">This is "SHOULD" right
          now, but I think it should be "MUST".  I can't think of a
          reason why not to make it MUST.</cref>  Alternatively, the
          field may contain the special value "*", in which case the
          SOPA RR applies to all schemes, with a limitation: some
          clients use certain schemes only for internal operations, and
          regardless of whether those schemes are included in an SOPA
          RR, they MAY be ignored.</t>

          <t hangText="Target:">A DNS name relative to the root that is
          in the same policy realm as the SOPA RR's owner
          name.  The name MUST be a DNS name according to the rules in
          <xref target="RFC1034" /> and <xref target="RFC1035" />, except
          that the left-most label of the target MAY be the wildcard
          character ("*").  In addition, the target may be "."; in that
          case, the RR asserts that there are no other names in the same
          policy realm.  For further discussion, see <xref
          target="specials" />.  The target MUST NOT be an alias <xref
          target="RFC2181" />, such as the owner name of a CNAME <xref
          target="RFC1034" />, DNAME <xref target="RFC6672" />, or other
          similar such resource records.</t>
        </list></t>
        <t>The SOPA RRTYPE's wire format is as follows:</t>
        
        <t><cref source="ajs@anvilwalrusden.com">To follow if this
        idea (and this version of it) turns out worth pursuing.  It
        can be derived from above, however.</cref>
        </t>
      </section>
    </section>

    <section title="Use of the SOPA RRTYPE"
             anchor="rruse">

      <t>SOPA RRs may have, in effect, three different functions.  The
      simplest is to make an assertion that two DNS names are in the
      same policy realm.  Under the port-and-scheme strategy, if the
      Starting Port is 0, the Ending Port is 65535, the Scheme is "*",
      and the Target is anything other than ".", then the SOPA record
      makes a claim that the owner name and the target name are in the
      same policy realm in every case.  This is also the claim
      whenever the names-only stragey is in use, and the RDATA has a
      target other than ".".</t>

      <t>The second function, available only under the port-and-scheme
      strategy, is to make an assertion that two DNS names are in the
      same policy realm, but only for some subset of ports or schemes
      or both.  There is a 1:1 port mapping presumed in the way the
      SOPA RR is structured, such that it is not possible to say that
      port N at the owner name is related to port M at the target
      name.  This is an expedient for simplicity.  For the same
      reasons of simplicity, the SOPA RR permits linking all schemes
      between names, or else one scheme; a given RR does not permit
      listing more than one scheme without using the wildcard
      selector.</t>

      <t>The third function is to make an assertion that no other name
      lies in the same policy realm as the owner name.  If
      there are names beneath that owner name, this is a way for a DNS
      operator to assert that the owner name is a public suffix.  For
      more details, see <xref target="specials" />.</t>
    
      <t> There could be more than one SOPA resource record per owner
      name in a response.  Each domain name in the RDATA is treated as
      a part of the same policy realm as the owner name in the
      original QNAME (subject to the qualifications of scheme and port
      contained in the SOPA RR in the port-and-scheme strategy).  The
      QNAME from the query might not be the owner name of the SOPA RR:
      if the original QNAME was an alias, then the SOPA owner name
      will be different.</t>

      <t>There are three possible responses to a query for the SOPA
      RRTYPE at an owner name that are relevant to determining the
      policy realm.  The first is Name Error (RCODE=3, also
      known as NXDOMAIN).  In this case, the owner name itself does
      not exist, and no further processing is needed.</t>

      <t>The second is a No Data response <xref target="RFC2308"  />
      of any type.  The No Data response means that the owner name in
      the QNAME does not recognize any other name as part of a
      common policy realm.</t>

      <t>The final is a response with one or more SOPA resource
      records in the Answer section.  Each SOPA resource record
      asserts a relationship between the owner name and the target
      name, according to the functions of the SOPA RRTYPE outlined
      above.</t>

      <t>Any other response is no different from any other sort of
      response from the DNS, and is not in itself meaningful for
      determining the policy realm of a name (though it
      might be meaningful for finding the SOPA record).</t>

      <section title="Special target labels" anchor="specials">
        <section title="The root target" anchor="dot">

          <t>An SOPA resource record with the single character "."
          (called the "root target") in the RDATA is a positive
          assertion that no other domain name falls inside the
          policy realm of the owner name.  The record has a
          special use: it may be used to bootstrap operation.  A client
          that has encountered the root target may remember the
          existence of the root target even after the expiry of the TTL
          on the RRset, until such time as a new query for the owner
          name may be made successfully.  This rule permits
          implementations to cache positive statements of administrative
          isolation during disconnected periods, thereby starting a
          subsequent session with the values of prior affirmed policy.
          Apart from this bootstrapping use, and the ability of such an
          RR to have a TTL independent of the negative TTL value for the
          zone, this mechanism is semantically equivalent to a No Data
          response.</t>

          <t>It would be absurd for the root target for any given schema
          to exist with any other SOPA resource record at that owner
          name.  An authoritative name server MAY refuse to serve a zone
          containing such an inconsistency, MAY refuse to load a zone
          containing such an inconsistency, or MAY suppress every SOPA
          RR at an owner name and schema except that containing the root
          target.  The name server side of a recursive resolver MAY
          discard every SOPA RR at an owner name except that
          containing the root target.  Conforming servers MUST NOT serve
          the root target and any other SOPA RR at the same owner
          name.  Clients receiving a SOPA RRset that includes the root
          target MUST accept that RR, and discard any other RR in the
          RRset.</t>
          
        </section>
        <section title="Wildcards in targets" anchor="wildcardtarget">
          <t>The special character "*" in the Target field is used to
          match any label, according to the wildcard label rules in
          section 4.3.3 of <xref target="RFC1034" />.  Note that,
          because of the way wildcards work in the DNS, is it not
          possible to place a restriction to the left of a wildcard; so,
          for instance, example.*.example.com does not work.  The effect
          is maintained in this memo.  An authoritative name server MUST
          NOT serve an SOPA RR with erroneous wildcards, and clients
          receiving such an SOPA RR MUST discard the RR.  If the
          discarded RR is the last RR in the answer section of the
          response, then the response is treated as a No Data response.</t>
        </section>
      </section>

      <section title="What can be done with an SOPA RR"
               anchor="utility">
        <t>Use of an SOPA RR enables a site administrator to assert
        or deny relationships between names.  By the same token, it
        permits a a consuming client to detect these assertions and
        denials.</t>

        <t>Some of these relationships are currently impossible to
        indicate in the DNS.  For example, IDN character variants (see
        <xref target="RFC4290" />) result in situations where multiple
        labels are sometimes intended to be treated as though they are
        the same.  Without a mechanism for binding the names together
        even loosely, such a goal cannot be achieved.</t>

        <t>The use of SOPA RRs could either replace the public
        suffix list or (more likely due to some limitations -- see
        <xref target="limitations" />) simplify and automate the
        management of the public suffix list.  A client could use the
        responses to SOPA queries to refine its determinations about
        http cookie Domain attributes.  In the absence of SOPA RRs
        at both owner names, a client might treat a Domain attribute
        as though it were omitted.  More generally, SOPA RRs would
        permit additional steps similar to steps 4 and 5 in <xref
        target="RFC6265" />.</t>

        <t>SOPA RRs might be valuable for certificate authorities when
        issuing certificates, because it would allow them to check
        whether two names are related in the way the party requesting
        the certificate claims they are.</t>
      </section>

    </section>

    <section title="An example case" anchor="eg">

      <t>For the purposes of discussion, it will be useful to
      imagine a portion of the DNS, using the domain example.tld.  A
      diagram of the tree of this portion is in <xref
      target="sampletree" />.  In the example, the domain
      example.tld includes several other names: www.example.tld,
      account.example.tld, cust1.example.tld, cust2.example.tld,
      test.example.tld, cust1.test.example.tld, and
      cust2.test.example.tld.

      <figure anchor="sampletree">
        <artwork><![CDATA[
                          tld
                           |   
                           |     
                  ------example ----- 
                 /     /   |  \      \
                /     /    |   \      \
               /   www  account \      cust2
           test                  \
          /   \                   cust1
      cust1   cust2
]]></artwork>
      </figure></t>
      
      <t>In the example, the domain tld delegates the domain
      example.tld.  There are other possible cut points in the
      example, and depending on whether the cuts exist there may be
      implications for the use of the examples.  See <xref
      target="worked" />, below.</t>
      <t>The (admittedly artificial) example permits us to
      distinguish a number of different roles.  To begin with, there
      are three parties involved in the operation of services:
      <list style="symbols">
        <t>OperatorV, the operator of example.tld;</t>
        <t>Operator1, the operator of cust1.example.tld;</t>
        <t>Operator2, the operator of cust2.example.tld.</t>
      </list></t>
      <t>Since there are three parties, there are likely three
      administrative boundaries as well; but the example contains
      some others.  For instance, the names www.example.tld and
      example.tld are in this case in the same policy realm.
      By way of contrast, account.example.tld might be treated as
      completely separate, because OperatorV might wish to ensure
      that the accounts system is never permitted to share anything
      with any other name.  By the same token, the names underneath
      test.example.tld are actually the test-instance sites for
      customers.  So cust1.test.example.tld might be in the same
      policy realm as cust1.example.tld, but
      test.example.tld is certainly not in the same administrative
      realm as www.example.tld.</t>
      <t>Finally, supposing that Operator1 and Operator2 merge their
      operations, it seems that it would be useful for
      cust1.example.tld and cust2.example.tld to lie in the same
      policy realm, without including everything else in
      example.tld.</t> 
      
      <section title="Examples of using the SOPA record for determining
                      boundaries" anchor="worked">
        <t>This section provides some examples of different
        configurations of the example tree in <xref target="eg" />,
        above.  The examples are not exhaustive, but may provide an
        indication of what might be done with the mechanism.  <cref
        source="ajs@anvilwalrusden.com">This needs to have examples of
        using the ports and scheme added to it.  Suggestions welcome.
        Also, I think some examples could be made longer to make them
        clearer.  Maybe complete zone files in presentation form in an
        appendix?</cref></t>

      
        <section title="One delegation, eight administrative
                        realms, no root target" anchor="18nu">
          <t>In this scenario, the example portion of the DNS name
          space contains all and only the following SOPA records for
          the names-only strategy:
          <list style="empty">
            <t>
            </t>
            <t>example.tld         86400   IN  SOPA  www.example.tld</t>
            <t>www.example.tld     86400   IN  SOPA  example.tld</t>
          </list></t>
          <t>For the scheme-and-port strategy, these are the records instead:
          <list style="empty">
            <t>
            </t>
            <t>example.tld         86400   IN  SOPA  0 65535 * www.example.tld</t>
            <t>www.example.tld     86400   IN  SOPA  0 65535 * example.tld</t>
          </list>
          </t>
          <t>Tld is the top-level domain, and has delegated
          example.tld.  The operator of example.tld makes no
          delegations.  There are four operators involved: the
          operator of tld; OperatorV; Operator1, the operator of the
          services at cust1.example.tld and cust1.test.example.tld;
          and Operator2, the operator of the services at
          cust2.example.tld and cust2.test.example.tld.</t>
          <t>In this arrangement, example.tld and www.example.tld
          positively claim to be within the same policy realm.
          Every other name stands alone.  A query for an SOPA record
          at any of those other names will result in a No Data
          response, which means that none of them include any other
          name in the same policy realm.  As a result, there
          are eight separate policy realms in this case: tld,
          {example.tld and www.example.tld}, test.example.tld,
          cust1.test.example.tld, cust2.test.example.tld,
          account.example.tld, cust1.example.tld, and cust2.example.tld.</t>
        </section>
        <section title="One delegation, eight administrative
          realms, root targets" anchor="18u">
          <t>This example mostly works the same way as the one in
          Section <xref target="18nu" />, but there is a slight
          difference.  In this case, in addition to the records listed
          in <xref target="18nu" />, both tld and test.example.tld
          publish root targets in their SOPA records.  For names-only:
          <list style="empty">
            <t>
            </t>
            <t>tld                      86400  IN  SOPA  .</t>
            <t>test.example.tld         86400  IN  SOPA  .</t>
          </list></t>

          <t>For scheme-and-port:
          <list style="empty">
            <t>
            </t>
            <t>tld                      86400  IN  SOPA  0 65535 * .</t>
            <t>test.example.tld         86400  IN  SOPA  0 65535 * .</t>
          </list></t>
          <t>The practical effect of this is largely the same as the
          previous example, except that these expressions of policy
          last 86,400 seconds instead of the length of time on the
          negative TTL in the relevant SOA for the zone.  Many zones
          have short negative TTLs because of expectations that
          newly-added records will show up quickly.  This mechanism
          permits such names to express their administrative isolation
          for predictable periods of time.  Moreover, because clients
          are permitted to retain these records during periods when
          DNS service is not available, a client could go offline for
          several weeks, and return to service with the presumption
          that test.example.tld is still not in any policy realm with
          any other name.</t>
        </section>
        <section title="Two delegations, seven or eight policy realms,
          root targets" anchor="27v8u">
          <t>In this scenario, example.tld delegates the name
          test.example.tld.  In this case, in addition to the SOPA
          record at test.example.tld, there is an SOA record for
          test.example.tld.  So, there are the same SOPA records as
          in <xref target="18u" />.  The addition of the SOA record
          for test.example.tld does not affect the relationship
          between test.example.tld and example.tld.  At this point,
          there are eight policy realms.</t>
          <t>Next, the Operator1 determines that it is safe to treat
          the test instance and production instance as being in the
          same policy realm.  To begin with, Operator1 asks
          OperatorV to add the following record to the
          test.example.tld zone for the names-only case:
          <list style="empty">
            <t>
            </t>
            <t>cust1.test.example.tld  86400   IN  SOPA  cust1.example.tld</t>
          </list></t>
          <t>And for the scheme-and-port case:
          <list style="empty">
            <t>
            </t>
            <t>cust1.test.example.tld  86400   IN  SOPA 0 65535 * cust1.example.tld</t>
          </list></t>


          <t>This arrangement is not complete yet.  Until a record is
          also added at cust1.example.tld, Operator1's intention
          is only half fulfilled.  The service at
          cust1.test.example.tld treats cust1.example.tld as part of
          a common policy realm, but the converse is not the
          case.  <cref source="ajs@anvilwalrusden.com">I can't decide
          whether there's anything useful in this configuration.
          Thoughts?  I also can't decide whether this is still 8 admin
          realms, 7 admin realms but broken, or 7 admin realms from
          one perspective and 8 from another.</cref></t>
          <t>To complete the process, Operator1 asks OperatorV to add
          the following record to the example.tld zone in the
          names-only case:
          <list style="empty">
            <t>
            </t>
            <t>cust1.example.tld  86400   IN  SOPA cust1.test.example.tld</t>
          </list></t>
          <t>In the scheme-and-port case:
          <list style="empty">
            <t>
            </t>
            <t>cust1.example.tld  86400   IN  SOPA 0 65535 * cust1.test.example.tld</t>
          </list></t>

          <t>Once this is complete, both names treat the other as part
          of the same policy realm.  In the end, the example
          segment of the DNS expresses the following seven
          policy realms: tld, {example.tld, www.example.tld},
          test.example.tld, {cust1.test.example.tld,
          cust1.example.tld}, cust2.example.tld, account.example.tld,
          cust2.test.example.tld.</t>
        </section>
      </section>
    </section>
<!--    <section title="Wildcards and the SOPA Resource Record" anchor="wildcards">
      <t>A zone publisher can cause all domains beneath it to be in
      the same administrative boundary by publishing a wildcard
      record.  For example, the wildcard expansion of an SOPA
      record at *.example.com with a target of *.example.com would
      mean that every name beneath example.com considers every other
      name beneath example.com to be within the administrative
      boundary.</t>
    </section> -->

    <section title="Limitations of the approach and other considerations" anchor="limitations">
      <t>There are four significant problems with this proposal, all
      of which are related to using DNS to deliver the data.</t>
      <t>The first is that new DNS RRTYPEs are difficult to deploy.
      While adding a new RRTYPE is straightforward, many provisioning
      systems do not have the necessary support and some firewalls and
      other edge systems continue to filter RRTYPEs they do not
      know.</t>
      <t>The second is that it is difficult for an application to
      obtain data from the DNS.  The TTL on an RRset, in particular,
      is usually not available to an application, even if the
      application uses the facilities of the operating system to
      deliver other parts of an unknown RRTYPE.</t>
      <t>The third, which is mostly a consequence of the above two, is
      that there is a significant barrier to adoption: until browsers
      have mostly all implemented this, operations need to proceed as
      though nobody has.  But browsers will need to support two
      mechanisms for some period of time if they are to implement this
      mechanism at all, and they are unlikely to want to do that.
      This may mean that there is no reason to implement, which also
      means no reason to deploy.  This is made worse because, to be
      safe, the mechanism really needs DNSSEC, and performing DNSSEC
      validation at end points is still an unusual thing to do.  This
      limitation may not be as severe for use-cases that are directed
      higher in the network (such as using this mechanism as an
      automatic feed to keep the public suffix list updated, or for
      the use of CAs when issuing certificates.</t>
      <t>Finally, in many environments the system hosting the
      application has only proxied access to the Internet, and cannot
      query the DNS directly.  It is not clear how such clients could
      ever possibly retrieve the SOPA record for a name.</t>

      <section title="Handling truncation" anchor="truncation">
        <t>It is possible to put enough SOPA records into a zone such
        that the resulting response will exceed DNS or UDP protocol
        limits.  This is especially true in the case where one wishes
        to take advantage of the scheme-and-port approach, and one
        expresses many different such relationship.  In such cases, a
        UDP DNS response will arrive with the TC (truncation) bit set.
        An SOPA response with the TC bit must be queried again in
        order to retrieve a complete response, in order to ensure that
        there is no missing root target (see <xref target="dot"
        />), generally using TCP.  This increases the cost of the
        query, increases the time to being able to use the answer, and
        may not work at all in networks where administrators
        mistakenly block port 53 using TCP.</t>
      </section>

    </section>
    <section title="Security Considerations" anchor="security">
      <t>This mechanism enables publication of assertions about
      administrative relationships of different DNS-named systems on
      the Internet.  If such assertions are 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, 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>
    </section>
    <section title="IANA Considerations" anchor="iana">
      <t>IANA will be requested to register the SOPA RRTYPE if this
      proceeds.</t>
    </section>
    <section title="Acknowledgements">
      <t>The author thanks Adam Barth, Dave Crocker, Jeff Hodges, John Klensin,
      Murray Kucherawy, Gervase Markham, Patrick McManus, Henrik
      Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas Roessler,
      Peter Saint-Andre, and Maciej Stachowiak for helpful comments. </t>
    </section>
   </middle>
  <back>

    <references title="Normative References">

<!-- BEGIN INCLUDED references file draft-sullivan-domain-origin-assert-02.xml-normative -->


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

<reference anchor='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>


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

<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>


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

<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>


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

<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>


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

<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>


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

<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>


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

<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>

<!-- END INCLUDED references file draft-sullivan-domain-origin-assert-02.xml-normative -->
    </references>
      
    <references title="Informative References">

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


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

<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>


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

<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>


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

<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>


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

<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>


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

<reference anchor='RFC3403'>

<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'>
<organization /></author>
<date year='2002' month='October' />
<abstract>
<t>This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules.  The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).  Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record.  It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).  It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]</t></abstract></front>

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


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

<reference anchor='RFC4290'>

<front>
<title>Suggested Practices for Registration of Internationalized Domain Names (IDN)</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>This document explores the issues in the registration of internationalized domain names (IDNs).  The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names.  To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations.  This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names.  This memo provides information for the Internet community.</t></abstract></front>

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


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

<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>


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

<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>


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

<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>


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

<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>


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

<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>

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

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

    <section title="Change History">
      <t><list style="hanging">
        <t hangText="00 to 01:">
          <list style="symbols">
            <t>Changed the mnemonic from BOUND to AREALM</t>
            <t>Added ports and scheme to the RRTYPE</t>
            <t>Added some motivating text and suggestions about what
            can be done with the new RRTYPE</t>
            <t>Removed use of "origin" term, because it was
            confusing.  The document filename preserves "origin" in the
            name in order that the tracker doesn't lose the change
            history, but that's just a vestige.</t>
            <t>Removed references to cross-document information
            sharing and ECMAScript.  I don't understand the issues
            there, but Maciej Stachowiak convinced me that they're
            different enough that this mechanism probably won't work.</t>
            <t>Attempted to respond to all comments received.  Thanks
            to the commenters; omissions and errors are mine.</t>
          </list>
        </t>
        <t hangText="01 to 02:">
          <list style="symbols">
            <t>Changed mnemonic again, from AREALM to SOPA.  This in
            response to observation by John Klensin that anything
            using "administrative" risks confusion with the standard
            administrative boundary language of zone cuts.</t>
            <t>Add discussion of two strategies: name-only or
            scheme-and-port.</t>
            <t>Increase prominence of utility to CAs.  This use
            emerged in last IETF meeting.</t>
        </list></t>
      </list></t>
    </section>
  </back>
</rfc>