> ## 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. # Configure DNS for Azure Private Link This page describes how to configure DNS so your dedicated instance hostname (`.privatelink.unstructuredapp.io`) resolves to the private IP of your Azure Private Endpoint. This step happens after you create your Private Endpoint as part of [onboarding](/business/azure/azure-privatelink/onboarding-di-pl). 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 | | ---------------------------------------------------------------------- | --------------------------------------------- | | Azure DNS (Azure Private DNS Zones) | [You use Azure DNS](#you-use-azure-dns) | | An internal DNS system such as Infoblox, BIND, or Active Directory DNS | [You use your own DNS](#you-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 `.privatelink.unstructuredapp.io` are forwarded to your configured DNS system and not resolved independently by the ZTN. ## You use Azure DNS This is the simplest setup if you already use Azure DNS in your subscription. ### In-VNet clients When you create your Private Endpoint, select **Integrate with private DNS zone** and choose or create an Azure Private DNS Zone named `privatelink.unstructuredapp.io`. Azure automatically creates an A record in the zone that resolves your dedicated instance hostname to the Private Endpoint's private IP. Link the zone to every VNet that needs access. No additional DNS configuration is needed. For more on automatic registration, see [Private Endpoint DNS integration scenarios](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration). ### On-premises clients (ExpressRoute or VPN) The Private DNS Zone integration in the previous section only works for clients inside a linked VNet. If you have on-premises clients reaching the platform over ExpressRoute or a VPN, bridge your on-premises DNS to Azure DNS with an [Azure DNS Private Resolver](https://learn.microsoft.com/en-us/azure/dns/dns-private-resolver-overview) inbound endpoint and a conditional forwarder. This assumes you already have a private network connection (ExpressRoute or VPN) between your on-premises network and your VNet, and that the Private DNS Zone is linked to the VNet that hosts the Private Resolver. 1. **Create an Azure DNS Private Resolver inbound endpoint.** In the Azure portal, go to **DNS Private Resolvers**, create a resolver in the VNet linked to the Private DNS Zone, then add an **inbound endpoint** in a dedicated subnet. Azure assigns the endpoint a private IP (for example, `10.0.10.4`). Note this IP. 2. **Add a conditional forwarder on your on-premises DNS.** Forward queries for `privatelink.unstructuredapp.io` to the inbound endpoint IP. Forwarding the parent zone covers `.privatelink.unstructuredapp.io` and all subdomains (for example `api..privatelink.unstructuredapp.io`) automatically — no per-instance rules are needed. Examples for common DNS systems: * **Windows DNS Server / Active Directory DNS:** Open **DNS Manager → Conditional Forwarders → New Conditional Forwarder**. Enter `privatelink.unstructuredapp.io` as the DNS Domain and add the inbound endpoint IP. * **BIND:** Add the following to `named.conf`, then run `rndc reload`: ```text theme={null} zone "privatelink.unstructuredapp.io" { type forward; forward only; forwarders { 10.0.10.4; }; }; ``` * **Infoblox:** Go to **Data Management → DNS → Forward Zones → Add**. Enter `privatelink.unstructuredapp.io` as the zone name and add the inbound endpoint IP as the forwarder. 3. **Validate** from an on-premises client. See [Validation](#validation). ## You use your own DNS If your authoritative DNS is something other than Azure DNS — for example, Infoblox, BIND, or Active Directory DNS — this is the recommended path. The same records serve clients in your VNet, on-premises clients reaching the platform over ExpressRoute or VPN, and laptops routed through a Zero Trust Network. There is no separate setup per client location, and no Azure DNS Private Resolver is required. Unstructured cannot create these records for you because your Private Endpoint and its private IP live in your subscription. **VNet workloads must use your internal DNS.** This setup only works for in-VNet clients if your VNet is configured with custom DNS servers that point to your internal DNS, instead of using Azure-provided DNS (`168.63.129.16`). Set the VNet's **DNS servers** to your internal DNS server IPs. Without this change, VMs and other in-VNet workloads will use the Azure-provided resolver, which has no knowledge of your internal records and will not resolve the hostname correctly. If your internal DNS servers need to resolve other Azure-internal hostnames, they must forward unresolved queries to `168.63.129.16`. Otherwise, Azure-internal resolution will break for those workloads. ### Recommended: A records to the Private Endpoint's private IP Add an apex and wildcard A record on a per-dedicated-instance zone in your internal DNS. The records resolve directly to the Private Endpoint's private IP. The wildcard ensures all current and future subdomains — for example `api.` and `platform-api.` — resolve without additional DNS changes. Example records for a Private Endpoint with private IP `10.0.5.12`: | Record | Type | Target | | ------------------------------------------------ | ---- | ----------- | | `.privatelink.unstructuredapp.io` | A | `10.0.5.12` | | `*..privatelink.unstructuredapp.io` | A | `10.0.5.12` | An Azure Private Endpoint has a single primary private IP per region. A TTL of 300 seconds is recommended. Find the Private Endpoint's private IP in the Azure portal: open the Private Endpoint resource, go to **DNS configuration**, and read the **IP addresses** column. ### 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: * `-dev.privatelink.unstructuredapp.io` → A records pointing at the dev instance's Private Endpoint IP * `-staging.privatelink.unstructuredapp.io` → A records pointing at the staging instance's Private Endpoint IP * `-prod.privatelink.unstructuredapp.io` → A records pointing at the prod instance's Private Endpoint IP 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: ```bash theme={null} dig .privatelink.unstructuredapp.io dig api..privatelink.unstructuredapp.io ``` On Windows, use `nslookup` instead of `dig`. Both queries should return private IP addresses within your VNet CIDR range. If they return public IP addresses or fail to resolve, see [Troubleshooting](#troubleshooting). ## Troubleshooting | Problem | Likely cause | What to check | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `dig` returns public IP addresses | The client is querying public DNS instead of the DNS system you configured | Confirm the client's resolver settings; confirm your internal DNS is authoritative for `privatelink.unstructuredapp.io` (own-DNS setup) or that your conditional forwarder is in place (Azure DNS + on-premises setup) | | `dig` returns NXDOMAIN | The records are missing, or the client cannot reach your DNS | Confirm the records exist in your DNS system and that the client can reach your DNS resolvers | | Resolution works in the VNet but fails from on-premises (Azure DNS setup) | The Private Resolver inbound endpoint or on-premises conditional forwarder is misconfigured | Confirm the inbound endpoint is healthy, that the VNet hosting the resolver is linked to the Private DNS Zone, and that the conditional forwarder targets the parent zone `privatelink.unstructuredapp.io` (not the full instance hostname) | | Resolution works from on-premises but fails for in-VNet clients (own-DNS setup) | VNet workloads are using Azure-provided DNS instead of your internal DNS | Update the VNet's **DNS servers** setting to point to your internal DNS server IPs | | Other Azure-internal hostnames fail to resolve after switching to custom DNS | Your internal DNS server is not forwarding unresolved queries to `168.63.129.16` | Configure your internal DNS to forward unresolved queries to `168.63.129.16` | | TLS handshake fails after DNS resolves to a private IP | The client is connecting to a hostname not covered by the provider-managed certificate | Confirm the client is connecting to a hostname under `.privatelink.unstructuredapp.io` | ## Questions? Need help? Contact your Unstructured account team or open a ticket in the [Unstructured Support Portal](https://support.unstructured.io/).