aws / aws-sdk

Landing page for the AWS SDKs on GitHub
https://aws.amazon.com/tools/
Other
68 stars 13 forks source link

Using dualstack endpoints fails in SecretsManager & eu-central-1 #645

Closed autarchprinceps closed 2 months ago

autarchprinceps commented 10 months ago

Describe the bug

Using dualstack endpoints fails in SecretsManager & eu-central-1

Error describing: Error: getaddrinfo ENOTFOUND secretsmanager.eu-central-1.api.aws

Expected Behavior

I am inside a VPC & EKS, and can resolve other endpoints, manually and through EKS.

/ # nslookup ec2.us-east-1.api.aws
Non-authoritative answer:
Name:   ec2.us-east-1.api.aws
Address: 3.83.171.207
Non-authoritative answer:
Name:   ec2.us-east-1.api.aws
Address: 2600:1f70:8000:20:c609:79a8:4398:f678

Current Behavior

I assume this has something to do with apis being named differently in different regions. You can't just replace the

/ # nslookup ec2.us-east-1.api.aws
Non-authoritative answer:
Name:   ec2.us-east-1.api.aws
Address: 3.83.171.207
Non-authoritative answer:
Name:   ec2.us-east-1.api.aws
Address: 2600:1f70:8000:20:c609:79a8:4398:f678
/ # nslookup ec2.eu-central-1.api.aws
** server can't find ec2.eu-central-1.api.aws: NXDOMAIN
** server can't find ec2.eu-central-1.api.aws: NXDOMAIN

Reproduction Steps

new SecretsManagerClient({
      region: 'eu-central-1',
      useDualstackEndpoint: false
    });

works, while switching that false to true breaks it.

Possible Solution

No response

Additional Information/Context

No response

SDK version used

3.385.0

Environment details (OS name and version, etc.)

Linux on EC2, Mac outside, pretty universal.

ajredniwja commented 9 months ago

Hi @autarchprinceps thanks for opening this issue, I was able to reproduce the issue:

Reproduction code:

import { SecretsManagerClient, DescribeSecretCommand } from "@aws-sdk/client-secrets-manager";

(async() => {
    const secretsManagerClient = new SecretsManagerClient({
        region: 'eu-central-1',
        // endpoint: 'https://secretsmanager.eu-central-1.dualstack.amazonaws.com'
        useDualstackEndpoint: true
    });

    try {
        const data = await secretsManagerClient.send(new DescribeSecretCommand({ SecretId: 'secret_id' }));
        console.log(data);
    } catch (error) {
        console.error(error);
    }
})();

Getting similar results for us-west-2 as well

I will have the team review this.

RanVaknin commented 7 months ago

Hi @autarchprinceps,

I looked a bit into this. This does not seem like an SDK issue. The secrets manager service itself does not have a dual stack endpoint defined in every single region. Same goes to your example with EC2, the EC2 service does not expose a dualstack endpoint for every region. This document highlights which services support dualstack endpoints, but unfortunately its not clear what are the actual supported endpoints.

The SDK does not "know", or cannot inherently verify the existence of specific service endpoints in each region, especially when it comes to dualstack configurations. It relies on a set of predefined rules and formats to construct these endpoints. If an endpoint for a particular service in a specific region has not been set up for dualstack use, or if there's a misconfiguration on the service side, the SDK would still attempt to construct and access it based on those rules, leading to a resolution failure.

This is done for forward compatibility reasons so that new endpoints "would just start working" when introduced by the service teams, circumventing the need for client side updates.

As it stands, this is not actionable by the SDK team, but I did create an internal ticket with the secrets manager service team to try and clarify this for you.

Let me know if you need anything else.

All the best, Ran~

P105787696

RanVaknin commented 7 months ago

Hi @autarchprinceps ,

I heard back from the service team. They mentioned that the standard endpoint are dualstack by default, which means that using the useDualstackEndpoint: true will result in the SDK trying to use the default dualstack endpoint scheme which is not used in the case of secrets manager.

➜  ~ host secretsmanager.us-east-1.amazonaws.com
secretsmanager.us-east-1.amazonaws.com has address 54.89.26.226
secretsmanager.us-east-1.amazonaws.com has address 18.209.193.36
secretsmanager.us-east-1.amazonaws.com has address 18.214.158.206
secretsmanager.us-east-1.amazonaws.com has address 34.207.27.105
secretsmanager.us-east-1.amazonaws.com has address 34.227.248.3
secretsmanager.us-east-1.amazonaws.com has address 34.231.78.94
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce04:cf54:e48d:ded:b474
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce02:c30c:bd57:b796:8cb4
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce01:7707:2a5c:d55b:b060
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce00:f4ec:1979:3f07:5ed3
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce03:e601:1b91:b5a9:ade2
secretsmanager.us-east-1.amazonaws.com has IPv6 address 2600:1f18:2544:ce05:b877:65fc:fb76:cfc7
secretsmanager.us-east-1.amazonaws.com mail is handled by 10 inbound-smtp.us-west-2.amazonaws.com.
➜  ~ host secretsmanager.us-west-2.amazonaws.com
secretsmanager.us-west-2.amazonaws.com has address 52.10.72.53
secretsmanager.us-west-2.amazonaws.com has address 54.213.110.155
secretsmanager.us-west-2.amazonaws.com has address 54.218.221.255
secretsmanager.us-west-2.amazonaws.com has address 44.233.50.148
secretsmanager.us-west-2.amazonaws.com has IPv6 address 2600:1f14:804:9201:3647:af99:9ae5:66f1
secretsmanager.us-west-2.amazonaws.com has IPv6 address 2600:1f14:804:9200:f853:6163:cc97:e0a5
secretsmanager.us-west-2.amazonaws.com has IPv6 address 2600:1f14:804:9203:957e:dae8:e3bd:c3ce
secretsmanager.us-west-2.amazonaws.com has IPv6 address 2600:1f14:804:9202:a954:7661:a544:a5f2
secretsmanager.us-west-2.amazonaws.com mail is handled by 10 inbound-smtp.us-west-2.amazonaws.com.
➜  ~ host secretsmanager.us-gov-west-1.amazonaws.com
secretsmanager.us-gov-west-1.amazonaws.com is an alias for AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com.
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has address 96.127.76.181
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has address 52.222.52.66
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has address 96.127.82.53
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has IPv6 address 2600:1f12:f71:e102:f3ef:9dc3:683a:6b91
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has IPv6 address 2600:1f12:f71:e101:b06c:28a4:7a4e:fb33
AWSMi-ExtNL-1K39E78IDMP2V-15f9d80091033c0b.elb.us-gov-west-1.amazonaws.com has IPv6 address 2600:1f12:f71:e100:8e68:58f4:52c3:fd36
➜  ~

The workaround here is to just use the standard endpoint as they support IPv6.

Thanks, Ran~

github-actions[bot] commented 2 months ago

This issue is now closed.

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.