Cost-optimized private DNS across clouds

Use this guide when employees must open a private application by hostname while its containers, VMs, or load-balancer addresses can change. The recommended design separates three jobs:

1. private DNS tells the client the application’s current address;
2. Tunnex decides which identity may reach those addresses and ports; and
3. the application authenticates the user and authorizes actions inside the application.

For most Tunnex deployments, do not buy a global DNS service. Reuse an existing internal resolver when one is already reachable. Otherwise, run a restricted, suffix-only DNS proxy on the Tunnex gateway and forward queries to the cloud’s VPC/VNet-local resolver. The managed desktop installs the scoped resolver, so employees enter only the application hostname—not a DNS server address.

Choose a paid cloud-managed inbound resolver when its operational support, availability model, or compliance controls justify the recurring cost. Use a global, internet-reachable resolver only when DNS must work independently of the Tunnex tunnel.

The example below grants the Finance team access to one HTTPS application:

identity plane
  company IdP / directory
       └─ Finance people group
            └─ Tunnex rule: Finance → finance.apps.corp.example → TCP 443

DNS plane
  managed employee desktop
       └─ suffix-scoped resolver installed by Tunnex
            └─ WireGuard tunnel
                 └─ selected site gateway
                      └─ private DNS resolver
                           └─ private zone
                                └─ current A/AAAA answers

application plane
  managed employee desktop
       └─ WireGuard tunnel
            └─ gateway policy: current answer IPs, TCP 443 only
                 └─ dedicated private load balancer / service frontend
                      └─ changing tasks, pods, VMSS, MIG, or ASG instances

The control plane coordinates identity, resolver profiles, answer generations, and policy. It is not in the DNS or application packet path.

Create the Tunnex resource from the exact application hostname, not from a manually copied address. The selected gateway resolves that hostname through the configured private resolver. Tunnex refreshes bounded A and AAAA answers before their effective TTL expires and compiles the current answers as exact /32 or /128 destinations for the resource’s protocol and port.

A failed, stale, inconsistent, or excessive answer set is not broadened into a subnet. It is withdrawn from authorization. Existing last-good data can remain visible for diagnosis, but it is not used to grant traffic.

Prefer a private load balancer or private service endpoint in front of dynamic workers. The orchestrator can then add and remove tasks, pods, or VMs without changing the employee-facing hostname. Direct service-discovery answers also work when their entire answer set is routed and remains within Tunnex’s limits, but they create more policy churn and a larger failure surface.

Colocating the proxy with the selected Tunnex gateway usually adds no new host failure domain: if that gateway is unavailable, its application path is already unavailable. The proxy process, configuration, and cache remain monitored dependencies. This is not automatic multi-gateway DNS failover. Every FQDN resource is bound to one exact Site/Gateway resolver context. Generation history prevents deleting and recreating the same hostname. Rebinding the existing resource requires a controlled, fail-closed outage: delete every referencing rule, retire the old resolver configuration so its generation is no longer eligible, confirm the impact preview, update the resource context, wait for a new healthy generation, change and verify the cloud return route, then recreate the rules. A second gateway can protect ordinary Site/CIDR traffic more directly, but exact-FQDN failover is neither automatic nor zero-downtime. A stable managed resolver improves DNS endpoint availability, not this Tunnex context workflow.

Retiring a resolver configuration affects every FQDN resource that shares that Site/Gateway context. Inventory all of their rules and execute the migration as one coordinated outage.

Prices below were checked on 2026-09-04. They exclude taxes, data transfer, logging, support plans, private load balancers, and the Tunnex gateway itself. Always recalculate in the deployment’s region and billing agreement.

• AWS lists Route 53 Resolver endpoints at $0.125 per ENI-hour. An inbound endpoint requires at least two IPs, so its endpoint floor is about $0.25 per hour or $182.50 for 730 hours, plus endpoint queries and the private hosted zone. See Route 53 pricing.
• AWS Route 53 Global Resolver starts at $4.50 per hour without filtering or $5.00 per hour with filtering for the first two Regions. It is a different product from VPC Resolver and is not the cost baseline for a VPN. See Global Resolver concepts.
• Azure bills DNS Private Resolver inbound/outbound endpoints and forwarding rulesets on a prorated basis; this design normally needs only an inbound endpoint. Offers and regional prices vary. Check the current Azure DNS pricing page before selecting it instead of a gateway proxy.
• Google Cloud currently lists the first 25 Cloud DNS managed zones at about $0.20 per zone-month and regular queries at $0.40 per million. Its price page does not list a separate generic hourly inbound-policy endpoint SKU. See Cloud DNS pricing.

Use one exact hostname and one dedicated destination address/port for each network trust boundary. For example:

Keep these names in a private zone. Do not publish RFC1918 answers merely to make remote resolution work. Give every HTTPS hostname a certificate that matches the private name, and keep application SSO/MFA and authorization in place even when Tunnex denies network access by default.

Tunnex FQDN enforcement is destination IP, protocol, and port enforcement after DNS resolution. It does not inspect an HTTP Host header, TLS SNI, or a URL path.

If finance.apps.corp.example and hr.apps.corp.example resolve to the same load-balancer IPs on TCP 443, those names are the same layer-3/layer-4 destination. A user allowed to reach one can open a socket to the other. For a hard network boundary, give Finance a dedicated private load balancer/VIP or a different port. If applications share an ingress, require application-layer authorization such as OIDC and treat Tunnex as defense in depth.

Tunnex also cannot grant only /reports while denying /admin on the same hostname and port. That is an application or layer-7 proxy policy.

1. Associate a Route 53 private hosted zone with the workload VPC.
2. Point the application record at its dynamic private frontend. For ECS or an Auto Scaling group, prefer a private Route 53 Alias to an internal ALB/NLB; the load balancer registers and removes changing backends. See Route 53 Alias to ELB.
3. Run a small caching proxy such as CoreDNS, Unbound, or dnsmasq on the existing Tunnex gateway. Bind only private/tunnel-facing addresses and accept UDP and TCP 53 only from intended Tunnex sources.
4. Forward only the private suffix to AmazonProvidedDNS at 169.254.169.253 or the VPC +2 address from inside the VPC. AWS documents both addresses in Amazon DNS concepts.
5. Put the gateway proxy’s stable private IP in the selected Tunnex resolver profile. Do not give a remote client the VPC +2 address directly.

AWS explicitly says forwarding private DNS from another network directly to a VPC CIDR +2 address is unsupported and can be unstable. Use the in-VPC proxy or a supported inbound endpoint. See AWS hybrid DNS guidance.

Use a Route 53 VPC Resolver inbound endpoint when a managed hybrid-DNS path is worth its minimum two ENIs and query charges. Put its required IPs in different Availability Zones and allow UDP/TCP 53 only from the actual gateway or device-pool path. An associated private hosted zone needs no separate outbound Resolver rule.

For Tunnex desktop projection, select one reachable, monitored inbound address for the exact suffix, or place a tested stable resolver proxy/VIP in front of the provider addresses. Retain the other inbound address as a monitored manual cutover target. Putting both IPs into one Tunnex profile creates strict consensus, not primary/backup behavior.

Route 53 Global Resolver is appropriate only when authorized devices must resolve private and public names over internet-reachable anycast DNS without depending on Tunnex. It needs its own DNS views and access sources and still does not authorize the application data path.

1. Link the Azure Private DNS zone to the workload VNet and the gateway VNet when they differ.
2. Map the employee-facing name to a reserved private frontend on an internal Standard Load Balancer, private Application Gateway, or Private Endpoint. Put VM Scale Set, AKS, or other changing backends behind that frontend.
3. Run the suffix-only proxy on the existing Tunnex gateway and forward the Azure suffix to 168.63.129.16 from inside the VNet.
4. Use the gateway proxy IP—not 168.63.129.16—as the Tunnex resolver endpoint.

The Azure-provided resolver address is reachable only from inside an Azure VNet. Microsoft recommends either an in-VNet DNS-forwarder VM or an Azure DNS Private Resolver inbound endpoint for remote networks. See Azure private DNS troubleshooting and Private DNS zones.

Azure DNS Private Resolver provides an inbound endpoint IP in a dedicated delegated subnet. Use it when the managed availability and support model is more valuable than the endpoint charge. A static endpoint IP avoids a configuration change after endpoint recreation. An outbound endpoint and forwarding ruleset are not required merely to answer zones linked to the resolver VNet.

Review the current subnet restrictions and endpoint behavior in the Azure DNS Private Resolver overview.

1. Authorize the workload VPC network to use the Cloud DNS private zone.
2. Give the application a reserved private frontend on an internal Application or Network Load Balancer. Put managed instance groups, GKE, or other changing backends behind it.
3. Create a custom record in the private zone, or use the internal load balancer’s service-label DNS name when its generated name is acceptable. See internal load-balancer DNS names.
4. Run the suffix-only proxy on the Tunnex gateway and forward locally to the VM metadata resolver at 169.254.169.254. Google documents this resolver in internal DNS.
5. Configure the gateway proxy’s private IP in the Tunnex resolver profile.

A Cloud DNS inbound server policy creates regional internal entry points for a VPC network. It can be attractive when the customer already operates Cloud VPN, Cloud Interconnect, or Router Appliances. Entry points have network and regional constraints, are not reachable through ordinary VPC peering or NCC, and should be tested from the exact Tunnex gateway path before activation.

For a gateway VM in the same VPC, give its NIC an external IPv4 address or enable Private Google Access on its subnet so it can reach the inbound-forwarder entry points. VPC firewall rules do not apply to those entry-point IPs; Google accepts TCP and UDP 53 automatically, so constrain the networks that can reach the server-policy path. Entry-point IPs can change when inbound forwarding is disabled and re-enabled or the VPC is recreated. Monitor them and activate a new Tunnex resolver-profile version when they change.

Read Cloud DNS server policies and use DNS peering for private zones owned by another VPC where required.

If AD DNS, BIND, Infoblox, BlueCat, CoreDNS, or another internal resolver already answers the application suffix, reuse it. The endpoint must be a literal IP reachable from the selected gateway over an approved Site route and must accept both the configured DNS transport and TCP fallback.

Do not configure a public resolver for a private zone. Do not expose recursive DNS to the internet. Restrict the resolver firewall to the gateway and intended Tunnex device pool, rate-limit it, patch it, and monitor it like any other network control.

The complete product workflow is documented in FQDN access, end to end. The architecture-specific steps are summarized here.

Create one Tunnex Site for the cloud network and bind its gateway. Approve only the resolver and application frontend ranges that clients need. Ensure the cloud route table returns the Tunnex device pool through the gateway, enable cloud-NIC and guest-OS forwarding, and restrict workload firewalls to the intended gateway/device source.

Every possible A or AAAA answer must be inside an approved route. FQDN policy does not repair a missing route or return path.

Open Access Policies → Resources → FQDN → Private DNS resolvers, select the Site and gateway, and create a profile containing:

• one stable profile name;
• the most-specific private-zone suffix, without *.;
• the provider label for operator context; and
• a literal reachable endpoint on UDP 53, with TCP 53 verified. Add a TCP profile member only when you intend both transports to be consensus checks.

Provider selection does not connect Tunnex to the cloud account or create a zone. Query the endpoint directly from the gateway over UDP and TCP before activating the profile.

On Access Policies → Resources → FQDN, review and enable the organization FQDN enforcement setting. This opt-in allows resolver generations to run; without it, a new resource cannot become healthy. It is separate from global Zero Trust/default-deny enforcement, so keep global enforcement off while staging unless the organization already has reviewed baseline and recovery rules.

Create one resource for finance.apps.corp.example, protocol TCP, port 443, and select the Site/gateway resolver context. Confirm that the expected most-specific suffix is selected. Wait for Healthy, a current generation, and at least one active answer before creating an access rule.

Do not create a broad VPC CIDR resource as a shortcut. That would defeat the Finance-only requirement.

Create or directory-sync a Finance people group. Add one rule:

Finance people group → finance.apps.corp.example → TCP 443

Do not add a Site, whole-subnet, or “any port” grant for the same users. Use an expiry for temporary access and keep application-level SSO enabled.

Stage baseline rules and a break-glass recovery path before changing the organization from open mesh to default deny. Then follow Test and enforce policy:

1. review ordinary Site/CIDR rules needed for administration;
2. confirm the FQDN opt-in remains enabled;
3. verify the Finance rule reports an active FQDN generation;
4. enable global Zero Trust enforcement in a controlled change window; and
5. wait until the gateway applies the new policy revision.

The FQDN opt-in and global Zero Trust enforcement are separate controls. A healthy resource with global enforcement off does not restrict the open mesh.

For strict identity-scoped FQDN access, an eligible FQDN rule derives the resolver carriage required by that user’s managed desktop. A broad Site DNS forward is not required merely to create the Finance rule.

Add a Site DNS forward only when every intended connected client should receive that private suffix, or when using open-mode/CIDR access that has no eligible FQDN rule. DNS visibility is not application authorization.

The suffix-scoped desktop resolver controls which queries native applications send to that resolver; Tunnex does not inspect or filter the DNS QNAME. A user who can reach the resolver IP can explicitly query any other zone that resolver answers. When DNS namespace confidentiality matters, use a dedicated DNS view or a suffix-only gateway proxy that refuses unrelated names. Avoiding an unnecessary broad Site forward reduces automatic namespace projection but is not a QNAME security boundary.

If a Site DNS forward and an FQDN resolver profile own the same suffix, point both at the same resolver IP. Tunnex fails closed instead of guessing between conflicting authorities.

Test from real managed desktops, not only from a control-plane badge.

From a Finance member’s connected device:

export PRIVATE_ZONE="apps.corp.example"
export APP_FQDN="finance.apps.corp.example"
export RESOLVER_IP="10.20.0.53"

# Endpoint health: explicit UDP and TCP queries.
dig +short @"$RESOLVER_IP" "$APP_FQDN" A
dig +tcp +short @"$RESOLVER_IP" "$APP_FQDN" A

# macOS native scoped resolver and application path.
scutil --dns | grep -A 8 -B 2 "$PRIVATE_ZONE"
dscacheutil -q host -a name "$APP_FQDN"
curl --fail --show-error --max-time 10 \
  -o /dev/null -w 'status=%{http_code} remote_ip=%{remote_ip}\n' \
  "https://${APP_FQDN}/"

The resolved address and resolver must route over a Tunnex interface. The application must present the expected TLS certificate and authenticate the user.

On macOS, plain nslookup or unqualified dig can query the default Wi-Fi DNS server and bypass a suffix-scoped /etc/resolver entry. An NXDOMAIN from that server does not prove Tunnex DNS is broken. Use scutil, dscacheutil, and the real application for native proof; use nslookup "$APP_FQDN" "$RESOLVER_IP" only as an explicit endpoint test.

On Windows, inspect the effective NRPT rule, then use Resolve-DnsName and the real HTTPS client. Static WireGuard files and clients that do not consume managed Tunnex DNS updates are not equivalent tests.

Record all of these before calling the rollout complete:

• the same Finance user cannot connect to the resource on an ungranted port;
• a user outside Finance cannot connect to the Finance application;
• the Finance user cannot connect to a sibling hostname with a different destination; and
• removing the user from Finance or disabling the rule withdraws access after the gateway applies the new policy.

Review Tunnex access events and application identity logs so a DNS failure is not mistaken for a policy denial.

• Use a private suffix owned by the company. Avoid .local, which conflicts with multicast DNS on common clients.
• Give different clouds or trust boundaries unambiguous subdomains, such as aws.apps.corp.example, azure.apps.corp.example, and finance.apps.corp.example.
• Keep authoritative TTLs long enough to avoid unnecessary churn but short enough for the service’s real failover objective. Confirm Tunnex has accepted the new generation before removing an old answer.
• Monitor resolver reachability over UDP and TCP, FQDN resource state, answer count, generation age, gateway health, and the application itself.
• Treat profile changes as versioned network changes. Lower TTL in advance, prove the new resolver, activate it, verify clients, then retire the old path.
• Do not use multiple profile endpoints as a failover list. A disagreement or timeout intentionally withdraws authorization.
• Treat a second gateway as direct recovery for ordinary Site/CIDR routes. For an exact-FQDN resource with generation history, document and rehearse the fail-closed rule-removal, resolver-retirement, impact-preview, context-rebind, new-generation, return-route, and rule-recreation workflow.
• Keep browser secure-DNS policy compatible with company private DNS. A browser that bypasses the operating-system resolver can return public or negative answers even while native split DNS is healthy.
• Use the provider’s managed resolver when DNS operations, service guarantees, or multiple non-Tunnex consumers cost more to support than the endpoint fee.

• Exact private hostname and TLS certificate are owned by the company.
• Each hard security boundary has a distinct private destination or an explicit layer-7 authorization control.
• Dynamic workers sit behind a private frontend or a bounded, routed service-discovery answer set.
• The private zone is linked or authorized to the gateway’s cloud network.
• The resolver listens on UDP and TCP 53 and is not public recursion.
• Resolver and all workload answers are inside approved Tunnex routes.
• Device-pool return routes point to the gateway.
• The resolver profile matches the most-specific intended suffix.
• The exact FQDN resource is healthy with a current generation.
• The people group and narrow protocol/port rule are correct.
• Baseline administration and recovery rules exist before default deny.
• FQDN opt-in is enabled before waiting for a healthy generation; global enforcement is enabled only after the rule and recovery path are ready.
• Exact-FQDN recovery is documented as a controlled fail-closed context rebind, not automatic or zero-downtime gateway failover.
• Positive and negative tests use real managed clients.
• DNS, gateway, access-event, and application monitoring have owners.

For provider-specific implementation, continue with the AWS default VPC walkthrough, Azure private VM walkthrough, Routed ranges and private DNS, and FQDN access, end to end.