[dns-privacy] In response to dprive DoT and why current DNS protection efforts are failing.

[Brewst <[e-mail]>]

I support the idea of the path between resolver and authoritative server
being encrypted by using DoT, as well.

I would like to bring up a topic from earlier responses. Particularly how a
system should handle DNS. I am in support of a system handling DNS settings
itself and any application that wishes to change this should require
elevated permissions. For context, this is referring to how we are using
DoH at the moment.

I believe the current atmosphere around browsers using stub resolvers can
unfortunately fall under RFC1087. The components of RFC1087 will follow and
I will be adding examples of how browsers(and other software) can be
interpreted as violating or not having these guidelines in mind while
allowing stub resolvers.

1.seeks to gain unauthorized access to the resources of the Internet
This can be interpreted as gaining unauthorized access to user system
information. We have to implicitly trust organizations and hope they are
not using their current infrastructure to take and catalog DNS queries and
system information. I know this can seem like a stretch as the user is
choosing to do this. In an example like the firefox browser, this is
enabled automatically. This should always involve system owner choice and
explicit permission to be performed.
source:
https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/

2.disrupts the intended use of the Internet
This can be seen as a way to circumvent the intended use of DNS. Software
developers should not be able to change the nature of how DNS works just
because of their personal view on the insecurity of current DNS practices.
This can be seen as an opinion. A better answer could be: Ignoring current
DNS settings within a system or organization potentially circumvents the
intended destination for DNS queries and use of resolution itself.

3.wastes resources (people, capacity, computer) through such actions
This can be easily understandable from an enterprise, small business, or
home office standpoint. Resources at organizations are wasted when
configuring domain policies to enforce anti stub resolver flags within
software. Organizational DNS resources are wasted when domains attributed
to third party resolvers need to be blocked to prevent
un-authorized traffic sent to said resolvers. Organizational security
research time and efforts are wasted in the investigation of security
events related to the unauthorized destination change of DNS traffic.

4.destroys the integrity of computer-based information
This can be interpreted as information from systems being shared with a
third party without any controls implemented to safeguard the integrity of
proprietary information. Because the information of systems is shared with
a third party, we have to assume the integrity of said information is no
longer guaranteed as they do not allow access for organizations or
individuals to officially query how their data is being used.

5.compromises the privacy of users.
This one is self explanatory. Sending data to a third party who is not held
responsible for the integrity of data sent to them, compromises privacy.
The way stub resolvers are handled today leads to additional privacy
concerns as well. As many of you are aware, Cobalt strike introduced a
module which takes advantage of the loose regulations DoH is built around
and leverages it to gain access to system information with the ability to
further compromise said systems. This is all without elevated permissions.

Brass tax section:
DNS resolution and destination of DNS traffic should not be allowed to
change without explicit system owner permission. The proposed solution of
having DNS encrypted via DoT from the resolver to authoritative is
fantastic idea. It ensures the data's integrity while also giving system
owners the ability to inspect traffic sent to their local resolver as well
as the traffic sent back to systems from the resolver. This also limits
organizational overhead as user systems would not need to be configured any
different than they are now. It would also remain seamless for the average
user, as well.
source:
https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/
It is a good read and hopefully can provide you with knowledge needed to
help determine the future of how DNS is protected.

I am new to this mailing list and if this is the wrong forum to bring up my
concerns with where and how DNS resolution settings should be controlled,
let me know.

Thanks for your time,

Logan