Internet DRAFT - draft-song-dnsop-tcp-primingexchange

draft-song-dnsop-tcp-primingexchange







DNSOP Working Group                                              L. Song
Internet-Draft                                Beijing Internet Institute
Intended status: Standards Track                                   D. Ma
Expires: May 30, 2015                                               ZDNS
                                                       November 26, 2014


             Using TCP by Default in Root Priming Exchange
                draft-song-dnsop-tcp-primingexchange-00

Abstract

   DNS payload size limitation constrains operational and policy choice
   for many years.  It is become increasingly notable in IPv6 transition
   and DNSSEC development, specifically during Priming Exchange process.
   Given that the load of priming exchange on the root system is
   relatively low, this memo proposes using TCP by default in Priming
   Exchange between resolver and root server.  This approach is aiming
   to treat Priming Exchange as a special process which brings a little
   change to the current root system and provide solution to the long-
   term problems.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 30, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Song & Ma                 Expires May 30, 2015                  [Page 1]

Internet-Draft             tcp-primingexchange             November 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Operational and policy constraints with Priming Exchange  . .   3
     2.1.  Full AAAA record with Priming Exchange  . . . . . . . . .   3
     2.2.  DNSSEC with Priming Exchange  . . . . . . . . . . . . . .   3
     2.3.  The number of NS server with Priming Exchange . . . . . .   4
   3.  Review of DNS over TCP  . . . . . . . . . . . . . . . . . . .   4
   4.  Requirement of priming exchange over TCP  . . . . . . . . . .   5
   5.  Performance analysis  . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Response time . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Load of system  . . . . . . . . . . . . . . . . . . . . .   6
   6.  Pros and cons . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Pros  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Cons  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Domain Name System is a typical UDP-based protocol which is
   connectionless and following single-packet exchange paradigm.  One
   exchange of DNS, which is important but without fully documented, is
   the Priming Exchange between resolver and root server[Priming-Test].
   In simple terms, priming query is a NS query for root zone (qtype=NS,
   qname='.', qclass=IN).  The traffic caused by priming exchange is
   also called 'ns-for-dot' traffic.

   Due to the maximum DNS message size specified in [RFC1035], all the
   DNS packets including Priming Exchange should fit within 512 octets.
   It becomes an historical and practical hard DNS protocol limit, even
   after EDNS0 [RFC6891] was introduced to mitigate this problem.  It
   bring constraints operational and policy choice for many years, and
   becomes increasingly notable in IPv6 transition and DNSSEC
   development, specifically for the case of Priming Exchange.





Song & Ma                 Expires May 30, 2015                  [Page 2]

Internet-Draft             tcp-primingexchange             November 2014


   Given that the load of Priming Exchange on the root system is
   relatively low [TLD-Statues-K] [QTYPE-L], this memo proposes using
   TCP by default in Priming Exchange between resolver and root server.
   This approach is aiming to treat Priming Exchange as a special
   process which brings a little change to the current root system and
   provide solution to the long-term problems.

   Note that this memo is neither protocol novelty nor specification of
   DNS over TCP which are discussed by [I-D.dickinson-dnsop-5966-bis]
   [T-DNS].  This memo is to analyze and argue the possibility of using
   TCP as a default transmission protocol with a small price to pay for
   it on the occasion.

2.  Operational and policy constraints with Priming Exchange

2.1.  Full AAAA record with Priming Exchange

   To the authors' knowledge, the concept "priming" was first defined in
   ICANN SSAC/RSSAC serial work [SAC016], [SAC017] and [SAC018]when
   people consider adding IPv6 AAAA Records to Priming Exchange.  For
   performance and resiliency purpose, there are two major requirements:
   1) include all A records for all thirteen root servers, 2) avoid the
   burden of TCP.  So the final operational decision is to return all A/
   AAAA record in additional section of priming reply, but with special
   sequencing of records in which type A records precede type AAAA
   records.

   Based on that decision, the AAAA records will be incomplete in small
   packets (<512B) given that truncation of the additional data section
   might not be signaled for additional section data (Appendix B of
   [RFC4472]).  Still to date, no more than two AAAA resource records
   can be included in the Priming response in the absence of EDNS0
   support.  This operational constraint compromise the resiliency of
   Root system for IPv6 users, especially under the consideration of
   IPv6-only deployment [I-D.song-sunset4-ipv6only-dns].

2.2.  DNSSEC with Priming Exchange

   The data in the additional section of a DNS response (also called
   referral response) is viewed as "courtesy" and optional.  So it is
   not required to be signed in Priming response and validated when a
   resolver receive it.  In the case of Priming Exchange, resolver only
   validates the NS RRSet but without validating the corresponding A and
   AAAA RRSets.

   For the performance consideration, most of time the resolver will not
   issue A or AAAA query for root servers.  So there is a risk that A/
   AAAA RRSet of root server is polluted with another set of data or



Song & Ma                 Expires May 30, 2015                  [Page 3]

Internet-Draft             tcp-primingexchange             November 2014


   invalid data.  It is not reasonable.  This issue is also addressed in
   [I-D.ietf-dnsop-resolver-priming] which gives up the possibility of
   DNSSEC with Priming Exchange since the requirement of DNS payload
   size even surpasses the largest feasible EDNS0 buffer size.

2.3.  The number of NS server with Priming Exchange

   Still due to the DNS payload limitation, the number of NS server of
   root zone is strictly limited.  The number 13 is never changed since
   1997 when the last Root letter "M" was assigned.  This fixed number
   of root NS servers introduces a topic constantly incurring arguments
   and misunderstanding (Maybe the rarity means the value, who knows).
   Some discussion and proposal [I-D.lee-dnsop-scalingroot] try to
   extended 13 to millions for pervasive distribution of Root zone.

   From the technical point of view, the number of NS server should be
   treated as a parameter of the root system, rather than a constant
   making the root server as some kind of rare resource of Internet
   which only incurs constant disputes with Internet governance issue.
   With TCP enhancement in Priming Exchange, the root zone operator is
   able to decide and control the value of this parameter based on
   practical and technical requirements.  It is also promising that the
   non-technical disputes with Internet governance will cease from this
   very topic.

   <<subsection 2.3 may be a little controversial and out of the scope
   of IETF discussion.  But it fit the topic of policy constraint
   brought out by technical issues.  This text may be amended largely
   according to the feedback of the community. >>

3.  Review of DNS over TCP

   The Domain Name System is a typical UDP-based protocol which is
   connectionless.  TCP is also designed in the original DNS
   specification [RFC1035] but it is only used in zone transfer and act
   as a backup when DNS packet gets truncated with large payload
   [RFC1123].  In addition, DNS over TCP is commonly viewed as expensive
   and not optimal compared to connectionless UDP.  This "community
   consensus" and operational practice are held since early days of DNS.

   Today the DNS system based on UDP has run into troubles in privacy,
   security and constraints both on policy and operation choices.  The
   limitation of pay load size for example, is one of most notable
   issues.  Besides the long-tail adoption, any mechanism supporting
   larger UDP packets such as EDNS0 will cause unexpected risk of IP-
   fragmentation [Fragment-Problem][Fragment-Poisonous].  That issue
   becomes increasingly notable concerning DNSSECwith key rollover
   process which involves much larger response packets.



Song & Ma                 Expires May 30, 2015                  [Page 4]

Internet-Draft             tcp-primingexchange             November 2014


   As to the very issue, some discussions focus on the problem of 512B
   limitation and the firewall/middle-box misbehavior.  Some propose the
   way to work around [I-D.ietf-dnsop-respsize].  This memo benefits
   mainly from the discussion of DNS over TCP [I-D.dickinson-dnsop-5966-
   bis][I-D.hzhwm-dprive-start-tls-for-dns][Question-DNS], especially
   from the extensive work of [T-DNS].  In short, they all identify that
   TCP is an extant part of current DNS implementation and has its
   inherent property overcoming the issue brought about by DNS over UDP.

   The author of this memo is the advocate for DNS over TCP, especially
   on the very occasions when it is needed.  In this memo, the priming
   exchange is identified as one of these occasions.

4.  Requirement of priming exchange over TCP

   The priming exchange and TCP are introduced respectively in the
   previous sections.  In this section some requirements and
   considerations are proposed on how to switch on priming exchange over
   TCP on both sides of resolver and root server.  Note that all the
   following discussion is based on the assumption that the root zone
   operator (ICANN/IANA) decides to adopt TCP in its priming exchange in
   order to break through the constraint explained in section 2

   The requirements for recursive server are:

   1)Be aware that more information with larger payload will be
   introduced into the priming exchange and make sure the TCP function
   of resolver is ok when a resolver issues "ns-for-dot" query to root
   server.

   2)Make a configuration or a necessary patch to the recursive server
   in order to send a priming query on TCP by default.  (The little
   change does not affect other UDP Qtype like A/AAAA/SOA)

   3)Similar to the suggestion of [I-D.ietf-dnsop-resolver-priming], do
   not send and re-send priming query over TCP to root server every
   often.  Considering the TTL of the NS records is currently six days
   (518400 seconds), 3~4 day is a proper setting for the interval of re-
   priming.

   4)Without actions above, be aware of the large possibility of risk
   due to truncated UDP packets or fragmentation.

   The requirements for root server:

   1)Be aware any changes may be introduced to Root zone and priming
   exchange, if the root zone operator (ICANN/IANA) decides to adopt
   priming exchange over TCP proposal.



Song & Ma                 Expires May 30, 2015                  [Page 5]

Internet-Draft             tcp-primingexchange             November 2014


   2)Given the rise of TCP connections from priming exchange, proper
   setting on maximum concurrent TCP connections should be carefully
   considered.  This setting will affect the response time of priming
   exchange over TCP [RIPE-TCP-Test].  Now common setting of maximum
   concurrent TCP connections is 10-100.

   <<This part is the initial consideration and loosely composed on the
   requirement of how to switch on priming exchange over TCP on both
   resolver and root server.  It may amended largely after receiving
   comments from the community.>>

5.  Performance analysis

   There are mainly two performance concerns when TCP is introduced by
   default in priming exchange: response time and load of root system.

5.1.  Response time

   There was a test in 2012 by RIPE NCC comparing TCP and UDP Response
   times of DNS root servers [RIPE-TCP-Test], which demonstrated that
   the response time of TCP query is twice or three times of UDP
   response time.  Although the measurements was done on the round-trip
   (RT) values of DNS queries for SOA, it is valid for estimate of
   priming response time.

   There are also some discussions and proposal of DNS over TCP with
   Fast Open technology [I-D.ietf-tcpm-fastopen] which will largely
   reduce end-to-end TCP latency [T-DNS].

   Because the frequency of priming exchange is not much high, the
   resolver has plenty of time to re-priming exchange with Root in any
   case whenever it boots up or its TTL timeout.  So it is convincible
   for the author of this memo that twice or three times latency is
   endurable in the very case of priming exchange.

5.2.  Load of system

   According to the monitoring system and tools developed by root server
   operators [TLD-Statues-K] [QTYPE-L], the information of priming load
   of Root server is public in a real-time manner.  At the time of this
   memo drafted, the average load of "ns-for-dot" query is less than 1k
   qps (out of 30k qps in total) in K-root which is composed of 17
   instances which are sharing the load.  The "ns-for-dot" query load in
   the case of L-root is 1.4k qps (out of 50k qps in total) with 152
   instances sharing the load.  It seems that the load of priming
   exchange traffic is not much high in this regard.





Song & Ma                 Expires May 30, 2015                  [Page 6]

Internet-Draft             tcp-primingexchange             November 2014


   Note that it's necessary and important for the root zone operator to
   conduct a carefully designed test of the impact of introduction of
   TCP into priming exchange in order to detect any latent anomalies.

   <<To be extended, comments are welcome!>>

6.  Pros and cons

6.1.  Pros

   Because TCP is a stream protocol in its nature, there is no longer
   any payload size limitation for DNS transmission.  This property is
   beneficial in following aspects:

   1)Adding full A/AAAA address of Root server in priming response,
   which will enhance the resiliency of Root system for IPv6 users,
   especially under the consideration of IPv6-only deployment
   [I-D.song-sunset4-ipv6only-dns].

   2)DNSSEC validation for priming exchange.  The priming exchange plays
   a key role guiding the traffic to the unique identity system.  There
   is little evidence or argument that priming exchange does not need
   integrity production, given that DNS becomes increasingly the attack
   vector of the Internet.

   3)Making DNS Priming Exchange scale to more extensions and
   applications, especially providing a possibility that a larger range
   of root zone hosts could be employed in a controlled manager
   following the current hierarchical architecture, which offers
   pervasive distribution of root service.

6.2.  Cons

   No change is cost free, even with a little changes in the current
   system.  It should be prudent and fully consider the impact of using
   TCP by default in priming exchange.

   1)Bring unexpected degradation in the performance of root services,
   latency, system load or other aspects which are needed tests in a
   large scale.  This may involve a lot of discussion and argument.

   2)This memo requires recursive name servers be aware of Priming
   Exchange is a special process and the relating mechanism should hence
   be triggered somehow as for software implementations.

   3)There is a concern about the capability of TCP for some resolver.
   Evidence [Question-DNS]show that a significant set of resolver cannot
   operate correctly over TCP even when TCP is required.



Song & Ma                 Expires May 30, 2015                  [Page 7]

Internet-Draft             tcp-primingexchange             November 2014


   4)If there is no enough incentive or push, it will take time for
   resolver to adopt the changes due to the common inertia.  It may
   incur both time and labor expense.

   <<To be extended, comments are welcome!>>

7.  Security Considerations

   TBD

8.  IANA Considerations

   TBD

9.  Acknowledgements

   Special tanks to Professor John Heidemann and his team at USC/ISI.
   Their work on T-DNS is the major source of inspiration for this memo.

10.  References

10.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472, April
              2006.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

10.2.  Informative References

   [Fragment-Poisonous]
              Herzberg, A. and H. Shulman, "Fragmentation Considered
              Poisonous", 2012.

   [Fragment-Problem]
              Kent, C. and J. Mogul, "Fragmentation considered harmful",
              1987.






Song & Ma                 Expires May 30, 2015                  [Page 8]

Internet-Draft             tcp-primingexchange             November 2014


   [I-D.dickinson-dnsop-5966-bis]
              Dickinson, J., Bellis, R., Mankin, A., and D. Wessels,
              "DNS Transport over TCP - Implementation Requirements",
              draft-dickinson-dnsop-5966-bis-00 (work in progress),
              October 2014.

   [I-D.hzhwm-dprive-start-tls-for-dns]
              Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D.
              Wessels, "TLS for DNS: Initiation and Performance
              Considerations", draft-hzhwm-dprive-start-tls-for-dns-00
              (work in progress), October 2014.

   [I-D.ietf-dnsop-resolver-priming]
              Koch, P. and M. Larson, "Initializing a DNS Resolver with
              Priming Queries", draft-ietf-dnsop-resolver-priming-04
              (work in progress), February 2014.

   [I-D.ietf-dnsop-respsize]
              Vixie, P., Kato, A., and J. Abley, "DNS Referral Response
              Size Issues", draft-ietf-dnsop-respsize-15 (work in
              progress), February 2014.

   [I-D.ietf-tcpm-fastopen]
              Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", draft-ietf-tcpm-fastopen-10 (work in
              progress), September 2014.

   [I-D.lee-dnsop-scalingroot]
              Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root
              system?", draft-lee-dnsop-scalingroot-00 (work in
              progress), July 2014.

   [I-D.song-sunset4-ipv6only-dns]
              Song, D., Vixie, P., and D. Ma, "Considerations on
              IPv6-only DNS Development", draft-song-sunset4-ipv6only-
              dns-00 (work in progress), October 2014.

   [Priming-Test]
              RIPE NCC, "A Look at DNS Priming Queries to K-root", 2007,
              <https://labs.ripe.net/Members/emileaben/content-look-dns-
              priming-queries-k-root>.

   [QTYPE-L]  "The "NS for Dot" query for L-root (DNS queries by
              QTYPE)", 2007,
              <http://hedgehog.dns.icann.org/hedgehog/hedgehog.html>.






Song & Ma                 Expires May 30, 2015                  [Page 9]

Internet-Draft             tcp-primingexchange             November 2014


   [Question-DNS]
              Huston, G., "a question of DNS Protocols", September 2013,
              <http://www.potaroo.net/ispcol/2013-09/dnstcp.html>.

   [RIPE-TCP-Test]
              "Comparing TCP and UDP Response Times of DNS Root
              Servers", <https://labs.ripe.net/Members/bwijnen/tcp-udp-
              dns-soa-rt-ratio>.

   [SAC016]   ICANN Security and Stability Advisory Committee, "Testing
              Firewalls for IPv6 and EDNS0 Support", 2007.

   [SAC017]   ICANN Security and Stability Advisory Committee, "Testing
              Recursive Name Servers for IPv6 and EDNS0 Support", 2007.

   [SAC018]   ICANN Security and Stability Advisory Committee,
              "Accommodating IP Version 6 Address Resource Records for
              the Root of the Domain Name System", 2007.

   [T-DNS]    Zhu, L., Hu, Z., and J. Heidemann, "T-DNS: Connection-
              Oriented DNS to Improve Privacy and Security (extended)",
              2007, <http://www.isi.edu/~johnh/PAPERS/Zhu14b.pdf>.

   [TLD-Statues-K]
              "TLD's Status for k-root", 2007,
              <http://k.root-servers.org/statistics/ROOT/tlds.html>.

Authors' Addresses

   Linjian Song
   Beijing Internet Institute
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China

   Email: songlinjian@gmail.com


   Di Ma
   ZDNS
   Beijing
   P. R. China

   Email: madi@zdns.cn







Song & Ma                 Expires May 30, 2015                 [Page 10]