DNS resolving with cloaking-rules.txt should not be impaired if connectivity isn't esthablished yet.

[ghost]

In hotels or at other public places there are wifi access points which require authentication via a web interface.

To reach this web interface one is required to visit http://1.1.1.1 or http://neverssl.com. The access point tries to hijack the web-request (can't do that to the dns-request since dnscrypt-protocol isn't vulnerable to dns-hijacking) and redirects the web-request with an 302 error code i.e. to blafoo.monzoon.net.

Dnscrypt-proxy can not resolve blafoo.monzoon.net by asking an uplink resolver since there is no connectivity at this point of time. However, dnscrypt-proxy should be able to resolve blafoo.monzoon.net if specified in /etc/dnscrypt-proxy/cloaking-rules.txt when /etc/dnscrypt-proxy/cloaking-rules.txt is specified and enabled in /etc/dnscrypt-proxy/dnscrypt-proxy.toml.

blafoo.monzoon.net webserver is reachable with curl http://<IP address of blafoo.monzoon.net>. The webserver very probably needs a header with "Host: blafoo.monzoon.net" to allocate the wifi to the hotel or public place.

Output of the following commands:

./dnscrypt-proxy -version
2.1.1

./dnscrypt-proxy -check
[empty]

What is affected by this bug?

DNS resolving before having connectivity.

When does this occur?

After dnscrypt-proxy outputs that it is up and running (and hasn't shut down to missing connectivity yet).

Where does it happen?

At hotel wlans and similiar public access points.

How do we replicate the issue?

If you are a laptop user you probably do not have to replicate that issue because you have experienced it yourself before.

Expected behavior (i.e. solution)

dnscrypt-proxy should deliver IPs from /etc/dnscrypt-proxy/cloaking-rules.txt without connectivity. dnscrypt-proxy should detect that connectivity is blocked. Blocked traffic should not result in time out or shut down of dnscrypt-proxy.

Other Comments

I love dnscrypt-proxy. Thumbs up for the good work.

[jedisct1]

What you are describing is a captive portal.

There's a dedicated configuration file in dnscrypt-proxy to handle resolution before the network is enabled: captive-portals.txt and a section in the configuration file.

This is what you should use instead of cloaking.

[ghost]

Thanks for the answer... I looked into captive-portals.txt and I thought that is for checking if connectivity beyond the router is possible without going through a captive portal.

As it is also a list of hard-coded IP addresses I'll try it the next time I'm in a hotel (tonight or tomorrow).

[ghost]

Mmmhhh. I have trouble getting that feature to work. However, that is very likely not due to dnscrypt-proxy but to a unique combination of NetworkManager, iptables and dnscrypt-proxy shutting down after a while.

[issuex]

Look like dnscrypt-proxy can't work with captive portal smoothly for a long time.

My solution is

• disable netprobe by netprobe_timeout = 0
• run curl --resolve detectportal.duckdns.org:80:84.200.69.80 -L -s -o /dev/null -w %%{url_effective} http://detectportal.duckdns.org to open captive portal website.
• lookup captive-portal-website.com to local dns add record it to cloaking-rules.txt
• run curl command again and captive portal work without switch loopback dns.!