Support custom DNS IP and DNS failover IP using custom DNS resolver

[ghengeveld]

• Added CHROMATIC_DNS_SERVERS environment variable to support custom DNS IP addresses.
• On ENOTFOUND error, automatically switch to using a custom DNS resolver that doesn't rely on OS-level DNS
• Added CHROMATIC_DNS_FAILOVER_SERVERS environment variable use when we still encounter ENOTFOUND even using the custom DNS resolver.

[linear]

AP-2314 Allow Customers To Override DNS When 'ENOTFOUND' Errors Are Returned From The Chromatic CLI

What

From time to time, customers encounter DNS lookup errors, typically on Macs, where the CLI can resolve index.chromatic.com until it can't. When this happens, the CLI will eventually return a getaddrinfo ENOTFOUND error and the customer cannot complete a build. Yann has run across this before as well.

Why

When Node passes the DNS lookup to the host OS, most of the time it simply works. But there are times when that DNS simply fail. The getaddrinfo part of the error message means that it is failing outside of Node down somewhere in the OS system libraries. Additionally, the HTTP package leverages this host API call but does have a way to override it.

How

The proposed solution would be to allow customers to set an environment variable to configure DNS servers that the CLI would use. There is a branch out on the CLI's repo that hard codes DNS to 1.1.1.1 and 4.4.4.4, cacheable-lookup. This branch fixed Yann's DNS issue. (link)

[jmhobbs]

I like having both options to override default and still have a fail over.

There's no cache built into Node direct DNS, do we want to add a layer or just accept the extra lookups will happen?

[brockwood]

There's no cache built into Node direct DNS, do we want to add a layer or just accept the extra lookups will happen?

That is a good idea and there are packages that will wrap the dns.resolve call that we could use: https://www.npmjs.com/package/axios-cached-dns-resolve

[ghengeveld]

I looked at axios-cached-dns-resolve, but since we don't use Axios, I don't think we can use it. I briefly looked for a lower-level alternative, but didn't find an obvious candidate. Considering the limited amount of requests we actually do (assuming the use of --zip), I think it's not a big enough concern to address right now.