Closed Piccirello closed 3 years ago
I'm a little worried this is going to break some users that are running in locked down environments. The only DNS server available may be a company-managed one, in which case DNS resolution will now fail. However, if this new DNS resolution feature is disabled by default, it will require affected users to specify --use-dns-resolver
(or something similar) on every CLI command. I expect the locked-down DNS to mostly occur in production environments where commands are run by some orchestration tool, rather than one-off. It also seems the only users currently impacted by this DNS issue are running the CLI locally, where users are more likely to be running one-off commands. Thus I think the trade-off of default enabled makes sense.
I'll send out a communication later today to our customers to let them know about this change. I'll hold off on shipping this for 2 weeks to give them ample time to make any required changes.
I pushed up a change that adds support for the DOPPLER_DISABLE_DNS_RESOLVER
environment value. Setting that env var to true
will disable the custom DNS resolver, removing the need to specify --no-dns-resolver
on every command (though the flag still exists).
I also pushed up a change to disable the feature by default. This will allow us to ship this PR sooner so that users can immediately start adding the custom dns flags as needed. We'll then ship a new release in two weeks that will enable the feature by default.
This PR switches the CLI to use a custom Go DNS resolver for all requests. This is to address the
context deadline exceeded (Client.Timeout exceeded while awaiting headers)
issue a small number of users are seeing when using a Google WiFi router (among others).Cloudflare's
1.1.1.1
is used, with the ability to override this value via--dns-resolver-address
. The custom DNS resolver can be disabled entirely with the--no-dns-resolver
flag.Closes ENG-1304.