Tailscale Integration

Using Control D with Tailscale is very easy, this guide will show you how.

You can use Control D as a Global Nameserver in Tailscale, and take control of your DNS for your entire tailnet.

📘

Requirements

Every machine in your tailnet needs Tailscale 1.70 or later.

Create an Endpoint

In the Control D web panel, create an Endpoint. Select Server, then choose Tailscale as the Endpoint Type. One Tailscale Endpoint covers your whole tailnet.

In an Organization, set Connected Devices to the number of machines in your tailnet. The dialog reminds you of this when you choose the Tailscale type.

After you create the Endpoint, Control D opens the Tailscale setup guide. You can reopen it at any time from the Endpoint's Configure button. The first step shows the Resolver ID. This is the only value Tailscale needs, so copy it.

Configure Nameserver

  1. Open the DNS page of the Tailscale admin console.
  2. Go to Nameservers, then select Add nameserver > Control D.
  1. Paste your Resolver ID and select Save.
  1. Turn on Override DNS servers. With this on, every machine in your tailnet resolves through Control D instead of its local DNS settings.

Do not add another global nameserver beside Control D. Machines can send queries to the other nameserver, which bypasses your Control D Profile.

If your machines must resolve internal domains, see Local DNS and Override DNS Servers.

Using Exit Nodes

By default, a machine that uses a Tailscale exit node sends all of its DNS queries to the exit node. It ignores your global nameservers. While an exit node is selected, that machine's queries skip Control D, so your Profile is not applied and the queries do not appear in Analytics.

To keep machines on Control D when they use an exit node:

  1. Open the DNS page of the Tailscale admin console.
  2. In Nameservers, select the three dots next to the Control D nameserver.
  3. Turn on Use with exit node, then select Save.

You can also turn on Use with exit node when you first add the Control D nameserver.

Different Profiles per Device

By default, every machine in your tailnet uses the Profile of the Endpoint that you added as the global nameserver. To give specific machines a different Profile:

  1. Create a separate Control D Endpoint that enforces the Profile you want, and copy its Resolver ID.
  2. In your tailnet policy file, add a nodeAttrs entry. Set target to the machines it applies to (tags, users, groups, or *), and set attr to controld: followed by that Resolver ID.
{
  "nodeAttrs": [
    {
      "target": ["tag:server"],
      "attr": ["controld:RESOLVER_ID?priority=1"]
    },
    {
      "target": ["tag:secure-server"],
      "attr": ["controld:OTHER_RESOLVER_ID?priority=2"]
    }
  ]
}

If a machine matches more than one entry, the entry with the higher priority number wins. In this example, a machine tagged with both tag:server and tag:secure-server uses OTHER_RESOLVER_ID. Tailscale removes the ?priority=N suffix before it sends the Resolver ID to Control D.

Control D must stay configured as the global nameserver for these overrides to work.

Confirm it Works

The last step of the setup guide shows Awaiting DNS Change... until Control D receives queries from your tailnet. After that, the Endpoint changes to an active state.

Open Analytics to view the DNS logs.

Each machine in your tailnet appears as a separate Client, named by its Tailscale hostname, and you can filter the query data by each machine. Tailscale only shares machine hostnames with Control D.

Connected Devices

Connected Devices is the number of physical devices that send DNS queries through an Endpoint. For a Tailscale Endpoint, this is the number of machines in your tailnet, not 1. Update the count on the Endpoint when you add or remove machines.

Local DNS and Override DNS Servers

By default, devices in your tailnet prefer their locally configured DNS servers. Enabling Override DNS servers makes devices ignore those local DNS settings and use Control D as the global nameserver.

If you enable Override DNS servers and your devices must resolve internal domains, add the internal DNS server to Tailscale as a restricted nameserver:

  1. Open the DNS page in the Tailscale admin console.
  2. Select Add nameserver, then Custom.
  3. Enter the IP address of your internal DNS server.
  4. Enable Restrict to search domain.
  5. Enter the internal domain, such as corp.example.com, and save the nameserver.

Tailscale will send queries for that domain to the internal DNS server while continuing to send other queries to Control D. The internal DNS server must be reachable from the affected tailnet devices, either directly through Tailscale or through an advertised subnet route.

If you leave Override DNS servers disabled, devices continue to prefer their local DNS settings, so you usually do not need to add internal nameservers to Tailscale. However, Control D is not then forced for every DNS query.

Running ctrld on a Tailnet Machine

If you also run the Command Line Daemon on a machine in your tailnet, Tailscale and ctrld can compete over that machine's DNS settings. Use DNS Intercept Mode on Windows and macOS to avoid that conflict.

Troubleshooting

If a machine in your tailnet cannot reach websites or Control D policy does not apply:

  1. Connect by IP address first. Try to reach a known IP address from the machine. If that also fails, the problem is the network or Tailscale connection, not DNS.
  2. Check the Tailscale connection. Run tailscale status to confirm the machine is connected to your tailnet. Run tailscale ping <machine> to test the path to another machine, such as an exit node or subnet router.
  3. Check for an exit node. If the machine uses an exit node, make sure Use with exit node is on for the Control D nameserver. See Using Exit Nodes.
  4. Check the Activity Log. Open the Activity Log for the Tailscale Endpoint. If the machine's queries are missing, they are not reaching Control D. Check Override DNS servers and confirm there is no other global nameserver.
  5. Check the Status page. On the machine, open the Status page. Compare DNS Source IP with Proxy Source IP. If they are different and you use redirect rules, redirected sites can fail. See Proxy Source IP.

Did this page help you?