[dns-privacy] It's DNS Jim....

["Ralf Weber" <[e-mail]>]

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