draft-song-dnsop-ixfr-fallback-01.xml

<?xml version="1.0"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC1996 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml">
<!ENTITY RFC1995 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml">
<!ENTITY RFC5936 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">

<!ENTITY I-D.kerr-ixfr-only SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-kerr-ixfr-only-01.xml">
<!ENTITY I-D.ietf-dnsext-rfc1995bis-ixfr SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsext-rfc1995bis-ixfr.xml">
<!ENTITY I-D.song-yeti-testbed-experience SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-song-yeti-testbed-experience-01.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<?rfc tocappendix="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>
<rfc category="info" docName="draft-song-dnsop-ixfr-fallback-01" ipr="trust200902">

  <front>

    <title>An IXFR Fallback to AXFR Case</title>

    <author fullname="Linjian Song" initials="L." surname="Song">
      <organization>Beijing Internet Institute</organization>
      <address>
        <postal>
          <street>2508 Room, 25th Floor, Tower A, Time Fortune</street>
          <city>Beijing</city>
          <region></region>
          <code>100028</code>
          <country>P. R. China</country>
        </postal>
        <email>songlinjian@gmail.com</email>
        <uri>http://www.biigroup.com/</uri>
      </address>
    </author>
    <date/>
    <!-- Meta-data Declarations -->

    <area>Internet Area</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- <keyword>dns</keyword> -->

    <abstract>
      <t>
        This memo introduces an IXFR issue observed during a multiple 
        signers experiment conducted in Yeti DNS project. In the 
        experiment IXFR client is designed to pull the zone from three 
        IXFR servers who used their own key to sign the zone and produce 
        different RRSIG records intentionally. The configuration of 
        multiple signers cause the failure of IXFR in client side.
      </t>

      <t>REMOVE BEFORE PUBLICATION: The source of the document is currently 
        placed at GitHub <xref target="xml-file"/>. Comments and pull request 
        are welcome. </t>

    </abstract>

  </front>

  <middle>

    <section title="Introduction">
    
    <t>In DNS specifications authoritative name server uses full zone 
      transfer (AXFR) <xref target="RFC5936"/>, incremental Zone Transfer 
      (IXFR)<xref target="RFC1995"/>, and NOTIFY <xref target="RFC1996"/> 
      to achieve coherency of the zone contents.  IXFR is an optimization 
      for large DNS zone transfer, which allows server only transfer the 
      changed portion(s) to client.</t>

    <t>AXFR fallback usually happens at server side by simply returning IXFR 
      client the entire new zone in condition that IXFR server cannot fulfill 
      the given delta-update request. It is because an IXFR client may has 
      multiple IXFR servers for a single zone. It is not a protocol defect 
      but do stimulate people to find optimization avoiding full zone transfer 
      <xref target="I-D.kerr-ixfr-only"/> and trying to make a new IXFR protocol 
      <xref target="I-D.ietf-dnsext-rfc1995bis-ixfr"/>. 
    </t>

    <t><xref target="RFC5936"/> suggests that if its upstream servers have different 
      ideas of the zone contents with the same (zone, serial) pair, the client can 
      stop adding records that already exist or deleting records that do not exist.
      However, if an IXFR incoherence error is spotted by that client, it is not clear 
      whether the client should stop IXFR process and ask for AXFR as a fallback. To the 
      author's knowledge, there is such recommendation so far for AXFR fallback 
      initiated by client in formal document. </t>

    <t>This memo introduces an IXFR problem observed during a DNS 
      root experiment in Yeti project<xref target="Yeti-DNS-Project"/> which 
      involves multiple root zone distribution master (DM). It is designed that 
      three DMs do have different "ideas" on how their keys are managed and 
      produce different RRSIG records. In this scenario, it is observed that 
      different DNS implementations have different behaviors due to the ambiguity 
      in understanding of IXFR and fallback to AXFR. </t>

    <t>
     REMOVE BEFORE Publication: The motivation of this memo is to ask for 
     discussion in the community  whether this specific fallback or 
     non-fallback is viewed as a problem. Is it worthwhile developing 
     IXFR protocol further towards rfc1996bis. Or this memo can serve providing some 
     information and guidance to operators who do run authoritative servers 
     in similar situation as it is done in Yeti experiment.  
    </t>

    </section>
    <section title="The IXFR issues observed in MZSK experiment">
    <t>
     As a background for this memo, the introduction of Yeti testbed and 
     experiments can be found in <xref target="I-D.song-yeti-testbed-experience"/>, 
     and section 3.1 and 4.2 are relevant. Conceptually, Yeti DNS intends 
     to break one signer/DM role into three which buys some properties 
     in loosely cooperative environment , such as resilience to single 
     point of failure, more independent choice for slave server, and certain 
     degree of transparency and management coordination for important 
     zone (root zone in Yeti's case).
   </t>
   <t>
     One experiment in Yeti is designed to test multiple signers with Multiple ZSKs (MZSK). 
     It is required that all public ZSKs used by DMs are included in the zone as a 
     key set; and resolver can validate the message by picking one key from the key 
     set. From DNSSEC point of view, it is technically workable. However, different 
     signers do produce different RRSIG RR which introduces zone inconsistency 
     from beginning in this case. In current setting of Yeti experiment, it is 
     possible that one client does AXFR/IXFR from one server and later asks for 
     IXFR from another server. 
    </t>

     <t>
     It is observed that when the IXFR client switched from one IXFR server to another, 
     it received a IXFR response deleting RRSIG record that does not exist. One IXFR client 
     running NSD 4.1.7 rejected IXFR response, made a log indicating a bad data and 
     then asked for full zone transfer. Luckily, Yeti root zone is relatively small (691K), 
     so the fallback to AXFR does not cause significant performance degeneration. But if
     operator does host big zone with MZSK model, it will cause problem based on current 
     IXFR.
     </t>
     <t>
     Another observation is that another IXFR client running Knot 2.1.0 in similar 
     situation just accepts the IXFR response, ignores the differences and generates a 
     merged zone with two RRSIG RRs. It not only produces larger response, but 
     also causes DNSSEC failure when a new zone is generated given that old RRSIG 
     is the signature of old zone RRs.   
     </t>

    </section>

    <section title="Possible solution">


      <t>
         Generally, there are three considerations to this issue. 
      </t>

    <t><list style="symbols">
    <t>Asking for development of RRSIG-aware IXFR format in which the RRSIG is 
      treated as a special and RRSIG RR should always be transfered in full (like 
      it does in AXFR). In the case of MZSK experiment, the old RRSIG record(s) 
      is replaced by the new RRSIG record(s) and no specific deleted RRSIG is 
      sent. Compared to the first case in NSD 4.1.7, it is helpful to reduce 
      the cost for full zone transfer if the zone is fairly large.</t>

    <t>
     Adopting the behavior of NSD 4.1.7 as a improvement for IXFR protocol in which
     an IXFR client should fall back to AXFR automatically in the event of an IXFR 
     incoherence error. To avoid unnecessary full zone transfer, it is desirable that 
     the IXFR client is more "sticky" to the server who transfers the zone to the 
     client last time. 

    </t>
    <t>Without modification of IXFR protocol, asking each IXFR client (root slave 
      in Yeti case) to be tied to a specific IXFR server(Yeti DM). This would 
      decrease redundancy and resiliency but would allow normal IXFR, and may 
      make debugging easier. But the MZSK operation introduce regional DM which 
      is not desirable for Yeti case.</t>
    </list></t>


    </section>

  <section title="Acknowledgments">
    <t>
    Specially thanks to Stephane Bortzmeyer who first spotted the IXFR issues from his NSD and Knot authoritative servers. Acknowledgment to Paul Vixie and Shane Kerr who contributed a lot to this technical finding and possible solutions in this memo. Thanks to Antonio Prado who helped to make the language more readable.
    </t>
  </section> <!-- Acknowledgments -->
  
  </middle>

  <back>

    <references title="References">
      &RFC1996; &RFC1995; &RFC5936;
      &I-D.kerr-ixfr-only;&I-D.ietf-dnsext-rfc1995bis-ixfr;
      &I-D.song-yeti-testbed-experience;

     <reference anchor="Yeti-DNS-Project" target="http://www.yeti-dns.org">
            <front>
                <title>Website of Yeti DNS Project</title>
                <author ></author>
                <date />
            </front>
     </reference>     
      <reference anchor="xml-file" target="https://github.com/songlinjian/ietf-draft-ixfr-ps">
       <front>
        <title>XML source file of IXFR Case draft</title>
       <author>
       <organization></organization>
        </author>
        <date year="2016"></date>
      </front>
    </reference>

     </references>

  </back>
</rfc>