MS activated DoH at the operating system level, in this "great" 20H2 release...?!

provels

@johnpoz
It seems then that there would be plenty of web security gateway providers who would be against this, as well as all of corporate world.

johnpoz

Yeah I don't see how MS corp customers would be happy about this at all..

provels

At any rate, I read Unbound 1.12.0 now supports DoH.
So if someone gets bored this weekend...

johnpoz

What is the point of running doh locally - really?? Other than as a way to satisfy something that wants to use doh. So if I use a local doh, it wont use a public one. This seems more like a way to try and get people to thinking that dns needs to be encrypted.

Doh nor Dot actually does what they say it does anyway - it doesn't hide where you go from the bad old isps being able to spy.. It just changes how they have to go about it. They still see what IP you are going to, until everything and everywhere supports encrypted sni.. They can see where your going in the https handshake..

In what scenario is a local network hostile to the point that would make any sense to encrypt your local dns, and slow it down as well.

What is the extra resources in cpu cycles to have say 100 clients resolve stuff over normal dns, vs 100 clients all doing encryption and the extra cpu cycles the nameserver has to expend to support.

I just really can not think of a use case for running a local doh server..

Gertjan

@provels said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

this weekend...

Because this weekend all the root-, tld-, domain- and name servers will support it also ?
Would be nice.
My domain name servers (bind) are ready to go.

Would be the end of forwarding. Great. Yet another ancient 'setup' that can be buried. DNS would become so complex that know-body touches the default (pSense) settings any more. No more DNS questions : it just plain works out of the box (actually, DNS works out of the box RIGHT NOW but then the admin logged in and well ... checkout this forum to see what happened).
Nicely resolving over 853. Everything hidden (TLS). Everything authenticated (DNSSEC).
What the heck : even certs can be checked using DNS (DNSSEC).

I get the bubbles ready.

Where are the two nuclear power plants for compensating the extra power consumption ?

DaddyGo

@johnpoz said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

BTW - give me a link to download it from, I will fire it up as a VM.

I am already working on a longer observation test environment and will be monitoring this machine (20H2 fresh) continuously...but I also have to do my concrete job...

so our ISP is not spying on us :), it is an enterprise network with 3 pcs. 10 Gig optical lines running and serving our radio stations centrally, we have an individual contract with the ISP, who is otherwise the national BIX

soon I will send the link in PM...THX
(pls note that, this is a Hungarian "image" by default)

as I would like to note, this machine (20H2) works alongside another 57 windowsmachines and it is only on this that we experience this issue
(I did not install it in my room at home..:)

+++edit:
@johnpoz - Thanks for the positive attitude, maybe it turns out what the hell is going on...

johnpoz

Can the interface be set to english - I'm going to have a difficult time if the interface is in Hungarian ;) hehehe

I can prob muddle through - not like the icons change, that sort of thing.. But searching for stuff that is not english might be a bit painful like control panel etc..

When it comes to the nonsense that is doh, its hard to have a positive attitude to be honest.. I don't care if they want to offer it.. But turning it on by default in browsers is HORRIBLE.. If they attempt to do the same thing in the OS.. Its the just the end to be honest.. It is the wrong direction to be going.. Forcing the use of central dns is NOT the correct direction for privacy or security.

DaddyGo

@johnpoz said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

Can the interface be set to english - I'm going to have a difficult time if the interface is in Hungarian ;) hehehe

I think yes :), although I haven't tried...
the installer offers the language selection option in the begining

since I want to be faithful to the environment, I didn't download the english image

but if you can't choose a language, let me know and I'll give you an English version

I hope it also produces these stupid things in the same way...

and it wasn't just for the Hungarians who intended this stupid DoH stuff, the stupid situation in the country is enough for us... hahaha
(I don't live there but I care what's going on)

@johnpoz "If they attempt to do the same thing in the OS.. "
it really is not possible to take a positive approach to this... yes
this would take control out of the hands of the sysadmins and a lot of other shit

provels

I see the latest pfBlockerNG-devel includes several feeds to block DoH servers.

DaddyGo

@provels said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

I see the latest pfBlockerNG-devel includes several feeds to block DoH servers.

Yes, :) as I wrote above we have been using it for thousands of years..

but this is a special problem now, look at the Wireshark PRTSC (above) and / or the o.ss2.us domain to be blocked by pfBlockerNG -devel, but on this build it doesn't... (20H2 clean from MS VLSC account, especially for Hungarians... it's a joke only :))

I personaly hate the DoH, (what the fu.....k is this, because it is not privacy protection, -that's for sure)

I think the right one: DHCP for client(s) with pfSense DNS (ONLY) + Unbound + CloudFlare DNS DoT + DNSSEC and of course pfBlockerNG -devel

johnpoz

Thanks for the link - sure wont get to today.. Nor tmrw - but saturday might have some time.

Nice link - peaked out at just over 50MBps.. Not too shabby..

DaddyGo

@johnpoz said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

Nice link - peaked out at just over 50MBps.. Not too shabby..

I think that, Dropbox EU cloud storage server + Transatlantic optic cables, and the Google is now investing in an even larger capacity cable.
Life is spinning up between the continents.

I would add to the test, (these are not influencing factors, but I describe them):

The install was pure 20H2 UEFI + GPT on 120GB SSD with Rufus.
After that I just did that:

-with MiniTool Partition Wizard 80 + 40 GB,

after, I transferred the connecttest in the registry to our own server. (IPv4 only + but we don't use IPv6 anywhere, not even in pfSense - so I didn't touch it)

-Firefox installation and then I turned off DoH in Firefox (forced mode)

about:config
network.trr.mode 5

-Then the network icon indicated no internet, hmmm :), even though I pointed to our own server...
-I looked for the issue and watched for the traffic to our connecttest server, I watched for 1 hour, there was no traffic, Win10 didn't even try to connect.

I read somewhere that, when there is no "connecttest" connection the Win tries to browser based to decide, whether have an internet connection or not..

It does this through its own browsers.....

-So I "fired up" the Chromium based Edge stuff (which is already mandatory in this build) and let’s see the miracle, after 2 - 3 minutes there was internet according to the icon

By then, I had already seen the connection to this server (original MS connecttest) what we discussed above in Wireshark PRTSC, which would not have been possible, because pfBlockerNG is blocking this domain...

I selected another blocked domain from one of the DNSBL feeds and tried it, this domain has also been bypassed the pfBlockerNG (o.ss2.us)

Briefly about the test so much, I will continue the test over the weekend and thanks for taking the time to do it yourself too. :)

BTW:
It is important to note that, there was never any traffic to our own connecttest server which was configured in the registry...
then now, which thing sets the Win parameters, if not the registry(?), ergo this is something hidden from us..(?!)
The network icon has been merrily showing internet access ever since :), and still no connection to our own server...

suspicious:
-Oddly enough, Firefox and Chromium Edge also bypass pfBlockerNG

Contrary to promises, Chromium Edge (which is already built into this build - not downloaded version) does not include a DoH enable or disable parameter (specific option to Chromium-based browsers).
I couldn't find it anywhere!!!

it should appear somewhere in a similar way, but nowhere....

DaddyGo

@provels said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

At any rate, I read Unbound 1.12.0 now supports DoH.

We are on a mailing list here (Unbound), we are already ahead of this .....actually 1.13.0rc2 pre-release...
unlike us others love DoH, it’s crazy

just watch:

Rod-It

If you are using a firewall rule to allow only specific outbound rules, is DNS configured to allow TCP or just UDP or port 53?

Chrome specifically and possibly now Edge Chromium will try to use DNS over TCP or DoH if TCP is allowed out, blocking TCP 53 outbound might help if it's open as it will fall back to UDP 53.

Not sure if this will help or not, if not i at least hope it was insightful.

johnpoz

Doh does not use tcp on 53.. that is just normal dns for large stuff.. doh is over port 443.. Just like every other https site on the planet - which is why its a pita to try and block. dot on the other hand is easy because it uses 853..

Rod-It

But I'm still curious if DNS is using TCP to get a resolve.

I dont know the in-depths of PfBlockerNG or the way in which unbound works, if it used UDP only then this might help, if not and it relies on the returned results, not the lookup directly then fine.

I was just noting the TCP on port 53 for DNS in case it was not known. I am aware of DoH and 443 though.

As a final paragraph, i am not a network guy, but trying to help and in return learning a lot, so even if i am not helpful in my replies at present, i learn a lot from you guys and hope to be able to give back in the future with more meaningful and helpful posts

Gertjan

@rod-it Yes for DNS using TCP.
Reply packets that are to big for UDP will be re send using the more adequate TCP.
This can happens when DNSSEC traffic is used.

I's a known pitfall : letting port 53 UDP traffic going in and out, and forgetting about TCP.
And complaining 'DNS' doesn't work well ......

viktor_g

you can try use squid proxy in ssl bump mode to block application/dns-message media type

see https://tools.ietf.org/html/rfc8484#section-6
and https://medium.com/nlnetlabs/dns-over-https-in-unbound-c7a407e8480

johnpoz

@rod-it said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

But I'm still curious if DNS is using TCP to get a resolve.

It could. Blocking a client from talking to dns over 53 tcp could cause issues..

Now the 512 limit before switching to tcp has really been removed with support for edns.. But you never know what a query might return.. And what features of dns are supported by either the client or the dns server your talking to..

Its not a good idea to block dns over 53 on tcp.. While you may never run into a problem - when you do.. It could be problematic finding the issue.

But since doh or dot does not use dns over tcp 53.. Blocking it wouldn't get you anything.. Off the top I can not think of any reason why you would want or need to block dns over tcp 53.. But there are reasons why that could cause you issues..

I would not suggest not allowing dns over tcp 53.

DaddyGo

@rod-it said in MS activated DoH at the operating system level, in this "great" 20H2 release...?!:

If you are using a firewall rule to allow only specific outbound rules, is DNS configured to allow TCP or just UDP or port 53?

Hi,

thank you for the comment

we won't let anything out of the firewall (box) at 53
the internal network communicates only with pfSense on port 53, outward DoT 853

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

or not beautiful but effective

https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html

++edit:
https://developers.cloudflare.com/1.1.1.1/nitty-gritty-details