<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY rfc1034 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc2119 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2781 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2781.xml'>
  <!ENTITY rfc3629 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
  <!ENTITY rfc3688 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
  <!ENTITY rfc5730 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml'>
  <!ENTITY rfc5731 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml'>
  <!ENTITY rfc5734 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5734.xml'>
  <!ENTITY rfc5910 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5910.xml'>
  <!ENTITY rfc6672 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml'>
  <!ENTITY rfc7535 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7535.xml'>
  <!ENTITY rfc7942 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml'>
  <!ENTITY I-D.bortzmeyer-dname-root SYSTEM
   'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bortzmeyer-dname-root'>
  <!ENTITY I-D.hildebrand-deth SYSTEM
   'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hildebrand-deth'>
  <!ENTITY W3C.xml PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20001006.xml'>
  <!ENTITY W3C.xmlschema-1 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-1-20041028.xml'>
  <!ENTITY W3C.xmlschema-2 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-2-20041028.xml'>
]>

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

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc iprnotified="no"?>

<!-- <?rfc strict="yes"?> -->

<rfc category="std" ipr="trust200902" docName="draft-bortzmeyer-regext-epp-dname-02">
  <front>
    <title abbrev="EPP Mapping for DNAME delegation">
      EPP&nbsp;Mapping&nbsp;for&nbsp;DNAME&nbsp;delegation&nbsp;of&nbsp;domain&nbsp;names</title>
    <author fullname="Stéphane Bortzmeyer" initials="S." surname="Bortzmeyer">
      <organization>AFNIC</organization>
      <address><postal><street>1, rue
      Stephenson</street><code>78180</code><city>Montigny-le-Bretonneux</city><country>France</country></postal>
      <phone>+33 1 39 30 83 46</phone>
      <email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
    </author>
    <date year="2018" month="March" day="19"/>
    <area>General</area>
    <keyword>EPP</keyword>
    <keyword>Extensible Provisioning Protocol</keyword>
    <keyword>DNAME</keyword>
    <keyword>AS112</keyword>
    <keyword>XML</keyword>
    <keyword>DNS</keyword>

    <abstract>
      <t>This document describes an Extensible Provisioning Protocol
      (EPP) extension mapping for the provisioning and management of
      Domain Name System for domain names stored in a shared central
      repository.  Specified in XML, this mapping extends the EPP
      domain name mapping to provide the ability to delegate a domain
      names through DNAME resource records, thus making the new domain
      an alias of a previous domain.</t>
      <t>REMOVE BEFORE PUBLICATION This document should be discussed
      on the Registration Protocols Extensions (regext) mailing
      list. The source of this document is kept on a Gitlab <eref
      target="https://framagit.org/bortzmeyer/ietf-epp-dname">at
      Framagit</eref>. A list of open issues <eref
      target="https://framagit.org/bortzmeyer/ietf-epp-dname/issues">is
      there as well</eref>.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="intro">
      <t>This document describes an extension mapping for version 1.0 of the
      Extensible Provisioning Protocol (EPP) described in RFC 5730
      <xref target="RFC5730"/>.  This mapping, an extension of the domain name
      mapping described in RFC 5731 <xref target="RFC5731"/>, is specified using
      the Extensible Markup Language (XML) 1.0 <xref target="W3C.REC-xml-20001006"/>
      and XML Schema notation (<xref target="W3C.REC-xmlschema-1-20041028"/>
      <xref target="W3C.REC-xmlschema-2-20041028"/>).</t>

      <t>The EPP core protocol specification <xref target="RFC5730"/>
      provides a complete description of EPP command and response
      structures.  A thorough understanding of the base protocol
      specification is necessary to understand the mapping described
      in this document.  Familiarity with the Domain Name System (DNS)
      described in RFC 1034 <xref target="RFC1034"/> and RFC&nbsp;1035
      <xref target="RFC1035"/> and with the DNS DNAME Resource Record
      type described in RFC 6672 <xref target="RFC6672"/> is required
      to understand the DNS concepts described in this
      document. (DNAME have properties that may be surprising at
      first; for instance, it aliases only the subdomains, not the
      owner name of the DNAME record itself.)</t>

      <t>The EPP mapping described in this document specifies a mechanism
      for the provisioning and management of domain names in a
      shared central repository. Today, most registries allow only
      delegation of domain names to name servers specified in NS
      resource records. DNAME <xref target="RFC6672"/> allow another
      type of delegation, which can be useful for instance for the new
      AS 112 <xref target="RFC7535"/>, as proposed in <xref
target="I-D.bortzmeyer-dname-root"/>. Information exchanged via this mapping
      can be extracted from the repository and used to publish DNAME
      resource records.</t>

      <section title="Conventions Used in This Document" anchor="conventions">
        <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 BCP 14, RFC 2119
        <xref target="RFC2119"/>.</t>

        <t>In examples, "C:" represents lines sent by a protocol client, and "S:"
        represents lines returned by a protocol server.  "////" is used to note
        element values that have been shortened to better fit page boundaries.
        Indentation and white space in examples is provided only to illustrate
        element relationships and is not a mandatory feature of this protocol.</t>

        <t>XML is case sensitive.  Unless stated otherwise, XML specifications
        and examples provided in this document MUST be interpreted in the
        character case presented in order to develop a conforming implementation.</t>
        
        <t>dnameDeleg-1.0 is used as an abbreviation for urn:ietf:params:xml:ns:dnameDeleg-1.0.</t>
        
      </section>
    </section>

    <section title="Object Attributes" anchor="attrs">
      <t>This extension adds additional elements to the EPP domain name
      mapping <xref target="RFC5731"/>.  Only those new elements are
      described here.</t>
      <t>DNAME information is published by a DNS server to indicate
        that a child zone is actually an alias of another zone.  A
        DNAME resource record (RR) contains a single field named
        target. See RFC 6672 <xref target="RFC6672"/> for the specific
        field format.</t>
    </section>
     
    <section title="Presentation">
      <t>It is the server policy to allow DNAME delegations or not. It
      is also the server policy to allow (or not) a domain to switch between
      these two types of delegation with a EPP &lt;update&gt;.</t>
      
     <t>The interface relies on the use of the
     &lt;dnameDeleg:dnameTarget&gt; element for creates, adds,
     removes, and &lt;domain:info&gt; responses.  The data is provided
     by the client. If the DNAME target is in a zone managed by the
     server, the server operator MAY checks its existence in its
     database and the fact that it is not itself a DNAME. Otherwise,
     the server operator MAY issue out-of-band DNS queries to check if
     the target really exists.</t>
     
     <t>The &lt;dnameDeleg:dnameTarget&gt; element contains a domain
     name, as described in Section 2.1 of RFC 6672 <xref
     target="RFC6672"/>.  The value of the
     &lt;dnameDeleg:dnameTarget&gt; element is represented as a
     eppcom:labelType (<xref target="RFC5730"/>, section 4.4, and
     <xref target="W3C.REC-xmlschema-2-20041028"/>).</t>
    </section>
      
      <section title="Examples">
        
      <t>Example use of the dnameDeleg:dnameTarget, for instance for
      an EPP &lt;create&gt;:<vspace blankLines="0"/></t>
<figure><artwork>
&lt;dnameDeleg:dnameTarget&gt;foo.bar.example&lt;/dnameDeleg:dnameTarget&gt;
      </artwork></figure>
      </section>
 
    <section title="EPP Command Mapping" anchor="commands">
      <t>A detailed description of the EPP syntax and semantics can be found in
      the EPP core protocol specification <xref target="RFC5730"/>.
      The command mappings described here are specifically for use in
      provisioning and managing DNAME delegations via EPP.</t>

      <section title="EPP Query Commands" anchor="queries">
        <t>EPP provides three commands to retrieve object information:
        &lt;check&gt; to determine if an object is known to the server,
        &lt;info&gt; to retrieve detailed information associated with an
        object, and &lt;transfer&gt; to retrieve object transfer status
        information.</t>

        <section title="EPP &lt;check&gt; Command" anchor="check">
          <t>This extension does not add any elements to the EPP
          &lt;check&gt; command or &lt;check&gt; response described in
          the EPP domain mapping <xref target="RFC5731"/>. Note that
          an EPP client cannot use &lt;check&gt; to find out if a
          server authorizes DNAME delegation for this specific domain
          (EPP login information is not sufficient because the fact
          that the server supports the extension does not mean it is
          authorized for all names.) [REMOVE BEFORE PUBLICATION: issue
	  #3 discussed the case.]</t>
        </section>

        <section title="EPP &lt;info&gt; Command" anchor="info">
          <t>This extension does not add any elements to the EPP
          &lt;info&gt; command described in the EPP domain mapping
          <xref target="RFC5731"/>. [REMOVE BEFORE PUBLICATION: issue
	  #6 discussed whether or not it would be a good idea.] However,
          additional elements are defined for the &lt;info&gt;
          response.</t>

          <t>When an &lt;info&gt; command has been processed successfully, the
          EPP &lt;resData&gt; element MUST contain child elements as described
          in the EPP domain mapping <xref target="RFC5731"/>.
          In addition, the EPP &lt;extension&gt; element SHOULD contain a child
          &lt;dnameDeleg:dnameTarget&gt; element that identifies the
	  extension namespace if the domain object has data associated
	  with this extension, based on server policy and depending on
	  support of the client for dnameDeleg, based on the EPP login
	  services it provided. The &lt;dnameDeleg:dnameTarget&gt;
          element contains a domain name as its value. A server MUST
	  NOT return both a &lt;dnameDeleg:dnameTarget&gt; and a
	  &lt;domain:ns&gt; (<xref target="RFC5731"/>, section 3.1.2).</t>

           <t>
          <figure>
              <artwork>Example &lt;info&gt; Response 
<![CDATA[
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">
S:           foo.bar.example
S:      </dnameDeleg:dnameTarget>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>
]]>
	      </artwork>
          </figure>
          </t>

          <t>An EPP error response MUST be returned if an &lt;info&gt; command
          cannot be processed for any reason.</t>
        </section>
      </section>

        <section title="EPP &lt;transfer&gt; Command" anchor="transferQ">
          <t>This extension does not add any elements to the EPP &lt;transfer&gt;
          command or &lt;transfer&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>. A domain cannot be switched from
	  NS delegation to DNAME delegation (or vice-versa) through a
	  transfer.</t>
	  <t> Note that this may be one additional reason for a
	transfer to fail: if the gaining registrar does not support
	  DNAME delegation. The server MUST return error code 2106.</t>
        </section>
      </section>

      <section title="EPP Transform Commands" anchor="transforms">
        <t>EPP provides five commands to transform objects: &lt;create&gt; to create
        an instance of an object, &lt;delete&gt; to delete an instance of an object,
        &lt;renew&gt; to extend the validity period of an object, &lt;transfer&gt; to
        manage object sponsorship changes, and &lt;update&gt; to change information
        associated with an object.</t>

        <section title="EPP &lt;create&gt; Command" anchor="create">
          <t>This extension defines an additional element for the EPP &lt;create&gt;
          command described in the EPP domain mapping <xref target="RFC5731"/>.
          No additional elements are defined for the EPP &lt;create&gt; response.</t>

          <t>The EPP &lt;create&gt; command provides a transform operation that allows
          a client to create a domain object.  In addition to the EPP
          command elements described in the EPP domain mapping <xref target="RFC5731"/>,
          the command MUST contain an &lt;extension&gt; element, and the &lt;extension&gt; element
          MUST contain a child &lt;dnameDeleg:dnameTarget&gt; element that identifies
          the extension namespace if the client wants to associate data defined in this extension to the domain object.  
          The &lt;dnameDeleg:dnameTarget&gt; has a domain name as
	  value. A client MUST NOT send both a
	  &lt;dnameDeleg:dnameTarget&gt; and &lt;domain:ns&gt;
	  elements. TODO See issue #4 for the choice of the error
	  code(s).</t>
           <t>
            <figure>
              <artwork>Example &lt;create&gt; Command:
<![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C:  <command>
C:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example</dnameDeleg:dnameTarget>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>
]]>
</artwork>
            </figure>
          </t>

          <t>When a &lt;create&gt; command has been processed successfully, the EPP
          response is as described in the EPP domain mapping <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;delete&gt; Command" anchor="delete">
          <t>This extension does not add any elements to the EPP &lt;delete&gt;
          command or &lt;delete&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;renew&gt; Command" anchor="renew">
          <t>This extension does not add any elements to the EPP &lt;renew&gt;
          command or &lt;renew&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;transfer&gt; Command" anchor="transferT">
          <t>This extension does not add any elements to the EPP &lt;transfer&gt;
          command or &lt;transfer&gt; response described in the EPP domain mapping
          <xref target="RFC5731"/>.</t>
        </section>

        <section title="EPP &lt;update&gt; Command" anchor="update">
          <t>This extension defines additional elements for the EPP &lt;update&gt;
          command described in the EPP domain mapping <xref target="RFC5731"/>.
          No additional elements are defined for the EPP &lt;update&gt; response.</t>

          <t>The EPP &lt;update&gt; command provides a transform operation that
          allows a client to modify the attributes of a domain object.  In
          addition to the EPP command elements described in the EPP domain
          mapping, the command MUST contain an &lt;extension&gt; element, and the &lt;extension&gt; element
          MUST contain a child &lt;dnameDeleg:dnameTarget&gt; element that identifies
          the extension namespace if the client wants to update the domain object with data defined in this extension.  
          The &lt;dnameDeleg:dnameTarget&gt; element has a domain name
	  as its value. If present, it updates the DNAME delegation to
	  the new target, if the domain was already DNAME-delegated,
	  or it switches the domain to a DNAME delegation, if it was
	  previously a NS delegation. A server MAY refuse such a
	  switch, per its policy. In the same way, a RFC 5731 <xref
	  target="RFC5731"/> update with NS information, without the
	  extension decribed here, switches to NS
	  delegation if the domain was previously DNAME-delegated.</t>
	  <t>TODO there is an issue with the switch from NS to DNAME
	  delegation if the domain had in-bailiwick name servers. See
	  issue #7.</t>

          <t>
            <figure>
              <artwork>Example &lt;update&gt; Command, Adding and Removing: 
<![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:          <dnameDeleg:dnameTarget xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0">foo.bar.example
C:          </dnameDeleg:dnameTarget>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>
]]>
	      </artwork>
            </figure>
          </t>

          <t>When an extended &lt;update&gt; command has been processed
          successfully, the EPP response is as described in the EPP domain
          mapping <xref target="RFC5731"/>.</t>
	</section>
      </section>

    <section title="Formal Syntax" anchor="syntax">
      <t>An EPP object mapping is specified in XML Schema notation.  The
      formal syntax presented here is a complete schema representation of
      the object mapping suitable for automated validation of EPP XML
      instances.  The BEGIN and END tags are not part of the schema; they
      are used to note the beginning and ending of the schema for URI
      registration purposes.</t>      
        <figure>
          <artwork>
<![CDATA[
BEGIN
<?xml version="1.0" encoding="utf-8"?>
<schema 
  targetNamespace="urn:ietf:params:xml:ns:dnameDeleg-1.0" 
  xmlns:dnameDeleg="urn:ietf:params:xml:ns:dnameDeleg-1.0" 
  xmlns="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified">
  
  <annotation>
    <documentation> 
      Extensible Provisioning Protocol v1.0 
      domain name extension schema 
      for provisioning DNAME domain names.
    </documentation>
  </annotation>
  
  <!-- 
  Child element found in EPP commands and response.  
  -->
  <element name="dnameTarget" type="string"/>

</schema>
END
]]>
	  </artwork>
        </figure>
<!-- 		</t> -->
    </section>

    <section title="Internationalization Considerations" anchor="i18n">
      <t>EPP is represented in XML, which provides native support for encoding
      information using the Unicode character set and its more compact
      representations including UTF-8 <xref target="RFC3629"/>.  Conformant XML
      processors recognize both UTF-8 and UTF-16 <xref target="RFC2781"/>.  Though
      XML includes provisions to identify and use other character encodings
      through use of an "encoding" attribute in an &lt;?xml?&gt; declaration,
      use of UTF-8 is RECOMMENDED in environments where parser encoding support
      incompatibility exists.</t>

      <t>As an extension of the EPP domain mapping <xref target="RFC5731"/>, 
      the internationalization requirements in the EPP domain mapping <xref target="RFC5731"/> are followed 
      by this extension. This extension does not override any of the EPP domain mapping <xref target="RFC5731"/> 
      internationalization features.</t>  
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document uses URNs to describe XML namespaces and XML schemas
      conforming to a registry mechanism described in RFC 3688 <xref target="RFC3688"/>.
      Two URI assignments have been completed by the IANA.</t>

      <t>Registration request for the extension namespace:</t>

      <t>URI: urn:ietf:params:xml:ns:dnameDeleg-1.0</t>

      <t>Registrant Contact: IESG</t>

      <t>XML: None.  Namespace URIs do not represent an XML specification.</t>

      <t>Registration request for the extension XML schema:</t>

      <t>URI: urn:ietf:params:xml:schema:dnameDeleg-1.0</t>

      <t>Registrant Contact: IESG</t>

      <t>XML: See the "Formal Syntax" section of this document.</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>The mapping extensions described in this document do not provide any
      security services beyond those described by EPP <xref target="RFC5730"/>,
      the EPP domain name mapping <xref target="RFC5731"/>,
      and protocol layers used by EPP.  The security considerations described in
      these other specifications apply to this specification as well.</t>

      <t>As with other domain object transforms, the EPP transform operations
      described in this document MUST be restricted to the sponsoring client
      as authenticated using the mechanisms described in Sections&nbsp;2.9.1.1 and
      7 of RFC 5730 <xref target="RFC5730"/>.  Any attempt to perform a
      transform operation on a domain object by any client other than the
      sponsoring client MUST be rejected with an appropriate EPP authorization
      error.</t>

      <t>The provisioning service described in this document involves
      the exchange of information that can have an operational impact
      on the DNS.  A trust relationship MUST exist between the EPP
      client and server, and provisioning of DNAME delegation MUST
      only be done after the identities of both parties have been
      confirmed using a strong authentication mechanism. This is just
      a repeat of <xref target="RFC5734"/>, section 8.</t>

      <t>An EPP client might be acting as an agent for a zone administrator who
      wants to send DNAME delegation information to be published by the server
      operator.  Man-in-the-middle attacks are thus possible as a result of
      direct client activity or inadvertent client data manipulation.</t>

    </section>

    <section title="Acknowledgements" anchor="acks">    
      <t>Most of the text has been copied from <xref
      target="RFC5910"/>, so thanks to its authors.</t>
      <t>Thanks to James Gould for a detailed review and for
      John Levine and Patrick Mevzek for good remarks. Thanks to
      Patrick Mevzek for the first implementation.</t>
    </section>
  </middle>

  <back>

<?rfc rfcedstyle="no"?>
    <references title="Normative References">
      &rfc2119;
      &rfc3688;
      &rfc5730;
      &rfc5731;
      &rfc6672;
      &W3C.xml;
      &W3C.xmlschema-1;
      &W3C.xmlschema-2;
    </references>

    <references title="Informative References">
      &rfc1034;
      &rfc1035;
      &rfc2781;
      &rfc3629;
      &rfc5734;
      &rfc5910;
      &rfc7535;
      &rfc7942;
      &I-D.bortzmeyer-dname-root;
      &I-D.hildebrand-deth;
    </references>

    <section title="Generic Resource Records type">
      <t>The goal of this document is not to allow arbitrary DNS
      Resource record types (such as TXT or LOC). Such a mapping would
      require the ability to add, update and remove individual
      records, but it would allow the EPP server to implement a
      "delegation-less" registry. An example of such attempt to define
      a standard protocol for provisioning a lot of resource record
      types is <xref target="I-D.hildebrand-deth"/>. But we don't
      follow that path. Instead, we keep the idea that the
      EPP server registers only delegations, either through NS records
      or, as here, a DNAME record. This keeps the mapping much
      simpler.</t>
      <t>For this reason, the possibility to add other resource
      records together with the DNAME (<xref target="RFC6672"/>,
      section 2.4) is out-of-scope here.</t>
    </section>
    
    <section title="Implementation status">
      <t>RFC-EDITOR: REMOVE BEFORE PUBLICATION</t>
      <t>This section records the status of known implementations of
      the protocol defined by this specification at the time of
      posting of this Internet-Draft, and is based on a proposal
      described in <xref target="RFC7942"/>.  The description of implementations in
      this section is intended to assist the IETF in its decision
      processes in progressing drafts to RFCs.  Please note that the
      listing of any individual implementation here does not imply
      endorsement by the IETF.  Furthermore, no effort has been spent
      to verify the information presented here that was supplied by
      IETF contributors.  This is not intended as, and must not be
      construed to be, a catalog of available implementations or their
      features.  Readers are advised to note that other
      implementations may exist.</t>
     <t>
     According to <xref target="RFC7942"/>, "this will allow reviewers and working
     groups to assign due consideration to documents that have the
     benefit of running code, which may serve as evidence of valuable
     experimentation and feedback that have made the implemented
     protocols more mature.  It is up to the individual working groups
     to use this information as they see fit".
     </t>
     <t>This EPP extension is implemented in the <eref
     target="https://metacpan.org/pod/Net::DRI">Net::DRI EPP
     client</eref>, written in Perl. The specific part of Net::DRI is
     <eref
     target="https://metacpan.org/source/PMEVZEK/Net-DRI-0.96_10/lib/Net/DRI/Protocol/EPP/Extensions/DNAME.pm">DNAME.pm</eref>.</t>
    </section>
      
<?rfc rfcedstyle="yes"?>
    
  </back>
</rfc>
