windows store not working with dnscrypt but works fine on public DNS

[Dizirgee]

Hello,
Last few day I'm fighting with windows store (on win10 64bit enterprise). I see there are few issues already logged in the past like #878 #785 #30
issues differ a bit and mostly are dismissed as not related to dnscrypt proxy.
Sry for long post, tried to put info that may be useful.

I use this beautiful sw for several years (thanks!), on win10 maybe for 6 months, so far didnt had any issues. Windows updates worked fine, i noticed issues with windows store but i never used it so i was not bothered - until now when i wanted to get xbox game pass.
Windows store app just wont load and gives error that suggest connection issue or myriad of articles how to fix lame store. Xbos app cant login cause also no connection.
Everything is magically fixed when I remove 127.0.0.9 from dns setting and put 8.8.8.8
listen_addresses = ['127.0.0.9:53']

First i suspected it may be just some broken implementation of particular dnscrypt resolver i was using (found few posts on google about dnscrpyt and store issues) , so i tested handful of them
server_names = ['soltysiak', 'dnscrypt.nl-ns0', 'securedns-doh', 'dns.digitale-gesellschaft.ch', 'sth-dnscrypt-se', 'cloudflare']
and no game.

I was on 2.0.35 and just updated to latest 2.0.41, no luck.
I'm also using eset internet security and have firewall disabled for testing (initially i thought i just blocked some store service as i never intended to use store)
I'm also using hosts file from "someonewhocares" but it doesnt have impact on this, also tested with default hosts.
I have ipv6 disabled on network and also block_ipv6 = true

I'm willing to bet that problem comes from M$ store (it seems to be pretty broken after simple google search) , its probably doing some broken query or something and it just gets drop/ignored by dnscrypt...

I tried with log_level = 0 and nothing in the log, only shows which server is used.
Only interesting thing i noticed, when enable query.log , restart dnscrypt and start store app there is virtually no entries in the log , there is just one or few lines and even if i keep refreshing page in store nothing gets added. So it looks like store may be just bypassing/ignoring the dnscrypt? But
query.log works fine, if i fire any web page or anything there is suddenly dozens of entries...

I even tried to use "google" resolver (but no idea how/if it is related to their normal 8.8.8.8) and store just doesnt work.
Tried to run dnscrypt as service and from cmd no difference.

So if i use regular public dns (google/opendns) store works, if i use any dnscrypt resolvers it doesnt.
Any ideas [except to stick with opendns] ?

EDIT: this must be some M$ glitch on this PC.
I did one more test. I copied whole dnscrypt (bins & config) to my work laptop, changed only to have it listen also on external interface (listen_addresses = ['127.0.0.9:53','192.168.0.213:53'] ) store works fine there. So I went ahead and set laptop IP as only DNS for my home PC and obviously its still not working... If i put 8.8.8.8 it works. I'm totally lost here. Even if store on this PC would be bugged to hell I fail to see how/why it would be sensitive to DNS setting in this way.

[alisonatwork]

I think this is a similar problem to #1212 and it happens to me as well. Very occasionally when running dnscrypt-proxy Windows will detect a network and everything is fine, but most of the time i run with yellow icon and intermittently broken UWP.

I do think this is fundamentally an issue of Windows not proactively re-checking the connection. I don't understand why it gets stuck. The original problem seems to be some kind of race condition, but after it's triggered it seems like you can't recover any more. This also happens sometimes on computers without any dnscrypt-proxy at all, so maybe there isn't a solution... but it would be good to try figure out if there is some way of reducing the frequency, since it does seem to occur more often with dnscrypt-proxy running than without it.

[alisonatwork]

Just answering myself, i decided to try fix this on my computer today following the workaround @coliod suggested on #878 to change the group policy.

The link they posted explaining the problem is here: https://support.umbrella.com/hc/en-us/articles/230900948-Umbrella-Roaming-Client-Microsoft-Windows-Limited-Network-Connectivity-Warning-Yellow-Triangle- Basically: by default the Network Connectivity Status Indicator will not use a DNS server on a different local network interface to do the network connectivity check. So if your DNS is set to 127.0.0.1, then the check will always fail.

This can be overridden by changing the group policy. I did it in Powershell on my computer, like this: https://github.com/alisonatwork/dotfiles/blob/master/scripts/Fix-NetworkConnectivityStatusIndicator.ps1

I just rebooted and so far things are fine, but it will probably take a few days of reboots, hibernates, wifi, no wifi etc to be sure that it works. If it does work, it might be worth adding to the docs here.

[iWARR]

@jedisct1
In fact, Windows fix needed

Windows 10 has a new network connectivity issue (gHacks)

The MS bugfix has been planned at early April, 2020.

---

There are another facts. M$ won't fix known bugs for years/tens years...
I've found the NCSI works bad many-many years ago. At last, they admited and decided to fix this. Lets see...

Anyway, those who expecting issues, should try the wiki : Network Connectivity Status Indicator (NCSI). The Variant 1 is for regular setup (any machines with or without DNSCrypt installed). This is your base point. Then try to play with other things.

I beleive, as soon as you done the wiki, everything will be OK even without new MS bugfixes. I can't say for sure, because I have all MS extra stuff deleted/disabled/restricted (Clouds, Xbox, Store, etc.)

---

Another advise is enabling blacklist log. Look in closely, if there no blocked aliases when you try to connect to the MS online services.

[lessload]

Is it possible to use powershell to get public-resolvers or other ? beacuse shell can access internet without trust NCSI . Example my script can detect intenet without use NCSI.

powershell -Command "Invoke-WebRequest https://pastebin.com/raw/RH3GW47Q -OutFile '%Temp%\dnscrypt-check.txt' -TimeoutSec 1"
for /F "delims=:" %%I in (%Temp%\dnscrypt-check.txt) do (if /I "czd" == "%%I" (echo x > "%Temp%\dnscrypt-check.txt" && GoTo OnlineRun) else (GoTo OfflineTest))

It may update public-resolvers without problem.

*** For all UWP app, app cannot access internet without NCSI check pass. ***
*** This topics problem may cannot solve. or you can try my script Here ***

[jedisct1]

@lessload Sure, the lists are here https://download.dnscrypt.info/resolvers-list/v2/

[alisonatwork]

The wiki page @iWARR wrote has a lot of detailed options for disabling or modifying the Windows network connectivity check. I have linked it in at the bottom of the "Installation on Windows" page of the wiki.

One thing not included on that page, though, is the UseGlobalDNS fix which i have been running successfully with for a couple weeks now. It might be worthwhile including that as a "quick fix" to just route the NCIS check through 127.0.0.1 for people who are on Windows 10 build 1709 or later.

Also documented here, btw: https://community.webroot.com/troubleshooting-116/network-icon-showing-yellow-with-the-webroot-dns-protection-agent-installed-339903

[lessload]

Is it possible to self host connecttest.txt by dnscrypt-proxy
and set 127.0.0.1 www.msftconnecttest.com in host file to bypass NCSI check.?
This problem maybe solve?

original NCSI url http://www.msftconnecttest.com/connecttest.txt
NCSI Registry location HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet

[alisonatwork]

I've just expanded the troubleshooting section in https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-Windows so that it documents the UseGlobalDNS workaround, as well as linking through to https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Windows-NCSI for more detailed information. I think this should solve the problem described in this and related tickets now.