DNS Problems with internal services and DNS rebinding protection

Some DNS servers have a feature called DNS rebinding protection. This can prevent a particular type of security issue but can impact the ability to access your internal services, particularly those hosted behind a subnet router using private (RFC1918: 192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/12) IP addresses. Some DNS servers may also apply this policy to the Tailscale IP range (RFC6598: 100.64.0.0/10, sometimes called the CGNAT IP range).

How does DNS rebinding protection work

DNS servers that have DNS rebinding protection enabled will block DNS responses that include a private IP address. On the public Internet, that does not cause any problems because public websites do not use private IP addresses. When accessing devices on your private network, this becomes an issue if the DNS names of those devices are visible to public DNS servers because sometimes those DNS responses will be blocked.

How does DNS rebinding protection affect Tailscale

When accessing internal services over Tailscale, it may be convenient to use DNS names. For example, imagine an internal dashboard located at dashboard.internal.example.com which uses an address of 10.0.0.1. 10.0.0.1 is a private IP address and can not be reached over the public Internet. If that IP address is shared with your tailnet using a subnet router, then members of your tailnet can easily access the dashboard using its name. Great!

Unfortunately, if someone on your tailnet tries to load dashboard.internal.example.com from their home, and their home router or ISP has DNS rebinding protection enabled, the internal dashboard will not be accessible.

MagicDNS is not affected by DNS rebinding protection, as it works entirely within the Tailscale client and no external DNS server is involved.

Workarounds to consider when using Tailscale

1. Use the Tailscale DNS configuration to configure a restricted nameserver (also known as split DNS) to send DNS requests for just the domain name of your internal service to a DNS server you control.

   In the above example, configuring internal.example.com to use an internal DNS server (either directly on the tailnet with a 100.x.y.z address or through a subnet router with a 10.a.b.c address) could be a reasonable approach. This also makes it harder for someone to discover what names are in use within your network (which does not necessarily improve security, but is also unlikely to hurt security).

   If you do not want to host this domain on an internal DNS server, then you can configure internal.example.com to use a public DNS server, such as Google Public DNS, Cloudflare Public DNS, or Quad9.

2. Configure the problematic DNS server to not perform DNS rebinding protection on the particular domain name (for example, internal.example.com). You will have to consult your router or DNS server instructions to determine if you can exclude domain names from DNS rebinding protection.

3. Disable DNS rebinding protection entirely. You will have to consult your router or DNS server instructions for the required steps.

4. Reconfigure your computer to use a public DNS service that does not include DNS rebinding protection. For example, Google Public DNS, Cloudflare Public DNS or Quad9.

5. Use the Tailscale DNS configuration with the 'override local DNS' option enabled to send all DNS queries (other than MagicDNS or domain names configured to use specific nameservers) to a public DNS service that does not include DNS rebinding protection. This is similar to the previous option but applies to the entire tailnet.