Change Cloudflare DNS to a less-known version

[spaze]

1.1.1.1 (and 1.0.0.1) is often blocked on network level due to either buggy network devices or intentionally (like in #9106).

1.1.1.2 together with 1.0.0.2 (malware-blocking DNS) and 1.1.1.3 with 1.0.0.3 (malware and adult blocking) are less-known Cloudflare DNS addresses and as such may work more often than 1.1.1.1. It certainly helps here, I can't reach 1.1.1.1 due to buggy ISP router but can go to 1.1.1.2 easily. See Cloudflare's own docs https://developers.cloudflare.com/1.1.1.1/setup/#1111-for-families

I have checked what the DNS is used for (for PHPStan Pro resolving only) and I know this is a workaround but it may help more users see the "Try different DNS servers" message less often. What do you think?

[phpstan-bot]

You've opened the pull request against the latest branch 1.11.x. If your code is relevant on 1.10.x and you want it to be released sooner, please rebase your pull request and change its target to 1.10.x.

[staabm]

Would it make sense to use both?

[spaze]

Probably not. I don't know exactly how the React DNS Config object works but if it would randomly pick one of the servers then there's 50% chance it would pick the one that doesn't work, making debugging it a bit harder because it would sometimes work.

If it would try one and then the other one if it fails, then it would possibly introduce a delay.

[ondrejmirtes]

Hi, are you often seeing the message "Could not download the PHPStan Pro executable ... Try different DNS servers in your configuration file"?

The problem is that the way the code currently works it that it shows this message for any network problem. So it might actually not be a DNS problem, just your spotty internet connection. Is that possible?

We'd need to improve this code so that it states the true problem. The problem is that when DNS resolution fails, it might also be because of a not-working internet connection, not a firewall.

So I'm suggesting something like this:

1. Try downloading PHPStan Pro as today
2. If it fails, try to figure out the reason:
3. Let's try downloading with a known IP address that we know exists. For example take the address of account.phpstan.com, and call the webserver with the right Host header. If it works, it might be a DNS issue, if it doesn't, we know the internet does not work.
4. If we think the connection works, let's try to resolve the IP address of the download-api server for the PHPStan Pro PHAR. (It's on AWS Cloudflare so it's dynamic and who knows what's going on there). If it fails, we know the DNS is blocked.
5. All of the steps above should be in some kind of "retry" block and tried 3 times.

WDYT?

[spaze]

Hi, thanks. I've extensively debugged the problem last year already and I'm 100% certain it's DNS why I see the message. The DSL modem model I have is blocking any and all packets to 1.1.1.1, so I see the message every single time I'm trying to use Pro unless I configure anything else than 1.1.1.1.

Here are some fresh tests:

Ping

~ $ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 17386ms

~ $ ping 1.1.1.2
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=56 time=74.0 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=56 time=99.2 ms
^C
--- 1.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 74.034/86.666/99.299/12.635 ms

DNS:

~ $ dig +short example.com
93.184.216.34
~ $ time dig +short example.com @1.1.1.1
^C
real    0m8.215s
user    0m0.022s
sys     0m0.028s
~ $ time dig +short example.com @1.1.1.2
93.184.216.34

real    0m0.109s
user    0m0.017s
sys     0m0.026s

Traceroute:

~ $ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.164.1 (192.168.164.1)  8.457 ms  7.707 ms  7.148 ms
 2  192.168.1.1 (192.168.1.1)  6.582 ms  6.186 ms  6.680 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *^C
~ $ traceroute 1.1.1.2
traceroute to 1.1.1.2 (1.1.1.2), 30 hops max, 60 byte packets
 1  192.168.164.1 (192.168.164.1)  55.331 ms  54.116 ms  53.664 ms
 2  192.168.1.1 (192.168.1.1)  53.195 ms  52.720 ms  52.256 ms
 3  89-24-145-107.customers.tmcz.cz (89.24.145.107)  64.404 ms  64.024 ms  63.549 ms
 4  * * *
 5  213.29.94.201 (213.29.94.201)  61.847 ms  61.445 ms  61.087 ms
 6  prag-b4-link.ip.twelve99.net (62.115.180.86)  60.868 ms  14.149 ms  14.185 ms
 7  cloudflare-ic-372123.ip.twelve99-cust.net (80.239.192.87)  14.258 ms  13.903 ms  17.485 ms
 8  1.1.1.2 (1.1.1.2)  13.032 ms  14.230 ms  13.116 ms
~ $

The results are stable as in I see them whenever I run the tests. It's the modem as confirmed by multiple other users of the same model.

[spaze]

Another question I couldn't find an answer to: why use a custom DNS and not leave it up to the local resolver? It's speed? Something else? The ReactPHP component supports TCP but doesn't support DNS-over-TLS for example (there's a pull request, although seemingly abandoned 10 months ago).

[ondrejmirtes]

Oh god, that sucks. I'm supposed to get T-Mobile fiber internet in 2 months so hopefully it's gonna work better :D

[ondrejmirtes]

Thank you. BTW thank you for using PHPStan Pro. I have some ideas how to make it awesome and I plan to make it a reality later this year :)

[spaze]

Oh god, that sucks. I'm supposed to get T-Mobile fiber internet in 2 months so hopefully it's gonna work better :D

Oh nice! It will work better unless you get the same model of the modem (you won't unless you'd get fiber with RJ-11 connectors 😅). Not sure if the problem is anything made by Sercomm or if it's this model only, or possibly a T-Mobile firmware.

[ondrejmirtes]

and not leave it up to the local resolver?

That's how it was originally but some users have a non-working DNS setup on their computer and they're not even aware of it. They're probably just relying on the web browser configuration or something.

reactphp reads the DNS config from /etc/resolv.conf so probably on some systems there's this file but the OS does not actually use it. That's why there can be some nonsense in that file, everything on the computer continues to work, except for PHPStan Pro.

[spaze]

Thank you.

Thank you :-)

BTW thank you for using PHPStan Pro.

Took me a while to get around to it, to realize how it could help and that it indeed can. Would you mind if I file some issues (mostly usability) I think would make it better?

[ondrejmirtes]

I'm aware of its many issues and I plan to rework it + add new features. So please wait for the revamp before filing the feedback :)

[spaze]

Cool, will wait 😁 Honestly speaking right now the textual interface is more usable for me (partly maybe because I'm so used to it) but I have still activated the subscription (right now, even skipped trial) to keep you motivated 😊 Not sure if it works but it feels right. Looking forward, thanks!