I am not sure. There is a fair bit of concentration in the
"authoritative server" market. I see measurements
(https://ithi.research.icann.org/graph-m9.html) showing that Go Daddy,
Cloudflare and AWS have a fairly big share of this market. Add Akamai,
Dyn and Google to the mix, and probably a couple of others, and you get
40% of names served by a small number of servers. For that set, I would
expect that the typical DoQ query will be a session resumption. For
smaller servers, maybe not. And yes, there is an aspect of concentration
there. As if more encryption encouraged more concentration.
-- Christian Huitema
On 2/10/2022 8:07 AM, libor.peltan wrote:
Anyway, do you think that the "typical" recursive-to-authoritative
query in DoQ era will be a session resumption, or a clean new
connection without any chance of 0-RTT or
counter-amplification-limit-token? I agree that both cases could be
explored, but the latter one is still a good start.
/Libor
Dne 09. 02. 22 v 21:35 Christian Huitema napsal(a):
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
