Routed ranges and private DNS

Routed ranges is the read-only network map produced from approved sites, device pools, Kubernetes VIPs, and DNS ownership. Use Sites to approve or remove pending LAN ranges.

Open Routed ranges and let every section finish loading before drawing a conclusion.

Check:

• every approved site range has the expected owner;
• the device pool does not overlap a site or service range;
• pending ranges are handled under Sites;
• Kubernetes VIP ranges are distinct from Service and device pools; and
• resolver ownership follows the intended site/gateway path.

If one backing request fails, treat the map as incomplete—not as proof that a CIDR is unused.

Open Access Policies → Resources, select FQDN, then choose a Site and Gateway under Private DNS resolvers.

Select Edit profiles. The dialog is titled Activate new DNS profile version.

For each profile:

1. Enter Profile name.
2. Choose Provider: AWS, Microsoft Azure, Google Cloud, or On-premises.
3. Enter comma-separated DNS zone suffixes without wildcards.
4. Add one or more endpoint IPs.
5. Choose UDP or TCP and port, normally 53.
6. Select Activate profiles only after checking the displayed resolver path.

Most-specific suffix wins. Profiles are not fallbacks for one another. If no suffix matches, Tunnex fails closed and sends no DNS query.

The resolver endpoint must be reachable from the selected gateway. Provider selection documents context only; Tunnex does not discover cloud accounts, private zones, or resolver endpoints.

1. Under Resources, select Create resource.
2. Select Create FQDN resource.
3. Enter a stable Name.
4. Enter one Exact hostname, such as orders.internal.example.com.
5. Optionally add a description.
6. Choose protocol and, when shown, the narrowest required port scope.
7. Choose the site and gateway providing the private DNS path.
8. Confirm the most-specific resolver preview, then select Create resource.

An unmatched name remains unconfigured/fail-closed. A newly configured name may show resolving until the gateway reports the server-projected answer.

For a static network destination, choose Create CIDR resource instead.

Enter Name, optional description, CIDR, protocol, and port range. Changing a resource later changes the destination every referencing rule can reach, so run Test access again after edits.

From a connected client, query the exact name and the selected resolver path:

getent hosts orders.internal.example.com
dig orders.internal.example.com

If resolution fails, verify in order:

1. the FQDN resource hostname is exact and normalized;
2. a suffix profile matches it;
3. the site/gateway path is active;
4. the resolver IP lies on an approved reachable route;
5. UDP/TCP 53 is allowed end to end; and
6. the authoritative private DNS server has the record.

DNS success does not grant traffic. A separate access rule must allow the subject to reach this resource.