draft-song-atr-large-resp.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 RFC1035 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC6891 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC7872 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml">
<!ENTITY RFC7873 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml">
 

<!ENTITY I-D.taylor-v6ops-fragdrop SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-taylor-v6ops-fragdrop-02.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="exp" docName="draft-song-atr-large-resp-02" ipr="trust200902">

  <front>

    <title>ATR: Additional Truncation Response for Large DNS Response </title>

    <author fullname="Linjian Song" initials="L." surname="Song">
      <organization>Beijing Internet Institute</organization>
      <address>
        <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>
        As the increasing use of DNSSEC and IPv6, there are more 
        public evidence and concerns on IPv6 fragmentation issues 
        due to larger DNS payloads over IPv6. This memo introduces an 
        simple improvement on DNS server by replying an additional 
        truncated response just after the normal fragmented response. 
        It can be used to relieve users suffering on DNS latency and 
        failures due to large DNS response. 
      </t>

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

    </abstract>

  </front>

  <middle>

    <section title="Introduction">

      <t>
        Large DNS response is identified as a issue for a 
        long time. There is an inherent mechanism defined in 
        <xref target="RFC1035" /> to handle large DNS response 
        (larger than 512 octets) by indicating (set TrunCation bit) 
        the resolver to fall back to query via TCP. Due to the fear of 
        cost of TCP, EDNS(0) <xref target="RFC6891" /> was 
        proposed which encourages server to response larger 
        response instead of falling back to TCP. However, as the 
        increasing use of DNSSEC and IPv6, there are more public 
        evidence and concerns on user's suffering due to packets 
        dropping caused by IPv6 fragmentation in DNS due to large 
        DNS response. 
      </t>
  
      <t>  
        It is observed that some IPv6 network devices 
        like firewalls intentionally choose to drop the IPv6 
        packets with fragmentation Headers<xref target="I-D.taylor-v6ops-fragdrop"/>. 
        <xref target="RFC7872"/> reported more than 30% drop rates for sending 
        fragmented packets. Regarding IPv6 fragmentation issue due 
        to larger DNS payloads in response, one measurement <xref target="IPv6-frag-DNS"/>
        reported 35% of endpoints using IPv6-capable DNS resolver 
        can not receive a fragmented IPv6 response over UDP. Moreover, 
        most of the underlying issues with fragments are unrevealed 
        due to good redundancy and resilience of DNS. It is hard for DNS 
        client and server operators to trace and locate the issue when 
        fragments are blocked or dropped. The noticeable DNS failures 
        and latency experienced by end users are just the tip of the iceberg.
      </t>

       <t> 
        Depending on retry model, the resolver's 
        failing to receive fragmented response may experience long 
        latency or failure due to timeout and reties. One typical case 
        is that the resolver finally got the answer after several retires 
        and it falls back to TCP after deceasing the payload size in EDNS0. 
        To avoid that issue, some authoritative servers may adopt a policy 
        ignoring the UDP payload size in EDNS0 extension and always 
        truncating the response when the response size is large than a 
        expected one. However one study <xref target="Not-speak-TCP"/> 
        shows that about 17% of resolvers in the samples can not ask a 
        query in TCP when they receive truncated response. It seems a dilemma 
        to choose hurting either the users who can not receive fragments 
        or the users without TCP fallback capacity. There is also some voice of "moving 
        all DNS over TCP". But It is generally desired that DNS can keep 
        the efficiency and high performance by using DNS UDP in most of 
        time and fallback as soon as possible to TCP if necessary for some 
        corner case.
       </t>

       <t>To relieve the problem, this memo introduces an small improvement 
        on DNS responding process by replying an Additional Truncated 
        Response (ATR) just after a normal large response which is to be 
        fragmented. Generally speaking ATR provides a way to decouple the 
        EDNS0 and TCP fallback in which they can work independently according 
        to the server operator's requirement. One goal of ATR is to relieve 
        the hurt of users, both stub and recursive resolver, from the position 
        of server, both authoritative and recursive server. It does not 
        require any changes on resolver and has a deploy-and-gain feature 
        to encourage operators to implement it to benefit their resolvers.  
       </t>
<!--
      <t>
        Another possible use of ATR is to help troubleshooting for DNS operators 
        where ATR can be deployed as a measurement tool to identify vulnerable 
        servers and users. The presence of both Large EDNS0 payload size and 
        TrunCation bit can tell if there is any fragment not 
        received in a certain transaction with a name server by receiving 
        only ATR response without ordinary UDP response. Another measuring approach 
        using ATR is to selectively reply ATR response to specific 
        group of resolvers and record the TCP connections it received during 
        that period. It can help identify vulnerable users and adopt ATR to 
        them.  
        </t> 
-->
        <t>
        [REMOVE BEFORE PUBLICATION] Note that ATR is not just a proposed idea. Some advocates of ATR implemented it based on BIND9 (https://gitlab.isc.org/isc-projects/bind9/merge_requests/158). And Some verify it based on an large-scale experiment platform of APNIC lab  <xref target="APNIC-experiment"/> which is introduced in this memo. </t>

    </section>
    <section title="The ATR mechanism" anchor="ATR_mechanism">

      <t>
        The ATR mechanism is very simple that it involves a ATR module in 
        the responding process of current DNS implementation . As show in 
        the following diagram the ATR module is right after truncation loop 
        if the packet is not going to be fragmented. </t>

      <figure anchor="components" title="High-Level Testbed Components">
        <artwork>
          <![CDATA[
A DNS +-------------+        +-------------+  Normal
query |             | No     |             | response
+------>  Truncation +-------->     ATR     +--------->
      |    loop     |        |    Module   |
      | truncation? |        | truncation? |
      +-------------+        +-------------+
          yes|                   yes|     +-----+
             |                      +-----+timer+-->
             |                            +-----+
             |                      Truncated Response
             +--------------->
              Truncated Response
        ]]>
        </artwork>
      </figure>
      <t>
        The ATR responding process goes as follows:
      </t>
        <t>
          <list style="symbols">

        <t>When an authoritative server receives a query 
        and enters the responding process, it first go through the normal 
        truncation loop to see whether the size of response surpasses the EDNS0 
        payload size. If yes, it ends up with responding a truncated packets. 
        If no, it enters the ATR module.</t>

        <t>In ATR module, similar like truncation loop, the size of response is 
        compared with a value called ATR payload size. If the response of a 
        query is larger than ATR payload size, the server firstly sends the normal 
        response and then coin a truncated response with the same ID of the query. 
        </t>

        <t>The server can reply the coined truncated response in no time. 
        But considering the possible impact of network reordering, it is 
        suggested a timer to delay the second truncated response, for example
        10~50 millisecond which can be configured by local operation.</t>
      </list>
       </t>
       <t>
        Note that the choice of ATR payload size and timer SHOULD be 
        configured locally. And the operational consideration and 
        guidance is discussed in <xref target="ATR-payload-size"/> and 
        <xref target="ATR-timer"/> respectively.
      </t>

        <t>
        There are three typical cases of ATR-unaware resolver behavior 
        when a resolver send query to an ATR server in which the server 
        will generate a large response with fragments:
        </t>
      <t><list style="symbols">
      <t>
        Case 1: a resolver (or sub-resolver) will receive both the large response 
        and a very small truncated response in sequence. It will happily 
        accepts the first response and drop the second one because the transaction 
        is over. 
      </t>
       <t>
        Case 2: In case a fragment is dropped in the middle, the resolver will end up 
        with only receiving the small truncated response. It will retry using TCP 
        in no time. </t>

        <t>
        Case 3: For those (probably 30%*17% of them) who can not speak TCP and 
        sitting behind a firewall stubbornly dropping fragments. Just say good luck to them!
        </t>
        </list></t>

        <t>
        In the case authoritative server truncated all response surpass certain 
        value , for example setting IPv6-edns-size to 1220 octets, ATR will helpful 
        for resolver with TCP capacity, because the resolver still has a fair chance 
        to receive the large response.</t>
        </section>

    <section title= "Experiment on how well ATR works" anchor="APNIC-experiment">

      <t>It is worth of mentioning APNIC report<xref target="How-ATR-Work"/> 
      on "How well does ATR actually work?" done by Geoff Huston and 
      Joao Damas after 00 version of ATR draft. It was reported firstly 
      in IEPG meeting before IETF 101 and then posted in APNIC Blog later.
      </t>

      <t>It is said the test was performed over 55 million endpoints, 
        using an on-line ad distribution network to deliver the test 
        script across the Internet. The result is positive that 
        ATR works! From the end users' perspective, in some 9% of 
        IPv4 cases the use of ATR by the server will improve the 
        speed of resolution of a fragmented UDP response by signaling 
        to the client an immediate switch to TCP to perform a 
        re-query. The IPv6 behavior would improve the resolution 
        times in 15% of cases.</t>

      <t>
        It also analyzed the pros and cons of ATR. On one hand, It is 
        said that ATR certainly looks attractive if the objective is 
        to improve the speed of DNS resolution when passing large DNS 
        responses. And ATR is incrementally deployable in favor of 
        decision made by each server operator. On another hand, ATR 
        also has some negative factors. One issue is adding another DNS 
        DDoS attack vector due to the additional packet sent by ATR, 
        (author's note : very small adding actually.) Another issue is 
        risk of RO by the choice of the delay timer which is discussed 
        fully in <xref target="ATR-timer"/>.    
      </t>

      <t>
        As a conclusion, it is said that "ATR does not 
        completely fix the large response issue. If a resolver cannot 
        receive fragmented UDP responses and cannot use TCP to perform 
        DNS queries, then ATR is not going to help. But where there are 
        issues with IP fragment filtering, ATR can make the inevitable 
        shift of the query to TCP a lot faster than it is today. But it 
        does so at a cost of additional packets and additional DNS 
        functionality". "If a faster DNS service is your highest priority, 
        then ATR is worth considering", said at the end of this report 
      </t>
    </section>

    <section title="Operational considerations">

      <t>
        There are some operational consideration on ATR, 
        such as the parameter of the ATR timer and ATR 
        payload size, and policies on when ATR is triggered 
        to avoid side-effect.</t>

        <section title="ATR timer" anchor="ATR-timer">
        <t>
        As introduced in <xref target="ATR_mechanism"/> ATR timer 
        is a way to avoid the impact of network reordering(RO). 
        The value of the timer is critical, because if the delay is 
        too short, the ATR response may be received earlier than 
        the fragmented response (the first piece), the resolver 
        will fall back to TCP bearing the cost which should 
        have been avoided. If the delay is too long, the client 
        may timeout and retry which negates the incremental benefit 
        of ATR. Generally speaking, the delay of the timer should be 
        "long enough, but not too long".</t>
      <t>
        To the best knowledge of author, the nature of RO is 
        characterized as follows hopefully helping ATR users 
        understand RO and how to operate ATR appropriately in RO 
        context.
      <list style="symbols">
      <t>
        RO is mainly caused by the parallelism in Internet components 
        and links other than network anomaly <xref target="Bennett"/>. 
        It was observed that RO is highly related to the traffic load 
        of Internet components. So RO will long exists as long as the 
        traffic load continue increase and the parallelism is used to 
        enhance network throughput.
      </t>
       <t>
        The probability of RO varies largely depending on the different 
        tests samples. Some work shown RO probability below 2% <xref target="Paxson"/> 
        <xref target="Tinta"/> and another work was above 90% <xref target="Bennett"/>. 
        But it is agreed that RO is site-dependent and path-dependent. 
        It is observed in that when RO happens, it is mostly exhibited 
        consistently in a small percentages of the paths. It is also 
        observed that higher rates smaller packets were more prone to 
        RO because the sending inter-spacing time was small.
      </t>
      <t>
        It was reported that the inter-arrival time of RO varies 
        from a few milliseconds to multiple tens of milliseconds 
        <xref target="Tinta"/>. And the larger the packet the larger 
        the inter-arrival time, since larger packets will take longer 
        to be transmitted.</t>
        </list>
        </t>
        <t>
        Reasonably we can infer that firstly RO should be taken into account 
        because it long exists due to middle Internet components which 
        can not be avoided by end-to-end way. Secondly the mixture of larger 
        and small packets in ATR case will increase the inter-arrival time 
        of RO as well as the its probability. The good news is that the RO is 
        highly site specific and path specific, and persistent which means the ATR operator 
        is able to identify a few sites and paths, setup a tunable timer setting 
        for them, or just put them into a blacklist without replying ATR response.
        </t>

        <t>
        Based on the above analysis it is hard to provide a perfect value of ATR timer 
        for all ATR users due to the diversity of networks. It seems OK to set 
        the timer with a range from ten to hundreds ms, just below the timeout 
        setting of typical resolver. Is suggested that a decision should be made as 
        operator-specific according to the statistic of the RTT of their users. 
        Some measurement shown <xref target="Brownlee"/><xref target="Liang"/> 
        the mean of response time is below 50 ms for the sites with lots of 
        anycast instance like L-root, .com and .net name servers. For that sites, 
        delay less than 50 ms is appropriate.
        </t>
        </section>

        <section title="ATR payload size" anchor="ATR-payload-size">

        <t> 
          Regarding the operational choice for ATR payload size, there are 
          some good input from APNIC study <xref target="scoring-dns-root"/>on 
          how to react to large DNS payload for authoritative server. The difference 
          in ATR is that ATR focuses on the second response after the ordinary 
          response.
        </t>

        <t>
          For IPv4 DNS server, it is suggested the study that do not 
          truncate and fragment IPv4 UDP response with a payload up to 
          1472 octets which is Ethernet MTU(1500) minus the sum of IPv4 header(20) 
          and UDP header(8). The reason is to avoid gratuitously 
          fragmenting outbound packets and TCP fallback at the source. </t>
        <t>
          In the case of ATR, the first ordinary response is emitted 
          without knowing it be to fragmented or not on the path. 
          If a large value is set up to 1472 octets, payload size between 
          512 octets and the large value size will probably get fragmented 
          by aggressive firewalls which leads losing the benefit of ATR. 
          If ATR payload size set exactly 512 octets, in most of case ATR 
          response and the single unfragmented packets are under a race at 
          the risk of RO. </t>
        <t>
          Given IPv4 fragmentation issue is not so serious compared to IPv6, 
          it is suggested in this memo to set ATR payload size 1472 octets 
          which means ATR only fit large DNS response larger than 1500 octets in IPv4. 
        </t>

        <t>
          For IPv6 DNS server, similar to IPv4, the APNIC study is suggested 
          that do not truncate IPv6 UDP packets with a payload up to 1,452 
          octets which is Ethernet MTU(1500) minus the sum of IPv6 header(40) 
          and UDP header(8). 1452 octets is chosen to avoid TCP fallback in 
          the context that most TCP MSS in the root server is not set probably 
          at that time.   
        </t>
         
        <t>
          In the case of ATR considering the second truncated response, a smaller 
          size: 1232 octets, which is IPv6 MTU for most network devices(1280) 
          minus the sum of IPv6 header(40) and UDP header(8), should be chosen as 
          ATR payload size to trigger necessary TCP fallback. As a complementary 
          requirement with ATR, the TCP MSS should be set 1220 octets to avoid 
          Packet Too Big ICMP message as suggested in the APNIC study. 
        </t>

        <t>
          In short, it is recommended that in IPv4 ATR payload size SHOULD be 
          1472 octets, and in IPv6 the value SHOULD be 1232 octets. 
        </t>

        </section>

        <section title="Less aggressiveness of ATR">
        <t>
        There is a concern ATR sends TC=1 response too aggressively 
        especially in the beginning of adoption. ATR can be implemented 
        as an optional and configurable feature at the disposal 
        of authoritative server operator. One of the idea to mitigate this 
        aggressiveness, ATR may respond TC=1 responses at a low possibility, 
        such as 10%.  </t>
 
        <t>
        Another way is to reply ATR response selectively. It is 
        observed that RO and IPv6 fragmentation issues are path specific and 
        persistent due to the Internet components and middle box. So it is 
        reasonable to keep a ATR "whitelist" by counting the retries and 
        recording the IP destination address of that large response causing 
        many retires. ATR only acts to those queries from the IP address in 
        the white list.
        </t>
        </section>
        
    </section>

  <section title="Security Considerations">
    <t>
    There may be concerns on DDoS attack problem due to the fact that the 
    ATR introduces multiple responses from authoritative server. The extra 
    packet is pretty small. In the worst case, it's 50% more packets and they 
    are small</t>

    <t>DNS cookies <xref target="RFC7873" /> and RRL on authoritative may be possible solutions</t>

    <t>
       

    </t>

  </section>

    <section title="IANA considerations">

    <t>No IANA considerations for this memo</t>

    </section>

   <section title="Acknowledgments">
    <t>
    Many thanks to reviewers and their comments. Geoff Huston 
    and Joao Damas did a testing on the question "How well does ATR actually work?". 
    Alexander Dupuy proposed the idea to distinguish ATR responses 
    from normal ones. Akira Kato contributed ideas on operational consideration. 
    Shane Kerr help author with the security consideration. Stephane Bortzmeyer gave thought of happyeyeballs on resolver side. </t> 

    <t>
    Acknowledgments are also give to Mukund Sivaraman, Evan Hunt and Mark Andrews 
    who implement it and maintained it in a brunch in BIND9 code base. 
    </t>
  </section> <!-- Acknowledgments -->
  </middle>

  <back>

    <references title="References">
      &RFC1035; &RFC6891;&RFC7872;&RFC7873;
      &I-D.taylor-v6ops-fragdrop;

     <reference anchor="IPv6-frag-DNS" target="https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns">
            <front>
                <title>Dealing with IPv6 fragmentation in the DNS</title>
                <author fullname= "Goeff Huston">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="2017" month="August" day="22"/>
            </front>
     </reference>  
          <reference anchor="Paxson" target="https://cseweb.ucsd.edu/classes/fa01/cse222/papers/paxson-e2e-packets-sigcomm97.pdf">
            <front>
                <title>End-to-End Internet Packet Dynamics</title>
                <author fullname= "Vern Paxson">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="1999" month="August" day="22"/>
            </front>
     </reference>  

          <reference anchor="Tinta" target="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35247.pdf">
            <front>
                <title>Characterizing End-to-End Packet Reordering with UDP Traffic</title>
                <author fullname= "Sandra P. Tinta">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="2009" month="August" day="18"/>
            </front>
     </reference>  
      <reference anchor="Bennett" target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.461.7629&amp;rep=rep1&amp;type=pdf">
            <front>
                <title>Packet Reordering is Not Pathological Network Behavior</title>
                <author fullname= "Jon C. R. Bennett">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="1999" month="December"/>
            </front>
     </reference>
           <reference anchor="Liang" target="https://netsec.ccert.edu.cn/duanhx/files/2013/02/latency.pdf">
            <front>
                <title>Measuring Query Latency of Top Level DNS Servers</title>
                <author fullname= "Jinjin Liang">
                  <organization>Tsinghua University</organization>
                  <address></address>
                </author>
                <date year="2013" month="February"/>
            </front>
     </reference>  
           <reference anchor="Brownlee" target="http://www.caida.org/publications/papers/2002/nsrtd/nsrtd.pdf">
            <front>
                <title>Response time distributions for global name servers</title>
                <author fullname= "Nevil Brownlee">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="2002" />
            </front>
     </reference>    
      <reference anchor="Not-speak-TCP" target="https://labs.ripe.net/Members/gih/a-question-of-dns-protocols">
            <front>
                <title>A Question of DNS Protocols</title>
                <author fullname= "Goeff Huston">
                  <organization></organization>
                  <address></address>
                </author>
                <date year="2013" month="August" day="28"/>
            </front>
     </reference>  
    
      <reference anchor="ATR-Github" target="https://github.com/songlinjian/DNS_ATR">
       <front>
        <title>XML source file and test script of DNS ATR</title>
       <author>
       <organization></organization>
        </author>
        <date year="2017" month="September" day="5"></date>
      </front>
    </reference>

      <reference anchor="How-ATR-Work" target="https://blog.apnic.net/2018/04/16/how-well-does-atr-actually-work/">
            <front>
                <title>How well does ATR actually work?</title>
                <author fullname= "Goeff Huston">
                  <organization>APNIC</organization>
                  <address></address>
                </author>
                <date year="2018" month="April" day="16"/>
            </front>
     </reference>  

       <reference anchor="scoring-dns-root" target="https://blog.apnic.net/2016/11/15/scoring-dns-root-server-system/">
            <front>
                <title>Scoring the DNS Root Server System</title>
                <author fullname= "Goeff Huston">
                  <organization>APNIC</organization>
                  <address></address>
                </author>
                <date year="2016" month="November" day="15"/>
            </front>
     </reference>  

     </references>

<!--
    <section title="How well does ATR actually work?">

      <t>It is worth of mentioning APNIC report<xref target="How-ATR-Work"/> 
      on "How well does ATR actually work?" done by Geoff Huston and 
      Joao Damas after 00 version of ATR draft. It was reported firstly 
      in IEPG meeting before IETF 101 and then posted in APNIC Blog later.
      </t>

      <t>It is said the test was performed over 55 million endpoints, 
        using an on-line ad distribution network to deliver the test 
        script across the Internet. The result is positive that 
        ATR works! From the end users' perspective, in some 9% of 
        IPv4 cases the use of ATR by the server will improve the 
        speed of resolution of a fragmented UDP response by signaling 
        to the client an immediate switch to TCP to perform a 
        re-query. The IPv6 behavior would improve the resolution 
        times in 15% of cases.</t>

      <t>
        It also analyzed the pros and cons of ATR. On one hand, It is 
        said that ATR certainly looks attractive if the objective is 
        to improve the speed of DNS resolution when passing large DNS 
        responses. And ATR is incrementally deployable in favor of 
        decision made by each server operator. On another hand, ATR 
        also has some negative factors. One issue is adding another DNS 
        DDoS attack vector due to the additional packet sent by ATR, 
        (author's note : very small adding actually.) Another issue is 
        risk of RO by the choice of the delay timer which is discussed 
        fully in <xref target="ATR-timer"/>.    
      </t>

      <t>
        As a conclusion, it is said that "ATR does not 
        completely fix the large response issue. If a resolver cannot 
        receive fragmented UDP responses and cannot use TCP to perform 
        DNS queries, then ATR is not going to help. But where there are 
        issues with IP fragment filtering, ATR can make the inevitable 
        shift of the query to TCP a lot faster than it is today. But it 
        does so at a cost of additional packets and additional DNS 
        functionality". "If a faster DNS service is your highest priority, 
        then ATR is worth considering", said at the end of this report 
      </t>
    
      <t>
        This test and report definitely made ATR more shiny attracting 
        attention in the community. But it is found that there 
        are still something unknown on "How well does ATR 
        actually work". Firstly the test only counts the "success" 
        case ("failure" otherwise) in which the "success" for large UDP 
        case can be achieved by normal retries. The latency of that retries 
        may reduced by ATR is not taken into account. </t>
      <t>
        Secondly more analysis could be done in future to compare ATR with TCP. 
        From the failure rate of users, we see ATR and TCP have similar performance
         (same for IPv4, and only 2% difference in IPv6). But there are resolvers who 
         are able to receive the fragments more sooner in ATR case , but 
         they fall back to TCP in TCP case. If not misunderstood, 
        the two unknown parts underestimates the benefit of ATR in terms 
        of speed of response.
      </t>
      <t>
        The third unknown part is about the ATR timer and RO impact. In APNIC 
        test, 10 ms was adopted as the delay of ATR timer according to 00 version 
        of this draft. Different delay of ATR timer may not change the key result 
        on gains of ATR (9% for IPv4 and 15% for IPv6). But the cost of RO 
        is not measured. In the majority cases ATR is not needed, say 
        87% in IPv4, and 79% in IPv6. So it overestimate ATR in this regards 
        if RO cost is not taken into account. 
      </t>

    </section>
-->  
        <section title="Considerations on Resolver awareness of ATR" anchor="Resolver-Consideration">
    
    <t>
       ATR proposed in this memo is a server-side function which 
       requires no change in resolver, so it is not required that 
       resolver MUST recognized ATR and react accordingly. But it may 
       helpful for some cases where a resolver is able to recognized ATR 
       response, for example by checking the large edns0 payload size 
       and TrunCation bit. 
    </t>
    <t>
       One case is use ATR is used as troubleshooting tool by which 
        resolver operators are able to flag problematic name servers. 
        The resolver operators is enable to log cases where ATR 
        responses is received without a (reassembled) UDP response to a 
        query. In the case of receiving a ATR, RDNS can choose to restrict 
        maximum EDNS to a lower value than the default 4096 that currently 
        used. 
    </t>

    <t>
       Another case is that when receiving a ATR response a ATR-aware 
       resolver can adopt a "happyeyeballs" strategy by opening a separate 
       transaction sending the query via TCP instead of falling back to 
       TCP and closing the original UDP transaction. Listen to port 53 
       on both TCP and UDP port 53 will enhance the availability 
       and reduce the latency. It will add more tolerance to network 
       reordering issue as well. However, it should be taken into account about 
       the balance of resolver's resource. Less priority should be given  
       to that function when the resolver is "busy".</t>

      <t>Note that a normal truncated response may be mistaken as ATR 
        response when authoritative server truncated responses once the 
        packets size surpasses a certain value.
     </t>

    <!--
      <t>
       Another case is that a ATR-aware resolver is able to indicate 
       its support for ATR to prudent servers who do not reply ATR 
       response to every query and resolver. If that requirement is 
       valid, it is possible for resolver to re-use the AT bit defined 
       in this memo as a indication asking ATR response from the server. 
     </t>
   -->
     <t>  
       However resolver use case of ATR is currently outside of the scope of 
       server-ATR proposal. It needs further discussion. 
      </t>
    </section>

     <section title="Revision history of this document">
        <section title="draft-song-atr-large-resp-01">

        <t>After receiving reviews and comments, changes of 01 version are shown as belows:  
        <list style="symbols">
        <t>Rewrite introduction and add another goal of ATR as a measuring tool;</t>
        <t>Add section 3 indicating a ATR response. An bit in the EDNS0 OPT header is defined as a indicator of ATR response. The flag bit is called "ATR Response" (AT) bit;</t>
        <t>Add Section 4 Operation considerations, which discuss ATR timer , ATR payload size, and less aggressiveness of ATR;</t>
        <t>Add IANA consideration to register the AT bit;</t>
        <t>Add section 7 Acknowledgments;</t>
        <t>Append a list of references regarding Network reordering, and APNIC's study on IPv6 and DNS;</t>
        <t>Add Appendix A, An introduce of APNIC testing work and author's comments;</t>
        <t>Appendix B. Considerations on Resolver awareness of ATR;</t>
        <t>Change the category="std" . It is said in RFC6891 IETF Standards Action is required for assignments of new EDNS(0) flags. So the draft should be categorized as standard track if registering AT bit is desired in this document.</t>
        </list></t>

          <t>Change history is also available in the public GitHub
            repository where this document is maintained: <eref
            target="https://github.com/songlinjian/DNS_ATR"/>.</t>
        </section>
        <section title="draft-song-atr-large-resp-02">
        
        <t>Changes in 02 version of ATR draft:</t>
        <t>
        <list style="symbols">
        <t>Remove the section of introduction of AT bit as well as requirement of IANA registration of that bit;</t>
        <t>Change the category of this document to experimental and move the introduction of APNIC's experiment from Appendix A to section 3;</t>
        <t>Add IANA consideration to register the AT bit;</t>
        <t>Add more names in Acknowledgments part after IETF102;</t>
        </list></t>
        </section>
     </section>
  </back>
</rfc>