Subject: [DNSOP] updated tech report about DNS-over-TCP and DNS-over-TLS

From: John Heidemann <[email-masked]>
Date: Mon, 14 Jul 2014 21:46:30 -0700

In Feb. 2014, Zi Hu posted about a study about DNS performance over TCP
and TLS.  The context was a proposal to allow DNS to use TLS over TCP,
described in
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-01

We got a lot of input we got from the community (particularly those at
OARC in Warsaw).  We've updated our technical report about DNS-over-TCP
and -TLS based on new work stemming from this feedback.

The new tech report is at
http://www.isi.edu/publications/trpublic/files/tr-693.pdf

This tech report (ISI-TR-2014-693) is a major revision of the prior
technical report (ISI-TR-2014-688). Since that work we have improved our
understanding of the availability of TCP fast open and TLS resumption,
and we have tightened our estimates on memory based on external reports
(section 5.2). This additional information has allowed us to conduct
additional experiments, improve our modeling, and provide a more
accurate view of what is possible today; our estimates of latency and
memory consumption are both lower than in our prior technical report as
a result. We have also added additional information about packet size
limitations (Figure 2), experiments evaluating DNSCrypt/DNSCurve
(section 6.1), analysis of DTLS, and covered a broader range of RTTs in
our experiments. We believe these additions strengthen our central
claims: that connectionless DNS causes multiple problems and that T-DNS
addresses those problems with modest increase in latency and memory
suitable for current hardware.

Discussion with the community and feedback from reviewers raised a
number of associated issues.  These issues were and are summarized in
the body of the paper, but we have placed detailed discussion in
appendices so the body may focus on our our central claims in a moderate
amount of space.  Important additional topics include a detailed
discussion of deployment (Appendix H), an evaluation of TCP-specific
threats and their applicability to T-DNS (Appendix I), a detailed
comparison of the relationship between T-DNS with TLS to DTLS (Appendix
J), and details about supporting experiments.

Here's the abstract of the new technical report for folks who
are unfamiliar with this work:

    DNS is the canonical protocol for connectionless UDP. Yet DNS today
    is challenged by eavesdropping that compromises privacy,
    source-address spoofing that results in denial-of-service (DoS)
    attacks on the server and third parties, injection attacks that
    exploit fragmentation, and size limitations that constrain policy
    and operational choices. We propose T-DNS to address these
    problems. It uses TCP to smoothly support large payloads and to
    mitigate spoofing and amplification for DoS. T-DNS uses
    transport-layer security (TLS) to provide privacy from users to
    their DNS resolvers and optionally to authoritative
    servers. Expectations about DNS suggest connections will balloon
    client latency and overwhelm server with state, but our evaluation
    shows costs are modest: end-to-end latency from TLS to the recursive
    resolver is only about 9% slower when UDP is used to the
    authoritative server, and 22% slower with TCP to the
    authoritative. With diverse traces we show that frequent connection
    reuse is possible (60-95% for stub and recursive resolvers, although
    half that for authoritative servers), and after connection
    establishment, we show TCP and TLS latency is equivalent to
    UDP. With conservative timeouts (20 s at authoritative servers and
    60 s elsewhere) and conservative estimates of connection state
    memory requirements, we show that server memory requirements match
    current hardware: a large recursive resolver may have 24k active
    connections requiring about 3.6 GB additional RAM. We identify the
    key design and implementation decisions needed to minimize overhead:
    query pipelining, out-of-order responses, TLS connection resumption,
    and plausible timeouts.

As before, we are interested in feedback about the work.  We got a
number of questions about deployment issues, and we've tried to speak to
them all.

   -John