Re: [Resolverless-dns] Paper on Resolver-less DNS

[Anne Bennett <[e-mail]>]

PV>>> https://datatracker.ietf.org/doc/draft-sah-resolver-information/

AB>> I took a quick look at the above draft; it specifies a method
AB>> for enquiring about "features of a recursive resolver", but
AB>> gives no ideas or guidance as to what such features might
AB>> consist of, aside from a brief sentence fragment in the
AB>> abstract, "such as whether they perform DNSSEC validation or
AB>> are available over transports other than what is defined in
AB>> RFC 1035".

PV> ah. that's my misunderstanding then. i thought "has policy" was 
PV> one of the assigned indicators. it should be.

It may well become one; the draft states that "IANA will
create a new registry titled "DNS Resolver Information"
that will contain definitions of the names that can be used
with the protocols defined in this document", but since such a
registry is not implemented yet, the reader of the draft can't
assume what's intended.  Likely you've seen another document
or followed another discussion that mentioned it.

AB>> It seems to me straightforward to use this mechanism to supply
AB>> the information *that* a resolver applies filtering, but I don't
AB>> see how it could reasonably *describe* the filtering, since
AB>> such a description would essentially almost *be* the filtering.

PV> i would not, and we could not, export that policy.

We're on the same page there!

ES>>>> we talked about possible privacy drawbacks of resolver-less
ES>>>> DNS. However, did we talk about the privacy risks of using a
ES>>>> traditional DNS resolver? They can monitor the entire browsing
ES>>>> activities of a user and present the real privacy problem.

PV>>> DoT (RFC 7858) corrects that privacy problem and is being deployed.

AB>> I dispute the idea that DNS over TLS addresses the privacy
AB>> problem of the resolver operator having access to all of a
AB>> user's DNS queries.

PV> i think our ships are passing in the night.

Quite possibly, or mine may have sprung a leak.  ;-)

PV> "traditional dns resolver" means one you run on your campus,
PV> on your LAN, on your hypervisor, on your endpoint. this whole
PV> "public DNS" bullpucky is entirely non-traditional.

Ah, I was assuming that "traditional" DNS resolution was the mechanism
of UDP or TCP queries to port 53 (or, now, 853), no matter who was
running the resolver.

I don't have stats on devices on the Internet, but I suspect
that the number of DNS clients on networks run professionally,
with local resolvers, is, at this point, probably small
compared to the number of cellphones, laptops, home systems,
and IoT devices.  Ideally, these would all would use the
ISP's resolvers, but if people are connecting to untrusted
networks (e.g. wireless at the airport or coffee shop), I can
well imagine why using one of the "public" resolvers might
be considered safer, though if DNSSEC validation is used,
a hostile or compromised ISP might matter less.

PV> resolverless is questionless. no knowledge of user intent is
PV> leaked, only knowledge of user probable next steps. this is
PV> an important difference,

Thank you for setting me straight on that; I was indeed thinking of DoH.

ES> Ok, I assume we agree on a traditional DNS resolver being able
ES> to monitor the user's online activities, right?

If here you define "traditional DNS resolver" as the port 53 (or 853)
answerer of questions, then, sort of - that is, most of the user's
online activities will be based on the resolution of hostnames to IP
addresses, and the hostname queries will give the resolver a pretty
good idea of the sites of interest to the user.

But... the ISP can already do traffic analysis, based on the
endpoints of the TCP/IP connections (not to mention sniff the
traffic if it is not encrypted), so if the user is using the
ISP's resolver, there's no *additional* privacy concern there,
I think.

If you're considering that some people use the "big public
resolvers", then sure, those sites could be acquiring
information which a user would prefer to keep private.
It's rather tempting to say "so don't do that" (that is,
don't use the big public resolvers), though.  I'm still not
convinced that a whole new DNS mechanism is a step in the
right direction; it seems to me like just one more attack
surface to have to monitor and protect.

ES> Furthermore, resolver-less DNS is a decentralized approach
ES> where there does not exist a single entity being able to monitor
ES> the full scope of the user's online activities.

The ISP will always be able to do that, even if only traffic analysis.

ES> In resolver-less DNS you do not trust retrieved DNS records
ES> because you validate these records.

At this point, you should probably tell me to Read The Fine
Paper, but I immediately wonder: *how* does the client validate
the records?  I suppose the server may be sending all the
DNSSEC information.

If so, though, your scheme still cuts off my ability, as a network
admin, to use DNS resolution to impose policies to protect my users
from malware (for example).



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[e-mail]                                    [phone] x2285