Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.unstructured.io/llms.txt

Use this file to discover all available pages before exploring further.

This page describes how to configure DNS so your dedicated instance hostname (<companyname>.privatelink.unstructuredapp.io) resolves to the private IPs of your AWS PrivateLink VPC Endpoint. This step happens after you create your VPC Endpoint as part of onboarding. Clients must connect using the dedicated instance hostname because TLS is terminated using a provider-managed certificate. The two most common setups are below — choose the one that matches your authoritative DNS.

​
Choose your setup

Your authoritative DNS is…Go to
Amazon Route 53You use Route 53
An internal DNS system such as Infoblox, BIND, or Active Directory DNSYou use your own DNS
A Zero Trust Network (such as Zscaler) is a network path, not a DNS authority. Clients connecting through a ZTN still resolve DNS through whichever DNS system you use, so the section that matches your authoritative DNS already covers them. Note that some ZTN configurations intercept or proxy DNS queries — if your ZTN performs DNS interception, verify that queries for <companyname>.privatelink.unstructuredapp.io are forwarded to your configured DNS system and not resolved independently by the ZTN.

​
You use Route 53

This is the simplest setup if you already use Route 53 in your AWS account.

​
In-VPC clients

When you create your VPC Endpoint, enable the Enable private DNS name option. The Amazon-provided DNS resolver in your VPC will then return the endpoint’s private IPs whenever clients query your dedicated instance hostname. No additional DNS configuration is needed. (Note: this resolution is handled by the VPC resolver — you will not see a corresponding private hosted zone in the Route 53 console.) This requires DNS hostnames and DNS resolution to be enabled on your VPC. See VPC DNS attributes.

​
On-premises clients (Direct Connect or VPN)

The private DNS resolution configured in the previous section only works from inside your VPC. If you have on-premises clients reaching the platform over Direct Connect or a VPN, bridge your on-premises DNS to Route 53 with a Resolver inbound endpoint and a conditional forwarder. This assumes you already have a private network connection (Direct Connect or VPN) between your on-premises network and your VPC.
  1. Create a Route 53 Resolver inbound endpoint. In the AWS console, go to Route 53 → Resolver → Inbound endpoints, and create an endpoint with at least two ENIs in different Availability Zones in your VPC. Note the IP address of each ENI (for example, 10.0.1.10 and 10.0.2.10). The endpoint’s security group must allow inbound TCP and UDP traffic on port 53 from your on-premises network.
  2. Add a conditional forwarder on your on-premises DNS. Forward queries for <companyname>.privatelink.unstructuredapp.io to the Resolver inbound endpoint IPs. This forwarding rule covers all subdomains (for example api.<companyname>.privatelink.unstructuredapp.io) automatically — no additional rules are needed per subdomain. Customers with multiple dedicated instances configure one conditional forwarder per dedicated instance.
Examples for common DNS systems:
  • Windows DNS Server: Open DNS Manager → Conditional Forwarders → New Conditional Forwarder. Enter <companyname>.privatelink.unstructuredapp.io as the DNS Domain and add both Resolver IPs.
  • BIND: Add the following to named.conf, then run rndc reload: 
    zone "<companyname>.privatelink.unstructuredapp.io" {
    type forward;
    forward only;
    forwarders { 10.0.1.10; 10.0.2.10; };
};
  • Infoblox: Go to Data Management → DNS → Forward Zones → Add. Enter <companyname>.privatelink.unstructuredapp.io as the zone name and add both Resolver IPs as forwarders.
  1. Validate from an on-premises client. See Validation.

​
You use your own DNS

If your authoritative DNS is something other than Route 53 — for example, Infoblox, BIND, or Active Directory DNS — this is the recommended path. The same records serve clients in your VPC, on-premises clients reaching the platform over Direct Connect or VPN, and laptops routed through a Zero Trust Network. There is no separate setup per client location, and no Route 53 Resolver inbound endpoint or conditional forwarder is required. Unstructured cannot create these records for you because your VPC Endpoint and its private IPs live in your account.
VPC instances must use your internal DNS. This setup only works for in-VPC clients if your VPC instances are configured to query your internal DNS server rather than the default Amazon-provided resolver. Update your VPC’s DHCP option set to point to your internal DNS server IPs. Without this change, EC2 instances and other in-VPC workloads will use the Amazon resolver, which has no knowledge of your internal records and will not resolve the hostname correctly.
Add an apex and wildcard A record on a per-dedicated-instance zone in your internal DNS. The records resolve directly to the VPC Endpoint’s private IPs. The wildcard ensures all current and future subdomains — for example api. and platform-api. — resolve without additional DNS changes. Example records for a VPC Endpoint with ENIs at 10.0.5.12 and 10.0.6.12:
RecordTypeTarget
<companyname>.privatelink.unstructuredapp.ioA10.0.5.12, 10.0.6.12
*.<companyname>.privatelink.unstructuredapp.ioA10.0.5.12, 10.0.6.12
A VPC Endpoint creates one ENI per Availability Zone, so most dedicated instances have two or three private IPs. List all of them on each record — DNS round-robins across them, giving you per-AZ failover. A TTL of 300 seconds is recommended. Find the VPC Endpoint’s private IPs in the AWS console: open the VPC Endpoint, go to the Subnets tab, and read the IPv4 addresses column for each ENI.

​
Multiple dedicated instances

Customers with multiple dedicated instances configure a separate zone per dedicated instance. For example, a customer with development, staging, and production instances configures:
  • <companyname>-dev.privatelink.unstructuredapp.io → A records pointing at the dev instance’s VPC Endpoint private IPs
  • <companyname>-staging.privatelink.unstructuredapp.io → A records pointing at the staging instance’s VPC Endpoint private IPs
  • <companyname>-prod.privatelink.unstructuredapp.io → A records pointing at the prod instance’s VPC Endpoint private IPs
This avoids claiming the entire privatelink.unstructuredapp.io namespace on your internal DNS and lets you connect to additional dedicated instances later without conflicts.

​
Validation

From within the target network, run the following: 
dig <companyname>.privatelink.unstructuredapp.io
dig api.<companyname>.privatelink.unstructuredapp.io
Both queries should return private IP addresses within your VPC CIDR range. If they return public IP addresses or fail to resolve, see Troubleshooting.

​
Troubleshooting

ProblemLikely causeWhat to check
dig returns public IP addressesThe client is querying public DNS instead of the DNS system you configuredConfirm the client’s resolver settings; confirm your internal DNS is authoritative for <companyname>.privatelink.unstructuredapp.io (own-DNS setup) or that your conditional forwarder is in place (Route 53 + on-premises setup)
dig returns NXDOMAINThe records are missing, or the client cannot reach your DNSConfirm the records exist in your DNS system and that the client can reach your DNS resolvers
Resolution works in the VPC but fails from on-premises (Route 53 setup)The Route 53 Resolver inbound endpoint or on-premises conditional forwarder is misconfiguredConfirm the inbound endpoint has at least two ENIs in different AZs, that its security group allows port 53 from your on-premises network, and that the conditional forwarder points at the inbound endpoint’s ENI IPs
Resolution works from on-premises but fails for in-VPC clients (own-DNS setup)VPC instances are using the Amazon resolver instead of your internal DNSUpdate the VPC’s DHCP option set to point to your internal DNS server IPs
TLS handshake fails after DNS resolves to private IPsThe client is connecting to a hostname not covered by the provider-managed certificateConfirm the client is connecting to a hostname under <companyname>.privatelink.unstructuredapp.io

​
Questions? Need help?

Contact your Unstructured account team or open a ticket in the Unstructured Support Portal.