DNS Error when resolving subgraph Url on subgraph introspect (error[E028])

[platzhersh]

Description

I wanted to make an instrospection on one of our subgraphs.

rover subgraph introspect https://k8s-dev.cistec.com/com/patient/graphql --header "Authorization: Bearer <token>"

but instead I am getting

error[E028]: error sending request for url (https://k8s-dev.cistec.com/com/patient/graphql): error trying to connect: dns error: no record found for Query { name: Name("k8s-dev.cistec.com.home."), query_type: AAAA, query_class: IN }
        Make sure the endpoint is accepting connections and is spelled correctly

Something seems to not work with the host resolution. The hostname is resolvable in our company network. A curl / ping to it works perfectly fine.

Thought maybe its SSL related, found #837, but the new insecure options didn't help.

Also I executed the exact same command just about 10 minutes earlier, before upgrading rover cli and it worked. (Previous version was v0.8.1)

Steps to reproduce

Clear steps describing how to reproduce the issue. Please link to a reproduction if you can. This makes your issue much easier to diagnose.

Expected result

Expected introspection response with schema.

Actual result

error sending request for url (https://k8s-dev.cistec.com/com/patient/graphql): error trying to connect: dns error: no record found for Query { name: Name("k8s-dev.cistec.com.home."), query_type: AAAA, query_class: IN }
        Make sure the endpoint is accepting connections and is spelled correctly

Environment

Run rover info and paste the results here

Rover Info:
Version: 0.13.0
Install Location: /Users/cglat/.rover/bin/rover
OS: Mac OS 13.2.1 [64-bit]
Shell: /bin/zsh
cglat@cglat-mac s

[platzhersh]

For now, I'm just using curl and jq, which does the job. But would be nice to have the rover CLI to work too.

curl --location 'https://k8s-dev.cistec.com/com/patient/graphql' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{"query":"\nquery SDL {\n  _service {\n    sdl\n  }\n}","variables":{},"operationName":"SDL"}'\
| jq -r '.data._service.sdl' > subgraph.graphql

[platzhersh]

rover explain E028 prints this: (didn't help much)

E028

This error occurs when Rover could not connect to an HTTP endpoint.

If you encountered this error while running introspection, you'll want to make sure that you typed the endpoint correctly, your Internet connection is stable, and that your server is responding to requests. You may wish to run the command again with --log=debug.

[m4r0z]

Hey mate, any fix for this?

[platzhersh]

I know there was something about header option not being supported for certain rover cli commands, but that was for rover dev if i'm not mistaken. So no, no solution yet afaik, we are still just using curl.

[abernix]

Just as a note to point out from the original issue, it appears two things are true:

• There is a seemingly errant .home suffix on the error message which would seem to suggest that a .home TLD is being attempted during the DNS lookup: Is there a search domain setup in the /etc/resolv.conf (or similar) that could be causing this?
• Rover is attempting a IPv6 lookup here (based on the AAAA query). Is that expected given your network? What happens if you pass the -6 flag to your curl command (which has curl use IPv6)?

Query { name: Name("k8s-dev.cistec.com.home."), query_type: AAAA, query_class: IN }

[furai]

Seems I'm affected by this and can reproduce it without issues. It's something about DNS resolution. One of our domains has CNAME which resolves to 3 different IPv4 addresses, to access it I connect through OpenVPN. My host machine supports IPv6. I have valid IPv6 assigned to the machine I'm using but I guess our VPN does not have IPv6.

When running rover with --log=debug I get messages about it trying to resolve AAAA address even though there's no valid AAAA assigned to that domain. So I guess it somehow checks that system capabilities allow for IPv6 connection but then when connecting to some other network that won't support IPv6 it still tries to do it nonetheless instead of just using available IPv4 addresses.

Curiously enough it won't happen when I use npx. When using npm run script it breaks. No idea what's the deal here.

I'm using version 0.24.0.

EDIT: OK, it's working properly in version 0.24.0. When running npx I was using newer version than running through npm run script. Didn't notice it at first. I guess that some dependency update to some cargo packages fixed this issue.