Moin!
I apologise to Sara for stealing the tagline from her excellent article
at RIPE (
https://labs.ripe.net/Members/sara_dickinson/doh-its-dns-jim-but-not-as-we-know-it
), but the one point I seem to miss on the requirements list is that we
want a DNS solution.
Now there are a lot of reasons why DNS is successful, but there are two
both architectural and operational that I want to point out here and
that IMHO are important:
- Delegation of authority
- Caching
both are simple and effective which is why there semantics where kept
when going from DNS to DNSSEC and I see no reason not to keep these
semantics for going to encrypted DNS.
I call it encrypted DNS and not DNS privacy as this is what we can do as
DNS community, some of the privacy ideas on the interim or mailing list
(timing deltas for queries, different outgoing behaviours depending on
different inbound channels) are stuff that doesn’t take into how large
scale DNS works these days. The biggest risk to privacy today are IMHO
in HTTP land (ads, cookies) and not in the unencrypted connection
between recursive and authoritaitve DNS servers. I’m not saying that
we should not encrypt these sessions, but highly loaded server where the
user can hide between hundreds of thousand other users is sufficiently
private. Now not everyone can run or use those highly loaded servers and
thus we are working on encrypting this traffic, but if you want 100%
privacy you have to do a lot more on other lower levels (aka Tor) and we
should not try to solve all the privacy problems here.
A normal recursive resolver that usually handles 10s or 100s of
thousands of request per second only can do so because it is getting
most of the answers out of caches. For most providers these days the
cache hit rates are above 90% meaning only every 10th packet he has to
go out and look up something. As most queries require more than one
outgoing query to answer it cold (and sometimes even hot) these number
in real life is even higher, and answers from cache are fast as there is
no waiting for a reply packet, which is why a lot of modern resolvers
pre fetch popular content when it’s about to expire, which again is a
great privacy feature as the actual incoming ask can never relate to an
outgoing query for popular domain other then when the server is started.
So going to 2 different caches for dns privacy or disabling caches seems
like a no starter for me. Also as answering from cache and recursing is
different and often lives in independent threats, so far that it not
always possible to digest what caused a outgoing query (as the
recursive/iterative process causes lots of recursions). Also being
different code paths usually enhancements to the recursive part are
given to all users and not just a portion of users. That is true for
DNSSEC (if you turn it on all users gain validation) and should be also
true for encrypted DNS.
Now onto delegation, we have a clear way of delegating information down
the tree to a different entity. All the information needed is handed
down from the parent (NS and Glue for DNS plus DS for DNSSEC). This
seems to be the natural place to put information about enrypted DNS
(maybe TNS, Glue and TDS or something for keys), and while I worked with
software that encoded key material in name server names I don’t think
it will fly as people want to name their name servers.
So these are my two cents (and only my personal views) to the discussion
as I missed the interim meeting.
So long
-Ralf
——-
Ralf Weber
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
