Hi, my name is Austin Hounsell, and I'm a PhD
student at Princeton University.
And I'm going to be presenting some work today
about distributing DNS queries across recursive
resolvers to reduce centralization.
This work was done in collaboration with Paul
Schmidt, Kevin Borgolta, and Nick Feimster.
So essentially, we are presenting the design and
prototype implementation of a refactored
stub resolver that allows for decentralized
encrypted DNS resolution.
We then perform a preliminary evaluation of the
stub resolver's performance and utilize
a real-world dataset to evaluate how various
query distribution strategies, such as random,
round-robin, and hash-based strategies, affect
the amount of queries that are seen by recursive
resolvers.
So as we know, DNS privacy has become a
significant concern within the past few years.
We know that on-path network observers can infer
which websites you are visiting by looking
at your plain text DNS queries.
This kind of interference can occur within
governments or in coffee shop networks, and
etc.
So two protocols have been proposed to encrypt
DNS traffic.
One is DNS over TLS or DOT, and the other is DNS
over HTTPS or DOE.
And we're seeing that increasingly, DOE is being
rolled out by various browser vendors
and other software developers.
In fact, we're seeing that Firefox now uses DOE
as the default DNS protocol for US users,
which you know, encryption is a great thing.
It's great that encrypted DNS is being
increasingly deployed.
However, with it, some users are growing
concerned about ways in which the DNS may be
centralized
into a handful of large operators.
And so we stand to ask, well, is there a way we
can get encrypted DNS resolution while
distributing our queries across multiple
operators instead of centralizing into a small
set?
So first we want to ask, well, is decentralization
even worth doing in the first place?
What might be the theoretical reasons why you may
or may not want to distribute your
queries across multiple resolvers?
However, we're not going to be answering that in
this talk.
Instead we're focusing on, well, is it even
technically possible or feasible to distribute
queries across resolvers?
And what forms could this decentralization take?
So the architecture we have in mind goes
something like this.
In step one, the stub resolver discovers various
upstream resolvers that support DOE along
with the characteristics of these resolvers, such
as geographic location.
The user can specify these requirements such as
within a configuration file.
And then the stub resolver then selects of this
pool, a set of DOE resolvers that match
the characteristics the user desires.
The stub resolver then as it receives queries,
distributes them across multiple resolvers,
according to some user specified strategy.
So it was a random model or a round robin model.
To prototype this, we forked DNS script proxy,
which supports DOE and DNS script.
And we got it support for the hash and round robin
model.
And we also evaluated some existing code that was
within the proxy for random query distribution.
We evaluated the performance of this.
We know that the proxy can not only run on host
devices, but also on routers.
And so maybe it will support shooting queries for
a given strategy for an entire local network.
So this is just a quick example of what it looks
like to use a hash based model that
we implemented.
So for example, if the stub resolver sends out a
query for example.com, or receives it
rather, it may then forward it to Cloudflare's
upstream DOE resolver based on hashing of
the second level domain name.
For images.example.com, it would also get hashed
to Cloudflare's resolver because it
shares the same second level domain name with
example.com.
Similarly, New York Times might get mapped to
Google.
And then if the client queries it again, it gets
mapped to Google once again, same domain
name, and then the Washington Post goes to Quad9.
So we're seeing that the DNS queries are no
longer just going to a single DOE resolver,
but being distributed across multiple of them.
Similarly, the round robin model behaves as you
might expect.
First query goes to the first resolver, second
query goes to the second resolver, third
to the third, and so on and so forth.
And lastly, in the random model also might behave
as you might expect.
The queries go to various resolvers without a
particular order.
So we wanted to evaluate these strategies and see
what's the effect of a stub resolver
that implements these strategies on both page
load times, CD and localization, and the
percentage
of unique domain names that are seen by various
resolvers from each client.
So we're going to be answering these questions in
turn.
So first we turn to CD and localization, right?
And what we're particularly concerned about here
is what is the effect of using various
recursive resolvers on how far away the CDN
content is that you resolve, right?
So if we look at this figure, which is a CDF of
TCP and TLS setup times for CDN content,
we can read the legend in this way.
If you look at the Cloudflare-Google line, what
we're seeing there is that these are
the, this is the CDF of TCP and TLS setup times
when you use Cloudflare's DOE resolver
to resolve Google CDN content.
And essentially what we're seeing here is that
there really isn't too much of a difference
that's being made in terms of using one
particular resolver to host, to resolve CDN
content.
In other words, you could use Cloudflare's
resolver and get Google content just fine,
just as you can use Google's resolver to get
Cloudflare content just fine.
Similarly in terms of page load times, we're
seeing that no single strategy seems to have
the best or worst effect on performance for page
load times.
So these are measurements that were taken from
four Amazon EC2 vantage points in which
we perform page loads using a instrumented
instance of Firefox with Selenium in a headless
browser.
And we perform measurements with three different
query distribution strategies.
And so what we're seeing is that no single
resolver, once again, or rather no single
model seems to perform the best or the worst
across different vantage points.
We're seeing slightly different effects on page
load times, but everything looks about
roughly the same.
And then when you turn to a comparison of using a
single resolver for all your queries,
we're seeing a similar story where each resolver
seems to perform somewhat similarly in terms
of its effect on page load times, whereas in
certain vantage points, you're seeing maybe
a slightly higher effect than in other ones.
So for example, if you look at Oregon, you might
see that there's a much more pronounced
difference in page load times with certain resolvers.
And then lastly, we look at the effect of how
many unique domain names are seen by DNS
resolvers whenever you use query distribution
strategies.
So we utilize a real world dataset from Allman et
al of 100 homes in Cleveland, Ohio that
were connected to a fiber to the home network.
We utilize this traffic to perform our query
distribution strategies after the fact, so
to say, to kind of simulate what would this
traffic look like that is sent to various
resolvers if we were to use our query
distribution strategies in the first place.
And so what we're seeing here, if you look at
figure A with the hash distribution strategy,
is that if you use two resolvers, four resolvers,
or six resolvers, there's a kind of flat line
in terms of how many unique domain names from a
given client's queries are seen by various
resolvers on average.
And this is fairly intuitive to understand,
because if you think about it, in a hash-based
model, queries for the same domain name should
always go to the same resolvers.
It shouldn't be the case that two resolvers ever
receive a query for the same domain name.
Whereas if you look at the round-robin model,
within the first couple of weeks, we see that
each resolver starts to gain access to more and
more unique domain names from a given
client.
And this makes sense, because the round-robin
model doesn't have a fixed mapping between
domain names and resolvers.
Nonetheless, it is interesting to see that the
percentage of unique domain names does
kind of taper out over time.
And we think this is because in the traffic data,
there's a lot of queries for popular
domain names and fewer queries for less popular
domain names.
So in summary, we presented the design and
prototype implementation of a refactored stub
resolver architecture that allows for
decentralized encrypted DNS resolution.
We performed a preliminary evaluation of the stub
resolver's performance and utilized
the real-world dataset to evaluate how do
different query distribution strategies affect
how many queries are seen by recursive resolvers.
Our goal in this work is, again, not to suggest
that we necessarily should be using query
distribution strategies everywhere, or that we
should be using these exact strategies
or in a particular manner, but rather to explore
what is the feasibility of a distributed DNS
architecture in which we don't just send
encrypted DNS queries to a single resolver or
maybe
a small set of resolvers, but rather distribute
them across a larger set of resolvers.
And we're planning on doing some follow-up work
to see what does your performance look
like if you use a lot of resolvers, resolvers
that are in different geographic locations,
and how does this affect a client's privacy in a
formal way rather than the preliminary
evaluation that we've done?
Is there a way that we can formalize the privacy
costs and benefits of using different query
distribution strategies?
So I want to thank you all for listening to this
talk, and you are more than welcome to
contact me at the email above, and I'd be happy
to answer any questions.
So I want to thank my collaborators.
I want to thank the audience for listening, and
yeah, thank you very much.
[END]