I've been embroiled in my first house-move in 28 years, and just got back
to the table. I don't see any threads here about whatever this thing-which-
appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it?
Is there an official name for it I should be searching for?
Is it in fact not a monstrosity, and I'm just not smart enough? 
Cheers,
-- jra
DNS over HTTPS. And yes…DNS over TLS would be better in my opinion.
The IETF calls it "DoH", pronounced like "Dough". https://datatracker.ietf.org/wg/doh/about/
There are a number of such services from Google, Amazon, and others. Firefox and Chrome now reportedly use it unless you tell them not to. It is also in use by at least one botnet, per reports.
https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module
https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/
https://www.bleepingcomputer.com/news/security/psixbot-modular-malware-gets-new-sextortion-google-doh-upgrades/
One thing that bothers me about the Google implementation is that they apparently download the IANA zone and, in effect, operate as an informal root server. Not that I am protective of the root per se, but the root operators operate by an ethos described in RSSAC001 (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf.). If Google wants to promote itself into those ranks, I would expect it to shoulder the ethos and responsibility implied. The articles I pointed to above would suggest that it does not.
Aside from "DoH" (smacks Homer's head), you might find searching for the Mozilla (et. al.) "canary domain" useful.
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual.
It was mentioned in this (partially related) thread, with all the responses being the predictable “lol these folks in Silicon Valley need to lay off the drugs”.
https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html
Matt
It was mentioned in this (partially related) thread, with all the responses being the predictable ???lol these folks in Silicon Valley need to lay off the drugs???.
https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html
Here are some UKNOF presentations on it -
UKNOF43 - Potential ISP challenges with DNS over HTTPS
UKNOF44 - The latest news in the DNS resolution
UKNOF44 - Update on DoH and emerging IETF / IRTF standards
UKNOF44 - Panel: Operational Considerations of DoH Deployment
a message of 28 lines which said:
> Is there an official name for it I should be searching for?
The IETF calls it "DoH", pronounced like
"Dough". DNS Over HTTPS (doh)
And it is standardized in RFC 8484, which was published one year ago.
There are a number of such services from Google, Amazon, and
others.
And you can build your own quite easily, these days, to avoid being
dependent on a few US corporations.
One thing that bothers me about the Google implementation is that
they apparently download the IANA zone and, in effect, operate as an
informal root server. Not that I am protective of the root per se,
but the root operators operate by an ethos described in RSSAC001
(https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf.).
This is in line with RFC 7706 "Decreasing Access Time to Root Servers
by Running One on Loopback", and the root zone operators explicitely
authorize zone transfer, partially for this purpose.
a message of 10 lines which said:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least)
will go back to using your local DNS server list as per usual.
Unless, I hope, the user explicitely overrides this. (Because this
canary domain contradicts DoH's goals, by allowing the very party you
don't trust to remotely disable security.)
a message of 37 lines which said:
Here are some UKNOF presentations on it -
Note that the UK is probably the country in Europe with the biggest
use of lying DNS resolvers for censorship. No wonder that the people
who censor don't like anti-censorship techniques.
Indeed. It seemed like a glaring hole in the implementation. The Mozilla page on the topic implies it's temporary until some sort of "standard" solution can be found, but since you will always have folks who control DNS and want/need to enforce something like this (enterprises, for example), I'm not sure how you'd go about this without resorting to e.g. group policy-like things which is messy in its own right.
There are some additional checks for "enterprise" networks including checking whether "enterprise roots" is enabled which I guess is different from simply loading in extra root certificates. Why Mozilla and Google are SO insistent that I must not have control over my root certificate list is beyond me.
But yes, there's a Firefox pref to force it (or completely disable it regardless of the canary). Amusingly, unlike most of the actually-useful Firefox prefs, this one is apparently in the GUI [1]. It also allows you to pick the provider (Cloudflare or "custom", of course).
The bare about:config pref you want is "network.trr.mode". Short and sweet of it, set to 5 (off by choice), and it should disable the function entirely. 3 would be the opposite: always use it.
[1] https://support.mozilla.org/en-US/kb/firefox-dns-over-https
The goal is centralization of DNS and being to see more what users (or at least the aggregate stats, so that they can claim "we do not keep your data/IP/lookups") do, the goal is not that of 'security' or 'privacy'.
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
Also keep a split between the protocol and the implementation. DoT and DoH both serve the same goal of "encryption", but that is not being used here: they also want to move the recursor to another entity...
At least the use-application-dns.net zone is now not DNSSEC signed anymore as it was before, thus at least a NXDOMAIN can now be caused instead of SERVFAIL as .net indicated a signature, while one overrode that locally...
Greets,
Jeroen
According to Mozilla:
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-ov
er-https
Network administrators may configure their networks to treat DNS
requests for a canary domain differently, to signal that their local DNS
resolver implements special features that make the network unsuitable
for DoH.
In addition to the canary domain signal described above, Firefox will
perform some checks for network features that are incompatible with DoH
before enabling it for a user. These checks will be performed at browser
startup, and each time the browser detects that it has moved to a
different network, such as when a laptop is used at home, work, and a
coffee shop. When any of these checks indicates a potential issue,
Firefox will disable DoH for the remainder of the network session,
unless the user has enabled the "DoH always" preference as mentioned
above.
The additional checks that will be performed for content filtering are:
    Resolve canary domains of certain known DNS providers to detect
content filtering
    Resolve the "safe-search" variants of google.com and youtube.com to
determine if the network redirects to them
    On Windows and macOS, detect parental controls enabled in the
operating system
The additional checks that will be performed for private "enterprise"
networks are:
    Is the Firefox security.enterprise_roots.enabled preference set to
true?
    Is any enterprise policy configured?
The bare about:config pref you want is "network.trr.mode". Short and
sweet of it, set to 5 (off by choice), and it should disable the
function entirely. 3 would be the opposite: always use it.
Thank you, IMO this is by far the most useful piece of information on
the subject!
Robert
a message of 26 lines which said:
> (Because this canary domain contradicts DoH's goals, by allowing
> the very party you don't trust to remotely disable security.)The goal is centralization of DNS
Hmmm, no, read RFC 8484 (section 1).
While the 'connection to the recursor' is 'encrypted', the recursor
is still in clear text... one just moves who can see what you are
doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and
whatever: the remote end can see what you do. What's your point?
a message of 26 lines which said:
(Because this canary domain contradicts DoH's goals, by allowing
the very party you don't trust to remotely disable security.)The goal is centralization of DNS
Hmmm, no, read RFC 8484 (section 1).
Correct: for the DoH protocol it is not that goal, there it solely is "encryption". But DoT already solves that.
For the implementation though of DoH (what most people have a problem with), the sole goal is centralization and moving the information collection from the ISP to single entities that are already collection so much data, this just gives them more and for properties they do not even operate.
While the 'connection to the recursor' is 'encrypted', the recursor
is still in clear text... one just moves who can see what you are
doing with this.As with any cryptographic protocol. Same thing with VPNs, SSH and
whatever: the remote end can see what you do. What's your point?
The point is that the claimed goal (for the deployment) is that it gives users 'privacy', but in the end that 'privacy' just moves from the ISP that the user pays to an unrelated company that wants to see it all...
False advertising anyone?
Greets,
Jeroen
a message of 29 lines which said:
Correct: for the DoH protocol it is not that goal, there it solely
is "encryption". But DoT already solves that.
DoT is fine, (and my own public resolver activates it) but, as you
know, it is too easy to block, either explicitely, or as a by-product
of a "only port 443" policy.
Also, most of the complaints (for instance by the lobby who wrote to
the US congress) about DoH apply also to DoT (for instance, like DoH,
it prevents the ISP to modify or even to see the DNS requests and
responses, so the lobbies who don't like DoH won't like DoT either).
For the implementation though of DoH (what most people have a
problem with), the sole goal is centralization
This is your personal opinion, not a fact. (Speaking as someone who
deployed a DoH resolver.)
and moving the information collection from the ISP to single
entities that are already collection so much data,
That's why we need more DoH resolvers. Install one!
The point is that the claimed goal (for the deployment) is that it
gives users 'privacy', but in the end that 'privacy' just moves from
the ISP that the user pays to an unrelated company that wants to see
it all...
Security is often moving stuff to a different trusted party (think of
VPNs, for instance).
TDLR:
- Using DoT or DoH as a protocol is fine, though the recursor still controls/views the DNS queries
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53 is does not improve security or privacy...
Getting that forced fed by the monopolies controlling the browser.... bad for the Internet.
- Use a VPN if you do not trust your network provider.
- Use Tor if you really want 'privacy'.
a message of 29 lines which said:
Correct: for the DoH protocol it is not that goal, there it solely
is "encryption". But DoT already solves that.DoT is fine, (and my own public resolver activates it) but, as you
know, it is too easy to block, either explicitely, or as a by-product
of a "only port 443" policy.
Sounds like you don't trust the network you get access from (and possibly pay).
Use a VPN to get out of there. Though then you also move your trust point of course, but at least you do it for everything.
Just doing this for your webbrowser is not solving your problem (till encrypted SNI is a thing *everywhere*), there are other services on the Internet than this "HTTP" thing...
You might also want to look into this amazing thing called Tor if you really want privacy.
Also, most of the complaints (for instance by the lobby who wrote to
the US congress) about DoH apply also to DoT (for instance, like DoH,
it prevents the ISP to modify or even to see the DNS requests and
responses, so the lobbies who don't like DoH won't like DoT either).
You just moved your problem to the entity that now runs your DNS recursor.
Before "encryption" the network and the recursor could view/change your requests.
Likely these where both your ISP.
Encrypting to the recursor will still allow that recursor to see and modify answers.
Btw enabling DNSSEC only allows you to verify that there was a lie (or no answer).
Most users currently use their network provided DNS server. As such, they are likely using the one from the ISP...
The question is: who do you trust, in this question: the one that offers the recursive service.
If you do not trust your local network, VPN/Tor out of there.
If you trust your local network (as you pay them, just trust them, or live in a country with strong privacy enforcement and data collection policies), then just use them.
Browsers forcing upon a user per default a DNS provider does not address any of these things.
For the implementation though of DoH (what most people have a
problem with), the sole goal is centralizationThis is your personal opinion, not a fact. (Speaking as someone who
deployed a DoH resolver.)
You are mixing things.
A) Anybody can deploy DoT or DoH for their recursors (I have too).
B) Browser vendors are doing this "DoH" thing to centralize DNS to their recursors.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
And Mozilla claims that suddenly that is a good thing as 'it is encrypted', while it does not change the adversary: recursor still run by an ISP, that apparently one does not trust...
and moving the information collection from the ISP to single
entities that are already collection so much data,That's why we need more DoH resolvers. Install one!
Installed a whole bunch of them....
But not using them myself. DoT is the technically better version.
The point is that the claimed goal (for the deployment) is that it
gives users 'privacy', but in the end that 'privacy' just moves from
the ISP that the user pays to an unrelated company that wants to see
it all...Security is often moving stuff to a different trusted party (think of
VPNs, for instance).
See above.
Moving only your DNS to Cloudflare or Google does not solve the security stance, even though that is what people are marketing this whole DoH move for....
Greets,
Jeroen
I would also be concerned about the lock-in this creates. Cloudflare (at previous DNS-OARC meetings) has said their main reason for paying Mozilla & 1.1.1.1 is to improve the performance for their customers. I think this is a great thing for their customers, but is also an issue - if you take it to the privacy extreme here it harm not only their competitors but the end-users involved as well.
I’m personally very concerned about the very extreme stance taken by some people & organizations with the overall protocols and how they will harm the internet of the future.
I for one am awaiting the DoHoToQUICo53 overlords to appear.
- jared
a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH
or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation)
over UDP is quite an old thing and nobody complained. I really wonder
why there was so little reaction against OpenDNS or Google Public DNS
and suddently a lot of outcry against DoH...
You might also want to look into this amazing thing called Tor if
you really want privacy.
I know it, and use it and it is awfully slow. Telling to people who
want privacy that they need to adopt the difficult and costly (in
performance) solutions made for iranian opponents won't help to
improve security.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
Fact-checking: could you name some? (I do not know even one.)