Subject: Re: [dns-privacy] updated tech report about DNS-over-TCP and DNS-over-TLS

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 7 Aug 2014 14:26:59 +0800

So long the paper is and really excellent work it is. From this paper, it seems that the performance of TCP-based DNS is acceptable compared with UDP-based DNS. But DNS operators may still worry the performance of anycast which is used in root and many TLD domains if UDP is widely replaced by TCP. Do you have any plans on measuring the performance of anycast in TCP scenario?

Guangqing Deng
CNNIC 
 
From: John Heidemann
Date: 2014-07-15 12:46
To: dns-privacy; dnsop
Subject: [dns-privacy] updated tech report about DNS-over-TCP and DNS-over-TLS
 
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
 
_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Aug 2014 09:33:03 -0400

Hi Guangqing,

On 7 August 2014 at 2:27:37, Guangqing Deng ([email-masked]) wrote:

> So long the paper is and really excellent work it is. From this paper, it seems that the  
> performance of TCP-based DNS is acceptable compared with UDP-based DNS. But DNS operators  
> may still worry the performance of anycast which is used in root and many TLD domains if  
> UDP is widely replaced by TCP. Do you have any plans on measuring the performance of anycast  
> in TCP scenario?

The general concern with non-stateless exchanges between a unicast host and an anycast host is that the routing system between the two may exhibit oscillations that cause different anycast hosts to receive different packets associated with the same transaction. This is more of a concern the longer the transaction, and the more turbulent the routing between the hosts concerned. (In general, I have yet to see a significant problem with half-open connections on anycast DNS servers with short-held TCP sessions.)

In RFC 4786 we said:

   When a service is anycast between two or more nodes, the routing
   system makes the node selection decision on behalf of a client.
   Since it is usually a requirement that a single client-server
   interaction is carried out between a client and the same server node
   for the duration of the transaction, it follows that the routing
   system's node selection decision ought to be stable for substantially
   longer than the expected transaction time, if the service is to be
   provided reliably.

   Some services have very short transaction times, and may even be
   carried out using a single packet request and a single packet reply
   (e.g., DNS transactions over UDP transport).  Other services involve
   far longer-lived transactions (e.g., bulk file downloads and audio-
   visual media streaming).

   Services may be anycast within very predictable routing systems,
   which can remain stable for long periods of time (e.g., anycast
   within a well-managed and topologically-simple IGP, where node
   selection changes only occur as a response to node failures).  Other
   deployments have far less predictable characteristics (see
   Section 4.4.7).

   The stability of the routing system, together with the transaction
   time of the service, should be carefully compared when deciding
   whether a service is suitable for distribution using anycast.  In
   some cases, for new protocols, it may be practical to split large
   transactions into an initialisation phase that is handled by anycast
   servers, and a sustained phase that is provided by non-anycast
   servers, perhaps chosen during the initialisation phase.

One thing we proposed in draft-wouters-edns-tcp-keepalive was:

   Changes in network topology between clients and anycast servers may
   cause disruption to TCP sessions making use of edns-tcp-keepalive
   more often than with TCP sessions that omit it, since the TCP
   sessions are expected to be longer-lived.  Anycast servers MAY make
   use of TCP multipath [RFC6824] to anchor the server side of the TCP
   connection to an unambiguously-unicast address in order to avoid
   disruption due to topology changes.

This was a bit of a throwaway comment and deserves greater thought, but it's an example of how we could shoe-horn an initialisation phase into a long-lived (TCP) DNS transaction.

Joe

---

From: John Heidemann <[email-masked]>
Date: Thu, 07 Aug 2014 09:42:09 -0700

On Thu, 07 Aug 2014 09:33:03 -0400, Joe Abley wrote: 
>...

We talk about anycast in Appendix H.1 of the tech report, and observe
that anycast is used for HTTP CDNs like Edgecast (see cite [13]).
Patrick Gilmore suggested Cloudflare and Cachefly also do this.

Since HTTP connections are already long lived, I think this suggests
that potential T-DNS connections that last tens of seconds will not be
horrible.

The important thing to think about are the implications of an anycast
route change during a live connection.  With TLS the connection will be
torn down, since the new server will not have the same shared secret.
Clients already must recover TCP connections that are unexpectedly torn
down, so this is just another case that requires restart.

Will restart happen so often performance is impossibly bad?  I think 3
commercial HTTP CDNs would suggest not!  We have some data about anycast
and the roots (see Fan et al "Evaluating Anycast in the Domain Name
System", INFOCOM 2013)---I'll look if we can reanalyze that data to
characterize anycast stability.

It's also important that when DNS-over-TCP is having trouble because of
anycast route changes, DNS-over-UDP will also be less than happy.  See
Labovitz et al's "Delayed {Internet} Routing Convergence" (SIGCOMM 2000)
for loss rates during route change.  UDP will be MUCH more robust than
TCP because just one request and reply has to get through, but UDP too
will suffer.  Anycast route change is perhaps good time for a client to
try out that secondary nameserver :-)

   -John