The paper is titled "A first look at DNS over QUIC", and I very much
would like to see the second look. The first look contains very
interesting reporting on the usage of DNS over QUIC, serious efforts
made to find out which servers already support a version of DoQ. That
part is great, but the actual measurements are very much affected by
limitations of the test client and bugs in early implementations.
Mike Kosec mentioned on Twitter that "We do not use TLS session
resumption." (https://twitter.com/MikeKosek/status/1491351241695592454).
This are a very serious limitations of the test client. The performance
of DNS over QUIC depend a lot on the support of 0-RTT and, failing that,
session resumption. The test client performs two queries at short
intervals: a first one to "prime the cache", and a second one a few
seconds later. If the client supported 0RTT, the second query would
execute in a single round-trip. Not supporting 0RTT implies that the
second query will require at least two round-trips. Also not supporting
session resumption implies that the server first flight will require a
couple of kilobytes of overhead, instead of a few hundred bytes. These
limitations are not mentioned in the "methodology" section of the paper,
and I think they should be. They are mentioned in the conclusion, in
which the authors "plan to further evaluate DoQ by using previously
establishedsessions for subsequent queries, as well asTLS 1.3 0-RTT
between sessions in afuture study". Please do that!
Mike also wrote on Twitter that "We get no RETRY packet in the second
session, so the token is accepted by the server. However, we are still
bound by the anti-amplification limit, as the server stops sending data
(the server cert)." Both issues, the retry and the amplification limit,
can be traced to deployment choices and software issues in some of the
early implementations of DNS over QUIC. Servers do not always need to
issue a Retry packet on every first connection from a new IP address --
the amplification limits are designed to make that optional. Servers
definitely don't need to enforce the amplification limits if they
receive a valid token in the initial packets, that looks very much like
a bug. But then, buggy servers are a fact of life, and measurement
studies like those described in the paper are a good way to find out the
what deployed servers do: how many enforces Retry on the first
connection, how many support 0-RTT or Session Resumption, how many
enforce amplification limits despite a valid new token? It would be
great if the second version of this measurement paper reported on that!
-- Christian Huitema
On 2/8/2022 10:03 AM, Christian Huitema wrote:
The results are indeed interesting. And also surprising. It would be
nice to tease out what is inherent to the specification, what is
caused by choices or bugs in the early implementation, and what may be
caused by the testing process.
The paper points out the effect of amplification attack prevention.
Amplification prevention is of course a good thing. Even Do53
implementations should do a version of it, using DNS Cookies. But
clearly, it can impede performance. I checked my implementation of
QUIC, and it does not enforce amplification prevention if the initial
packet carried a valid new token -- but it would if the source IP
address of the initial packet did not match the IP address to which
the new token was sent. We would not want a botnet to use a valid new
token! Could you verify that the IP source address used in your
measurements remains constant?
You trace amplification prevention kicking in to the large size of TLS
certificates sent by servers. I checked in my implementation of QUIC
and found that when a session is resumed, the server response does not
include a CERT extension. There is no need to send the certificate
again, it was already verified by the client in the session being
removed. In resumption traces, the Initial packets and the Handshake
packet sent by the server are both a few hundred bytes, and fit in a
single UDP packet. Are the early server implementations are buggy? Or
does the test client wait too long before resuming the connection, so
the server finds that the ticket has expires and goes through a full
connection setup?
The paper mentions that most first connections experience a "retry".
That seems like a deployment choice at the server. The amplification
protections in theory make this process unnecessary. It would be
interesting to know why servers chose to do that for all connections.
Are they under constant DOS attacks?
So many questions...
-- Christian Huitema
On 2/8/2022 3:05 AM, James wrote:
Thanks for paper, and your results are very interesting.
One area that would be interesting to focus on is HTTP versions, I
would expect the performance characteristics between them to be
notably different, and it appears your client supports HTTP/2, but I
can't see if you distinguish the version in your dataset or if you
are only sending the HTTP/2 ALPN. More importantly for future work
would be comparing DoH3 with DoQ - this is something folk have been
thinking about[0] and there are very few resolvers that I'm aware
that offer it but may answer questions around the real-world impact
of HTTP overheads.
- J
0:
https://mailarchive.ietf.org/arch/msg/quic/roPNRcYwKpHBaYjOuHxzqGTEWp0/
On 8 Feb 2022, at 11:14, Mike Kosek <ko...@in.tum.de> wrote:
Dear dprive WG,
Over the past 6 months, we measured the adoption of DNS over QUIC
(and the different drafts) on resolvers worldwide, and evaluated
their performance in comparison to DoUDP, DoTCP, DoT as well as DoH.
The paper recently got accepted at PAM 2022, and might be of
interest to the WG:
One to Rule them All? A First Look at DNS over QUIC
https://arxiv.org/abs/2202.02987
Please find the abstract below this email. We also published the raw
data of our measurements on github:
https://github.com/kosekmi/2022-pam-dns-over-quic
While we plan to build up on this work in future studies, we are
happy to get feedback of what might be of interest to the WG -
please get back to us with any feedback or suggestions!
Best,
Mike, Viet, Malte, Vaibhav
TUM Technical University of Munich
---- Abstract ----
The DNS is one of the most crucial parts of the Internet. Since the
original DNS specifications defined UDP and TCP as the underlying
transport protocols, DNS queries are inherently unencrypted, making
them vulnerable to eavesdropping and on-path manipulations.
Consequently, concerns about DNS privacy have gained attention in
recent years, which resulted in the introduction of the encrypted
protocols DNS over TLS (DoT) and DNS over HTTPS (DoH). Although
these protocols address the key issues of adding privacy to the DNS,
they are inherently restrained by their underlying transport
protocols, which are at strife with, e.g., IP fragmentation or
multi-RTT handshakes - challenges which are addressed by QUIC. As
such, the recent addition of DNS over QUIC (DoQ) promises to improve
upon the established DNS protocols. However, no studies focusing on
DoQ, its adoption, or its response times exist to this date - a gap
we close with our study. Our active measurements show a slowly but
steadi
l
y increasing adoption of DoQ and reveal a high week-over-week
fluctuation, which reflects the ongoing development process: As DoQ
is still in standardization, implementations and services undergo
rapid changes. Analyzing the response times of DoQ, we find that
roughly 40% of measurements show considerably higher handshake times
than expected, which traces back to the enforcement of the traffic
amplification limit despite successful validation of the client's
address. However, DoQ already outperforms DoT as well as DoH, which
makes it the best choice for encrypted DNS to date.
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
