DNS over HTTPS - why won't the provider see dns?

Question

Mozilla Firefox

Good afternoon!
They write that there is a DNS function over https. They write that the provider, they say, will not see which site their client is accessing.
https://habr.com/ru/post/478012/
There right at the very beginning of the article.
And what prevents the same provider from muddiing some simple resolving type by ip-address to receive dns sites?
Or pr even the ip address of the requested sites will not see?

Answer 1

Well, this is kind of stupid. Of course, the provider sees which IP the request is going to, and the domain in SNI usually fires.
But the goal of DoH is not at all this, but that the provider (and generally anyone) could not replace the DNS response. Well, and also so that he would not even know which domain you resolved.

Answer 2

in HTTPS tlc encryption when using tor or vpn, the provider will see nothing
tor itself cannot encrypt dns traffic, but DNS over HTTPS will help

Answer 3

Because you don't understand the principle.
DoH is a request that is sent over https to a previously known server that will resolve the requested name, ostensibly allowing the browser to access the blocked site. Actually it breaks even easier than non-DoH. Why?
Here is a diagram of how provider blocking works:
- The user enters www.linkedin.org in the browser
- The browser generates a DNS packet with a request for which IP from www.linkedin.org and sends it to the router, which sends it to the provider
- The provider scans the DNS packets , sees a request to www.linkedin.org and instead of sending this packet to the world, wraps it up on its own DNS, which instead of the IP line returns the IP of the stub with the inscription blabla blocked.
- The user gets a fig in full screen
Here is a diagram of how DoH works:
- The user enters www.linkedin.org in the browser
- The browser generates a DNS packet asking which IP from a pre-known server specified in the settings and sends it to the router, and that one to the provider
- The provider looks up the DNS- packets, sees a request to a certain site in tyrnet and skips the request
- The browser has established an encrypted connection with a previously known server and sent a request to it about what IP www.linkedin.org has
- The browser received a response and showed the user a tench The user
is basking in his coolness and thinks "oh, what a fine fellow I am, how I got ... l RKN." Although who is who here ... l - it's still to be seen :)
Firstly, everything
user requests go through one specific gate, which really pushes the gate administration to accumulate statistics (and then sell/give it to someone)
tricky nut there is a bolt with the corresponding thread