How app connectors work

This feature is currently in beta. To try it, follow the steps below to enable it for your network using Tailscale v1.54 or later.

App connectors are available for all plans.

App connectors allow you to route application-specific traffic from your tailnet through a selected device that serves as an app connector. All tailnet traffic for that app goes through the app connector before routing it to the application domains. An app connector works by proxying DNS queries for the app's domains. They also advertise the subnet routes for the observed DNS results. Like a subnet router, traffic routes to the app connector from your tailnet devices before egressing to any IPs advertised by the application domains. An app connector is like an automatic subnet router for applications that you configure using domains instead of IP addresses.

For all tailnet devices, domains set to route through an app connector always do so. Tailscale routes traffic to apps through app connectors even if the device uses an exit node. Users can disable the accept routes setting on their Tailscale client. This will stop sending app traffic through the app connector.

Configure apps for route discovery

You can configure apps for route discovery using domains, CNAME records, or wildcards.

Domains

You can configure apps with a list of valid, fully qualified domain names (FQDN). Tailscale routes DNS routing records like A and AAAA through app connectors.

App connectors begin automatic route discovery after you add a domain. If you haven't pre-configured any routes, app connectors will start a learning period. During the learning period, the app connector proxies DNS requests as end-users request configured domains. It identifies routing records and adds them as advertised routes to each app connector. With auto approval enabled, the discovered routes are immediately advertised and updated on all tailnet devices. This routes traffic through the app connector (for the local region if using regional routing). The learning period continues until the app connector discovers all routes. For smaller domains, this takes minimal time. It might take longer for large domains or domains with wildcards.

DNS lookups

App connectors work by acting as the authoritative nameserver for the domains configured on an app. For example, when you configure an app for a domain (such as *.example.com), it creates a split DNS entry. Tailscale sends any subsequent DNS lookups for *.example.com to the appropriate app connectors. Each app connector performs the DNS lookup. If the lookup succeeds, it introduces a new subnet route for the resolved IP address before returning the response to the device that initiated the DNS lookup.

`CNAME` records

For CNAME records, which are not routing records, app connectors follow the CNAME chain and automatically advertise the resulting routes. You can use a command like dig to check if your domain uses a CNAME. The output will look like:

.1. app.acme.com IN CNAME acme.backend.com
.2. acme.backend.com A ...

In the above example, the target of the CNAME chain, acme.backend.com, will be used for route advertisement instead of app.acme.com.

If a web service uses geographic DNS load balancing, CNAME records might return different results in different locations. In these cases, it's best practice to deploy your app connectors in locations that closely mirror your organization's global footprint.

Wildcards

App connectors support using wildcards (*). Wildcard behavior is non-inclusive of the parent domain. For example, to include all of acme.com and its subdomains, use both acme.com and *.acme.com. To only include the top-level domain, include acme.com and omit *.acme.com. To include only subdomains, include *.acme.com and omit acme.com.

ACL driven route configuration

You can manually pre-configure routes in the access control lists (ACLs) section of your tailnet policy file alongside the domain configuration. For example:

{
    "name": "example-app",
    "connectors": ["tag:example-connector"],
    "domains": ["example.com"],
    "routes": ["192.0.2.0/24"],
}

Effective with Tailscale v1.60.0 for stable tracks and v1.59.43 for unstable tracks, app connector devices automatically advertise these routes as soon as you apply the ACL change to the tailnet policy file. App connectors for the app will immediately advertise these routes and routes added using the ACL section of the tailnet policy file are implicitly approved and do not require a sibling autoApprovers entry.

This maintains strict routing control as part of the ACL and approval process. In many instances, this also removes the need for users to build up large --advertise-routes arguments for device configurations to avoid lengthy discovery periods with disruptive routing changes.

Route coalescing

Routes populated by ACL driven route configuration coalesce or replace routes that are a sub-route of the new advertisement. For example, if the app connector previously discovered 198.51.100.0/24 and 203.0.113.0/24, and you adjusted the routes ACL to cover 192.0.2.0/24, the resulting route table for the app connector resolves to 192.0.2.0/24. This is to minimize routing table length and complexity.