DNS error

[ManojKiranA]

while running expose share

this the error i am getting
Could not connect to the server.
Connection to sharedwithexpose.com:443 failed during DNS lookup: DNS error

[drbyte]

sharedwithexpose.com seems to be responding fine for me.
Perhaps it was a temporary DNS sync issue.

[mpociot]

I think this has something to do with how ReactPHP resolves the dns, as this is implemented in PHP as well.

[clue]

I agree that this error message is somewhat confusing and doesn't provide the necessary information. That's why I've filed reactphp/socket#230 a few weeks ago in the underlying component to improve error reporting. I'm planning to release this in the next couple of days if everything goes according to plan. This should give us much better insights to see what's going on.

In the meantime, you can also try installing this component from dev-master to see if the exception includes any more details 👍

[mpociot]

@clue I just sent a test build with dev-master to someone that can reproduce the problem.

Here's the result:

Could not connect to the server.
Connection to sharedwithexpose.com:443 failed during DNS lookup: DNS query for sharedwithexpose.com failed: Unable to connect to DNS server (No route to host)

But pinging the host works just fine for him:

ping sharedwithexpose.com 
PING sharedwithexpose.com (142.93.106.246): 56 data bytes
64 bytes from 142.93.106.246: icmp_seq=0 ttl=49 time=143.324 ms
64 bytes from 142.93.106.246: icmp_seq=1 ttl=49 time=118.773 ms
64 bytes from 142.93.106.246: icmp_seq=2 ttl=49 time=116.059 ms

[clue]

@mpociot Thanks, this makes it much easier to debug:

DNS query for sharedwithexpose.com failed: Unable to connect to DNS server (No route to host)

This means the client side can't connect to the DNS server, so this is likely a system configuration or firewall issue. Perhaps you can try running one of the included DNS examples here: https://github.com/reactphp/dns/tree/master/examples

This is very close to what's being used internally by the socket component. We're not aware of any issues in our DNS component and these examples should work out of the box.

If it doesn't work on your system, you can also try checking the $config to see if it matches your expected system settings and/or manually specify another DNS server address (1.1.1.1 or 8.8.8.8) to see if this helps. A dump of $config and /etc/resolv.conf might be useful for further diagnosis.

[ian-patel]

dig +trace sharedwithexpose.com can't find records. ping looks fine.

[peteleco]

@clue Thanks, adding 1.1.1.1 dns works for me. Then i remove this dns let only google's dns and still works. I'm in Brazil, maybe was some slow dns propagation.

[themsaid]

Running the first example from https://github.com/reactphp/dns/tree/master/examples returns this:

RuntimeException: DNS query for www.google.com failed: Unable to connect to DNS server (No route to host) in /Users/mac/sites/dns/src/Query/UdpTransportExecutor.php:132
Stack trace:
#0 /Users/mac/sites/dns/src/Query/TimeoutExecutor.php(23): React\Dns\Query\UdpTransportExecutor->query(Object(React\Dns\Query\Query))
#1 /Users/mac/sites/dns/src/Query/RetryExecutor.php(79): React\Dns\Query\TimeoutExecutor->query(Object(React\Dns\Query\Query))
#2 /Users/mac/sites/dns/src/Query/RetryExecutor.php(22): React\Dns\Query\RetryExecutor->tryQuery(Object(React\Dns\Query\Query), 2)
#3 /Users/mac/sites/dns/src/Query/SelectiveTransportExecutor.php(67): React\Dns\Query\RetryExecutor->query(Object(React\Dns\Query\Query))
#4 /Users/mac/sites/dns/src/Query/CoopExecutor.php(58): React\Dns\Query\SelectiveTransportExecutor->query(Object(React\Dns\Query\Query))
#5 /Users/mac/sites/dns/src/Query/HostsFileExecutor.php(64): React\Dns\Query\CoopExecutor->query(Object(React\Dns\Query\Query))
#6 /Users/mac/sites/dns/src/Resolver/Resolver.php(35): React\Dns\Query\HostsFileExecutor->query(Object(React\Dns\Query\Query))
#7 /Users/mac/sites/dns/src/Resolver/Resolver.php(24): React\Dns\Resolver\Resolver->resolveAll('www.google.com', 1)
#8 /Users/mac/sites/dns/examples/01-one.php(18): React\Dns\Resolver\Resolver->resolve('www.google.com')
#9 {main}%    

[clue]

@themsaid Thanks for providing this exception trace. Can you file an issue in the upstream repo https://github.com/reactphp/dns with some details about your platform (PHP version, OS, /etc/resolv.conf and a dump of your $config object)?

We're not currently aware of any issues in our DNS component and people have been using this on a wide variety of platforms for years, so I'm really curious what could cause this issue. The only thing I have in mind might be if your system has a broken DNS configuration (primary DNS broken, but secondary DNS works), this is not currently implemented (reactphp/dns#6).

In the meantime, you should be able to work around this by explicitly defining another DNS server like given above. As an alternative, you can also temporarily add an entry to your /etc/hosts file like this (warning, may change in the future):

142.93.106.246 sharedwithexpose.com

Expose will also somehow use a Connector internally which accepts optional explicit DNS server configuration to override system defaults. This Connector can explicitly be configured like this:

$connector = new React\Socket\Connector($loop, array(
    'dns' => '127.0.1.1'
));

[mpociot]

@clue I was talking with @themsaid about this today and he was able to fix this.
He was using 1.1.1.1 as his system configured DNS server - which resulted in the above error.
When manually setting the DNS server to 8.8.8.8 he was able to connect to the Expose server successfully.

I think the best way to fix this in the Expose codebase, is to give users the ability to manually override/configure the DNS server that should be used when connecting.

[clue]

@mpociot I don't agree that Expose should have explicit DNS configuration by default. Any application should take advantage of the system configuration and just work. If your ping command works, so should Expose. If your ping command works and Expose doesn't work, then something is broken (could be a missing feature in the underlying DNS component).

Adding explicit DNS configuration options could be useful in some more advanced scenarios, but this probably shouldn't be the default. In particular, Expose should not override the system settings by default because the system DNS configuration could configure a company-internal DNS server which resolves different addresses than a publicly available one such as Couldflare's or Google's (let alone possible privacy implications).

I'd really like to understand what's causing this problem as it clearly seems to affect multiple users. We just need some more information and a fix probably shouldn't be too hard 👍

[mpociot]

Those are good points against having it configurable @clue :)

We will probably need some more input from @themsaid then.
All I know is that he is living in Egypt, where some internet censorship is in place, so this might be part of the problem.

[themsaid]

@themsaid I have no idea what's the causing the issue :) Could be the ISP indeed :)

[drbyte]

In the cases where this problem is occurring ...
Is dnsmasq installed? (eg Laravel Valet uses it, as do other tooling systems)

If so, then sometimes explicitly configuring to use 127.0.0.1 as the primary DNS service is helpful.

dnsmasq does honor hosts files out-of-the-box, so that's still a suitable place to put custom servername entries.

But with dnsmasq I would suggest not editing resolv.conf but instead to edit the dnsmasq settings (with Valet you can put custom configs in ~/.config/valet/dnsmasq.d/; without Valet you can probably use /etc/dnsmasq.d/ if enabled or /etc/dnsmasq if you like tampering with default files)

[omitobi]

I also experienced this issue right now on expose

Could not connect to the server.
Connection to sharedwithexpose.com:443 failed during DNS lookup: fwrite(): send of 38 bytes failed with errno=65 No route to host

[chiribuc]

I checked my /etc/resolv.conf and I remembered that i have IPV6 from my IPS.
If I change the order in the resolv.conf (set the IPV6 last) I don't receive an error anymore but the domain generated by expose it's not reachable from outside.

Now its back with the error...

Could not connect to the server.
Connection to tls://sharedwithexpose.com:443 timed out after 20 seconds

[chiribuc]

Yes...IPv6 is the problem.
I disabled it from my router and it works now but I don't like it. :)

[michaeldyrynda]

Can confirm disabling IPv6 resolves this :(

[mpociot]

Can someone help me reproduce this?

My /etc/resolv.conf looks like this:

nameserver 2001:4860:4860::8888

So it's using an IPv6 DNS, but I'm still able to connect to Expose.

It would be great if someone with this issue could try the following:

git clone [email protected]:beyondcode/expose.git

cd expose

composer update

./expose share my-local-site.test

This updates the internal ReactPHP component dependencies, so maybe this fixes it for you? As I can't verify the fix, I could use some help.

[chiribuc]

Can someone help me reproduce this?

My /etc/resolv.conf looks like this:

nameserver 2001:4860:4860::8888

So it's using an IPv6 DNS, but I'm still able to connect to Expose.

It would be great if someone with this issue could try the following:

git clone [email protected]:beyondcode/expose.git

cd expose

composer update

./expose share my-local-site.test

This updates the internal ReactPHP component dependencies, so maybe this fixes it for you? As I can't verify the fix, I could use some help.

I tested but it gives me the same error:

Could not connect to the server.
Connection to sharedwithexpose.com:443 failed during DNS lookup: DNS query for sharedwithexpose.com failed: Unable to connect to DNS server (php_network_getaddresses: gethostbyname failed. errno=0)

[chiribuc]

If I change the order of DNS and set the IPv6 to be the last in the /etc/resolv.conf than it works.
So from this:

nameserver IPv6
nameserver IPv6
nameserver IPv6

nameserver IPv4
nameserver IPv4
nameserver IPv4

to this:

nameserver IPv4
nameserver IPv4
nameserver IPv4

nameserver IPv6
nameserver IPv6
nameserver IPv6

[dakira]

@mpociot It's actually only not working when IPv6 or DNS over IPv6 is improperly configured, be it by the user or more probably the ISP. At that point the problem I discussed above with @clue kicks in. ReactPHP doesn't try a second DNS server if the first doesn't work (while the OS does and people don't notice their IPv6 DNS config is borked).

Just my wild guess after doing some testing on this..

[clue]

TLDR: Send a couple of sponsors my way (https://github.com/sponsors/clue) and I'm happy to solve this. 💸

This requires a feature addition in @reactphp which Expose builds on top of. Expose does not need any changes once this is built into @reactphp.

---

Here's a recap of what's going on:

• This only affects users that have multiple DNS servers and their primary DNS server is invalid (not reachable, not responsive etc.)
• This happens irrespective of whether you're using IPv4 or IPv6 (either works just fine!)
• Having multiple DNS servers is more common in dual stack setups, hence why this seems to be linked to IPv6
• This can be easily worked around by making sure the very first nameserver entry in your /etc/resolv.conf is valid (see above: DNS error #25 (comment))
• This can be easily reproduced by adding an invalid nameserver entry in your /etc/resolv.conf at the very top
• An invalid nameserver entry should not cause this error when other nameserver entries are valid (this requires work, see below)

Here's what needs to be implemented in @reactphp to make sure this error no longer shows up even when people have invalid nameserver entries:

• Done: The DNS component already supports parsing multiple nameserver entries into a Config object
• The DNS component needs to accept multiple DNS servers (limited to one address at the moment, use Config instead of a string)
• The DNS component needs a new "DNS executor" which accepts two executors and triggers the second one only if the first one fails
• The DNS component needs to wire up a stack of fallback executors when more than one nameserver is given in the Config
• The DNS component needs to be tagged in order for other component to depend on this new feature
• Done: The Socket component already parses all nameserver entries into a Config object
• The Socket component needs to pass the complete Config object instead of only its first nameserver entry to the DNS component (requires new DNS tag)
• The Socket component needs to be tagged in order for other component to depend on this new feature
• The Datagram component needs to pass the complete Config object instead of only its first nameserver entry to the DNS component (requires new DNS tag)
• The Datagram component needs to be tagged in order for other component to depend on this new feature
• Expose needs to be updated to require the new Socket component (requires new Socket tag), the DNS implementation is entirely opaque, no other changes whatsoever are required

As you can see, this is a non-trivial amount of work. I've layed out this plan to show this is very much actionable and could be solved in a couple of days.

As much as I'd love to work on this, I won't be able to commit to this right now: I'm rather busy working on a bunch of others projects at the moment.

Perhaps we can find a couple of new GitHub sponsors to allow me spending some time on this?

Put your money where your mouth is? 💸

[ondrejmirtes]

@clue BTW I had the same problem in PHPStan Pro and I solved it by hardcoding the DNS server to 1.1.1.1 for everyone. Can you think of any downside with this approach? Do you think that someone can have this server blocked by their corporate firewall or something?

[clue]

@ondrejmirtes Yes, this can be problematic. Hard-coding a public DNS server as the primary DNS server might be an option for some use cases (which is why this is indeed supported by @reactphp). This was briefly discussed in #25 (comment):

Adding explicit DNS configuration options could be useful in some more advanced scenarios, but this probably shouldn't be the default. In particular, Expose should not override the system settings by default because the system DNS configuration could configure a company-internal DNS server which resolves different addresses than a publicly available one such as Couldflare's or Google's (let alone possible privacy implications).

As per #25 (comment), some public DNS servers are also blocked in some more restrictive legislations (think country-wide blocks / firewalls implemented at the DNS level).

From a developer's perspective, I think this could perhaps be the more important reason why DNS fallback servers should be supported in ReactPHP itself:

@mpociot I don't agree that Expose should have explicit DNS configuration by default. Any application should take advantage of the system configuration and just work. If your ping command works, so should Expose. If your ping command works and Expose doesn't work, then something is broken (could be a missing feature in the underlying DNS component).

[ondrejmirtes]

@clue I see, it's funny how me and @mpociot had the same train of thought - I planned that if it turned out that 1.1.1.1 didn't work for everybody, I'd make the DNS configurable in PHPStan :D

I'm kind of used to that people's systems are broken in all kinds of ways, so it's better not to rely on it. For example in one instance the client crashed because the user had some non-sense in the memory_limit setting in php.ini, PHP silently ignores it, but some piece of code that tries to parse it throws an exception.

But I'll trust you on this one :)

[WyriHaximus]

Here's what needs to be implemented in @reactphp to make sure this error no longer shows up even when people have invalid nameserver entries:

• Done: The DNS component already supports parsing multiple nameserver entries into a Config object
• The DNS component needs to accept multiple DNS servers (limited to one address at the moment, use Config instead of a string)
• The DNS component needs a new "DNS executor" which accepts two executors and triggers the second one only if the first one fails
• The DNS component needs to wire up a stack of fallback executors when more than one nameserver is given in the Config
• The DNS component needs to be tagged in order for other component to depend on this new feature
• Done: The Socket component already parses all nameserver entries into a Config object
• The Socket component needs to pass the complete Config object instead of only its first nameserver entry to the DNS component (requires new DNS tag)
• The Socket component needs to be tagged in order for other component to depend on this new feature
• The Datagram component needs to pass the complete Config object instead of only its first nameserver entry to the DNS component (requires new DNS tag)
• The Datagram component needs to be tagged in order for other component to depend on this new feature
• Expose needs to be updated to require the new Socket component (requires new Socket tag), the DNS implementation is entirely opaque, no other changes whatsoever are required

@clue Do we have issues for all of this on the respected @reactphp repositories for tracking?

P.S. I'd be happy to pick those up, but it's not super high on my own priority list, like @clue says a one or more sponsors can help with that.

[simondavies]

I got the following error as others

Connection to sharedwithexpose.com:443 failed during DNS lookup:

Then looking through the above i did the following as others recommended @chiribuc thanks

edit my etc/resolv.conf and switched the IPv4 and IPv6 around.

nameserver 0000::0000:0000:0000:0000
nameserver 192.168.1.??

to

nameserver 192.168.1.??
nameserver 0000::0000:0000:0000:0000

and all run ok.

[fahmiegerton]

I have face similar issue. It was working before (weeks ago) but now it doesn't work. Am i doing something wrong?

[izshreyansh]

Using 1.1.1.1 definitely fix this issue.