Skip to content

vsock-proxy fails with DNS lookup of numeric CID as hostname (e.g. "19.ec2.internal") causing "Error at checking the allowlist: DNS lookup failed!" #716

@iamsrirams

Description

@iamsrirams

Title: vsock-proxy fails with DNS lookup of numeric CID as hostname (e.g. "19.ec2.internal") causing "Error at checking the allowlist: DNS lookup failed!"

Description:

I am encountering a persistent issue running the vsock-proxy from AWS Nitro Enclaves CLI version 1.4.3 on an EC2 instance in the us-east-1 region.

When starting vsock-proxy with correct numeric Enclave CID (19), the proxy performs DNS resolution on a hostname formed by appending the CID to the local domain, e.g. 19.ec2.internal.

This DNS lookup fails because this hostname does not exist, causing vsock-proxy to exit with the error:

Error: "Error at checking the allowlist: DNS lookup failed!"

This issue occurs under both conditions:

  1. Empty allowlist:

When /etc/nitro_enclaves/vsock-proxy.yaml contains an empty allowlist:

allowlist: []

The proxy immediately attempts DNS resolution on 19.ec2.internal and fails with the above error.

  1. Sample allowlist with valid AWS KMS domain entries:

Even when the allowlist contains valid KMS regional endpoints, such as:

allowlist:
  - address: kms.us-east-1.amazonaws.com
    port: 443

DNS lookups for these domains also fail within the proxy context despite successful DNS resolution from the system shell.


Steps to reproduce:

  1. Build and install AWS Nitro Enclaves CLI version 1.4.3 on an EC2 instance.
  2. Verify running enclave CID using:
nitro-cli describe-enclaves
  1. Create minimal or empty allowlist config /etc/nitro_enclaves/vsock-proxy.yaml as described above.
  2. Run vsock-proxy with:
sudo /home/ec2-user/nitro/aws-nitro-enclaves-cli-1.4.3/build/install/usr/bin/vsock-proxy --config /etc/nitro_enclaves/vsock-proxy.yaml 8080 19 8080
  1. Observe DNS lookup attempt to resolve 19.ec2.internal resulting in NXDOMAIN and proxy exit with the DNS error.

Expected behavior:

  • vsock-proxy should treat the numeric CID as an identifier and not attempt DNS resolution on a hostname formed from it.
  • Allowlist DNS resolution should succeed for valid domains.
  • Ability to disable internal DNS hostname lookups if necessary.
  • Proxy should start correctly both with an empty and a valid populated allowlist.

Actual behavior:

  • vsock-proxy always fails with DNS lookup errors.
  • Queries for 19.ec2.internal fail because the name does not exist in VPC DNS.
  • Allowlist domain lookups fail within the proxy context despite working from the shell.

Additional Information:

  • DNS lookups from the system shell (even with minimal environment) succeed for allowlist domains.
  • Network captures show repeated DNS queries for 19.ec2.internal with NXDOMAIN responses.
  • Tested with both empty allowlist and valid allowlist; both fail.
  • All relevant environment variables and network settings verified as correct.
  • Nitro CLI shows enclave CID as 19.

Additional Information:
Extensive debugging steps performed:

Verified DNS resolution works correctly on the host, including under minimal environments (e.g., sudo env -i PATH=$PATH nslookup kms.us-east-1.amazonaws.com).

Verified system DNS configuration (/etc/resolv.conf) is correct and DNS queries respond successfully.

TCPDump trace shows that the proxy attempts to resolve the enclave CID as a hostname (19.ec2.internal), which NXDOMAINs in the VPC domain.

Tested with both empty allowlist and populated allowlist with valid KMS endpoints — both cause DNS lookup failures inside proxy.

Attempted using IP addresses in allowlist to bypass DNS lookup but DNS failure persists even with empty allowlist.

Confirmed enclave CID is correct (19), matching nitro-cli describe-enclaves output.

Attempted running proxy manually outside systemd as root and with minimal environment variables — issue persists.

Systemd environment and start delays verified; no resolution.

Impact:

The inability to bypass or avoid DNS lookup on CID or allowlist domains prevents the vsock-proxy from starting, blocking Nitro Enclaves usage in a standard AWS EC2 environment.


Environment:

  • Nitro Enclaves CLI version: 1.4.3
  • OS: Amazon Linux 2023
  • Instance region: us-east-1
  • Kernel: 6.1.150-174.273.amzn2023.x86_64

Please advise on workarounds or fixes to prevent vsock-proxy from attempting DNS lookup on the numeric CID and to ensure allowlist DNS resolution succeeds within the proxy context.


Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions