Node getaddrinfo ENOTFOUND when using cy.visit() or cy.request()

[salty-blue-mango]

Current behavior:

+ nc -vzw url-hidden-for-security.ci.aws.saltstack.net 443
Connection to url-hidden-for-security.ci.aws.saltstack.net port 443 [tcp/https] succeeded!
+ echo 0
0
+ dig url-hidden-for-security.ci.aws.saltstack.net

; <<>> DiG 9.10.6 <<>> url-hidden-for-security.ci.aws.saltstack.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2269
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;url-hidden-for-security.ci.aws.saltstack.net. IN A

;; Query time: 54 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed May 13 14:05:55 MDT 2020
;; MSG SIZE  rcvd: 78

+ echo 0
0
+ set +x

> raas-ui@0.0.1 cy:content /Users/nwatts/src/raasdev/lock/raas-ui
> npx cypress run --spec 'cypress/integration/content-certification/**/*' --record --key key-hidden-for-security

/Users/nwatts/src/raasdev/lock/salt/locke/system/stig/audisp_remote_buffer_full

====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:    4.5.0                                                                              │
  │ Browser:    Electron 80 (headless)                                                             │
  │ Specs:      1 found (content-certification/audisp_remote_buffer_full.spec.ts)                  │
  │ Searched:   cypress/integration/content-certification/**/*                                     │
  │ Params:     Tag: false, Group: false, Parallel: false                                          │
  │ Run URL:    https://dashboard.cypress.io/projects/1wpobi/runs/1451                             │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘


────────────────────────────────────────────────────────────────────────────────────────────────────

  Running:  content-certification/audisp_remote_buffer_full.spec.ts                         (1 of 1)
  Estimated: 11 seconds
[cypress-log-to-output] Warning: An unsupported browser family was used, output will not be logged to console: chromium


  content certification
    1) Test Run: 1 -- audisp_remote_buffer_full
    2) Test Run: 2 -- audisp_remote_buffer_full


  0 passing (11s)
  2 failing

  1) content certification
       Test Run: 1 -- audisp_remote_buffer_full:
     CypressError: `cy.visit()` failed trying to load:

https://url-hidden-for-security.ci.aws.saltstack.net/

We attempted to make an http request to this URL but the request failed without a response.

We received this error at the network level:

  > Error: getaddrinfo ENOTFOUND url-hidden-for-security.ci.aws.saltstack.net

Common situations why this would fail:
  - you don't have internet access
  - you forgot to run / boot your web server
  - your web server isn't accessible
  - you have weird network configuration settings on your computer

The stack trace for this error is:

Error: getaddrinfo ENOTFOUND url-hidden-for-security.ci.aws.saltstack.net
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26)

Desired behavior:

Cypress should be able to successfully complete the cy.visit or cy.request command to an https url, if said url is able to be visited manually in a browser, without dns resolve issues.

Test code to reproduce

Private repo with private tests. Request access through this ticket.

Reproducible Example

Private repo with private examples. Request access through this ticket.

Versions

Tested on Cypress version 4.3.0 and 4.5.0
MacOs Catalina Version 10.15.3 (19D76)
Linux Debian - 10.3
Electron 80.0.3987.163

[jennifer-shehane]

Can you access the domain normally, via curl within your environment? What is the result of running curl yourdomain.com? Can you access the domain via a normal Node http.request within the environment? Knowing the results of these will help narrow down if this is a network issue inside or outside of Cypress.

[salty-blue-mango]

@jennifer-shehane I am able to curl the environment. I have at the top of the logs showing a netcat response as well as a dig on the url and everything is working. Running a plain https request through node.js gives a successful response as well.

[salty-blue-mango]

@jennifer-shehane Checking in on this ticket. I see that it is still labeled as stage: awaiting response.

[jennifer-shehane]

Unfortunately we have to close this issue as there is not enough information to reproduce the problem. This does not mean that your issue is not happening - it just means that we do not have a path to move forward.

Please comment in this issue with a reproducible example and we will consider reopening the issue.

[adamdicarlo]

I just ran into this, too. I'm pretty sure it's this: nodejs/node#5436 (comment) - a bug in glibc.

I'm running cypress within a pod in a kubernetes cluster and pointing it toward a hostname with a subdomain, 162330094441.maindomain.com ("maindomain" is not the actual value). The A record (from k8s's coredns, I assume) is a .local address... kubernetes uses mdns (multicast dns), and that's where the glibc bug comes up, I guess.

Assuming it's the glibc bug, there is one curious thing: the container base image is ubuntu:20.04; I would think that by 20.04, ubuntu would have incorporated the fix.

dev@sandbox-6b6bd67ddb-75bhd:~$ dig 162330094441.maindomain.com

; <<>> DiG 9.16.1-Ubuntu <<>> 162330094441.maindomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37224
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e9af45e8fafeecf8 (echoed)
;; QUESTION SECTION:
;162330094441.maindomain.com. IN	A

;; ANSWER SECTION:
ingress-nginx-controller.sandbox.svc.cluster.local. 30 IN A 10.107.88.60

;; Query time: 3 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Thu Feb 03 01:45:24 UTC 2022
;; MSG SIZE  rcvd: 139

[adamdicarlo]

I've found a workaround! Hack the /etc/hosts file inside of the pod that's about to run Cypress in order to prevent the DNS lookup for the hostname-with-subdomain-within-a-kubernetes-cluster (for the app under test) from needing to deal with the .local hostname.

This is what the hack looks like in my case:

# This must be run within the Cypress pod before starting Cypress
echo "$INGRESS_NGINX_CONTROLLER_SERVICE_HOST     subdomain.maindomain.com" | sudo tee -a /etc/hosts

where

• $INGRESS_NGINX_CONTROLLER_SERVICE_HOST is the env var provided by k8s that gives you the IP address of the service you want the hostname-with-subdomain to resolve to, and
• subdomain.maindomain.com is the hostname-with-subdomain Cypress will use to access the app under test.

My container's base image is Ubuntu 20.04.

Example command (a few coworkers and) I used to quickly test whether the problem was still present on various Docker images:

kubectl -n <namespace> run --restart=Never buster --image=node:17-buster --rm -i -t -- node -e 'void https.get("https://<subdomain>.<maindomain>.com/", console.log)'
node:events:498
      throw er; // Unhandled 'error' event
      ^

Error: getaddrinfo ENOTFOUND <subdomain>.<maindomain>.com
[...]

Here some of the work-arounds I tried that did not work:

• Monkey-patching Node's dns.lookup function at runtime from a test suite plugin file - this seemed to be in the wrong OS process
• Patching Cypress's own code in node_modules to make its request to avoid the broken DNS lookup hint flag combination - probably also the wrong process (or just one of two processes that would need patching?)
• Patching Cypress-the-app's code in ~/.cache/Cypress//Cypress/resources/app/packages/... - I may have given up before finding the exact right place(s) as I wasn't too confident in the idea of patching or monkey-patching anymore
• Using Debian Buster: Same DNS resolution problem.
• Using a newer Ubuntu release: Same problem on 21.04 and 21.10.
• Using Alpine Linux instead. On Alpine Linux (I tried the node:16-alpine image), Node.js is able to resolve the hostname-with-subdomain record provided by k8s's (which is something like ingress-nginx-controller.sandbox.svc.cluster.local. 30 IN A 10.107.88.60) without changing the flags passed to dns.lookup. In other words, code that uses https.get() works like it should. (AFAIK, it works on Alpine because musl libc implements getaddrinfo differently.) However, running Cypress (or probably any Electron app) is near or darn-near impossible with musl libc. If it is possible, it requires building Electron from source with special compiler flags and might require applying patches.

A work-around idea that I did not try:

• Somehow force k8s to give a different answer for that DNS lookup or have it also give an AAAA record, in order to trigger a different code path in glibc.

Whose bug is it, anyway?

I'm sure this is not a bug in Cypress. Cypress is using standard Node.js APIs to make HTTPS requests, that's all. It could be a bug in Node.js, or glibc, or maybe even something else. It is just not clear to me.

[KushalRaj]

Try removing all DNS list from your Network settings. It worked for me.