Cannot resolve external Domain Name from fleet VPC

I have a client-service application running on an EC2 instance in a separate VPC. This client-service is associated with an elastic ip address with a registered domain name. Let’s call it (example).com

My gamelift-fleet servers (WINDOWS_2012) need to make http(s) requests to this service during gameplay.

I am getting the following error in my Unity log files:
Curl error 6: Could not resolve host: (example).com

Tests:

  1. The domain name for my service is correctly set up. My service responds to http requests targeted to (example).com from the public internet.

  2. I tried using wget in the server’s powershell and got a similar error.
    wget http://(example).com -OutFile out.html
    wget : The remote name could not be resolved: (example).com

  3. I set up Gamelift VPC Peering as described here, but still get the same error from wget.

  4. I tried wget again replacing (example).com with:

    • Private IP Address
    • Elastic IP Address
    • AWS Private DNS
    • AWS Public DNS

    And got the same error
    wget : The remote name could not be resolved: (example).com

So,
How do I access my service (preferably by domain name) from within the fleet’s VPC?

Update:
I removed http => https forwarding from the client-service.

Now I can successfully reach the client-service from a fleet instance using insecure http so long as I do not use (example).com in the url

This is a good start, but I don’t want the client-service to respond to http requests.
(Even if they are never exposed to the outside internet.)

I would be happy to not use VPC peering at all, and simply communicate between the server and client-service via https through the outside internet; however,
if I disable VPC peering, the server still cannot reach (example).com

From the server:

  • wget http://google.com => success!

  • wget http://ec2-(my-elastic-ip).us-west-2.compute.amazonaws.com => success!

  • wget http://(example).com => FAILS
    “The remote name could not be resolved: (example).com”

From outside the VPC:

  • wget http://(example).com => success!

I think it has something to do with internal VPC DNS resolution, but I don’t fully understand it.

Can anyone help explain this?
Thanks

As a workaround, can you reach your server via IP address?

There shouldn’t be anything special about the GameLift fleet VPC, it should be configured with domain name resolution enabled
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html

There can be a lot of reason for VPC DNS resolution failure unfortunately.

Can you provide your fleet id? I will see if someone from the GameLift service team can take a quick look.

@Pip Thanks for the response : )

Yes, I can reach my client-service via ip address or even amazon generated public DNS name.
Unfortunately, with this method I cannot use HTTPS since my certs are registered (via LetsEncrypt) only to the domain name, not the ip address.

Here is my fleet id:
fleet-f120a31e-79b0-4b6a-8e56-f4c58c063a7c

I have left a document titled “PLEASE HELP.txt” on the server’s desktop with more details including the domain name that will not resolve.

I will leave the fleet running for a few days or until I hear a response.
Thank you

Another workaround I found (which allows HTTPS) is to add the domain names to the server’s hosts file.
This circumvents the need for DNS resolution.

But this is NOT A VIABLE SOLUTION on WINDOWS_2012, because windows UAC prevents modification of this file at install time.

I still do not understand where DNS resolution is failing. : ( Shouldn’t the VPC be treating my domain name like it does any other external domain name?? eg. google.com

Terminated fleet-f120a31e-79b0-4b6a-8e56-f4c58c063a7c
to conserve resources.

Update:
I could not resolve my domain name from within the client-service VPC either (in addition to the fleet VPC).

I may try posting to the VPC forum or else switching to linux and modifying server hosts file at install time.

I converted my Unity server build to run on Linux.

My install.sh now modifies /etc/hosts which enables my server to internally resolve my client-service domain name. This is good.

Unfortunately, the HTTPS web request is still not going through. The domain name is resolved, but there is an error accessing the CA store on the instance.

Unity bubbles up this error:
“Curl error 77: Error reading ca cert file from /etc/ssl/certs/ca-certificates.crt”

On both AMAZON_LINUX and AMAZON_LINUX_2
/etc/ssl/certs/ca-certificates.crt does not even exist.

My understanding is that linux distributions like Ubuntu use ca-certificates.crt, while Amazon Linux uses a different CA store system. Is this correct?

When I try to curl a HTTPS request to my domain name as gl-user-remote from a server instance via ssh it works.

So… Unity should be able to use curl under the hood, unless it is somehow hard-coded for an Ubuntu style CA-store…

This is frustrating :rage:
Does anyone have a suggestion?

Solution:

I added a symbolic link to the instance’s actual CA store, because UnityWebRequest was looking for a specifically named file “ca-certificates.crt”

sudo ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/ssl/certs/ca-certificates.crt

Thus my overall solution was two-fold:

  1. Used AMAZON_LINUX_2 servers and modified /etc/hosts with my domain name at install time (this would have been much more difficult on WINDOWS_2012)

  2. Added a symbolic link to handle the Unity bug preventing access to the server’s CA store

My servers can now communicate with my client-service application over HTTPS by traversing the public internet. VPC peering was not part of my final solution.

Woo! :grinning:

Glad you managed to unblock yourself.

Are you using GameLift TLS connections for your fleet? As you should ideally be calling GetInstanceCertificate from your server rather than relying on any fixed locations on the machine.

Yes, I am using the GameLift-generated TLS certificates and GetInstanceCertificate() to locate them.

My symbolic link, however, IS hard-coded to the location of the trusted CA store which I believe to be a property of the OS, so hopefully it is not likely to change.