ahmetb / runsd

Drop-in Service Discovery capabilities for Google Cloud Run.

Home Page:https://ahmet.im/blog/cloud-run-service-discovery/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

External domain getaddrinfo ENOTFOUND

thomas-advantitge opened this issue · comments

Hi,

We're encountering the following DNS error when executing a request from our Cloud Run container to api.powerbi.com:

getaddrinfo ENOTFOUND api.powerbi.com.

We tried both POWERBI_URL="https://api.powerbi.com/v1.0/myorg" and POWERBI_URL="https://api.powerbi.com./v1.0/myorg" with a dot because of #42 (comment).

DNS resolving of this domain works without runsd inside Cloud Run.

Our DB connection is however working with runsd, but that might be related to the fact that this is not a http connection so runsd might handle this differently.
Another difference between api.powerbi.com and the MongoDB domain could be the length, as we see a lot of logs like this:
runsd

Which brings me to the side question, again related to #42, if there could be a negative impact on DB connections depending on how many times runsd is resolving DNS names?

Try the https://github.com/ahmetb/runsd/blob/master/example/main.go app for troubleshooting how dns works.

The last question depends on your DB client library as it may do connection pooling, and DNS records can be cached by the resolver (in language runtime, router/recursive resolver etc).

Putting a dot at the end would prevent excessive resolution but it doesn't mean it's much slower.

Results from the example container show that google.com, cloud.google.com and powerbi.com are all working well. So there must be something odd with api.powerbi.com.

Strange enough, dig seems to show DNS resolution works:

$ dig +search A api.powerbi.com


; <<>> DiG 9.16.29 <<>> +search A api.powerbi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18455
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.powerbi.com.		IN	A

;; ANSWER SECTION:
api.powerbi.com.	3600	IN	CNAME	api.privatelink.analysis.windows.net.
api.privatelink.analysis.windows.net. 120 IN CNAME 03be66dd-3487-4b89-a8d9-89ade6381a91.trafficmanager.net.
03be66dd-3487-4b89-a8d9-89ade6381a91.trafficmanager.net. 300 IN	CNAME wabi-west-europe-d-primary-redirect.analysis.windows.net.
wabi-west-europe-d-primary-redirect.analysis.windows.net. 120 IN CNAME wabi-west-europe-d-primary-comp-ev2.westeurope.cloudapp.azure.com.
wabi-west-europe-d-primary-comp-ev2.westeurope.cloudapp.azure.com. 10 IN A 40.74.30.205

;; Query time: 92 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 30 09:03:37 UTC 2022
;; MSG SIZE  rcvd: 544

whereas curl is not able to resolve the host.

$ curl -sSLNv --http2 https://api.powerbi.com

* Could not resolve host: api.powerbi.com
* Closing connection 0
curl: (6) Could not resolve host: api.powerbi.com
curl failed: exit status 6

The host is resolvable without runsd. The only differences in the dig outputs between powerbi.com (working) and api.powerbi.com are the CNAME records and the three level sub domains. Could this impact the http requests?

You can enable verbose logging on runsd to see if it's handling that url odd when it comes from cURL for some reason. It might have something to do with dot count. Try appending a "." to the domain name.

You can refer to architecture guide/blog post to understand how it works. It's not too complex.