Discussions

The docs/README indicate that the ctrld router daemon supports split horizon DNS. This seems to work by allowing the normal DNS server on 53 (dnsmasq, unbound) to handle queries as normal, and then setting the daemon as upstream and using NAT / iptables rules to block bypasses. This works reasonably well out-of-the-box.

However, roaming devices will often have the ControlD endpoint configured for off-network protection. When they return to their ctrld-daemon protected home network, the router will allow the client to directly reach ControlD. This means that the local resolver does not have a chance to inject split-horizon records, and things like firewall[.DNS_SUFFIX.LOCAL] or Plex.MySplitDNS.Zone will break. On UniFi networks in particular, this also breaks WifiMan scanning.

The docs note the existence of the Control D Bypass folder or the ability to manually mirror local records to the cloud, but this is error-prone and high-effort.

Further, this does not address situations where I may want e.g. plex.MyDomainName.co to "just work" wherever I am, even if I am using OS-native DoH because mirror records for RFC1918 addresses will of course fail and the OS cannot handle the bypass folder. I need the resolver to return the private addresses only when I am on the same network served by the ctrld router endpoint, and the public address otherwise.

All of this is "expected" based on the reasonable design criteria, but it would be nice to have some configuration options to simplify it. Some ideas:

Automatic Mirror / Bypass sync toggle

Router endpoints could have a toggle to enable the router daemon to automatically synchronize local records (or the default DNS suffix) to either the Control D Bypass list, or to a special split-horizon local-zone / zoneScope / bind view. If the cloud resolver believes the client is on-network, it could return results preferentially from that split zone instead.

This has the major benefit that it requires no coordination from a managed client-- it will work across any software or OS using that control D resolver endpoint.

Cloud / Client awareness of ctrld router

The control plane and / or the client should be able to determine that a managed endpoint is on a network served by a managed router in the same tenant. This could allow either the resolver or the managed agent to change behavior, such as the resolver returning "split" records or the managed client defaulting to the local resolver instead. Possibilities:

1. resolve verify.controld.com (CNAME <instance>.verify.controld.com) both via OS resolver and ctrld agent, and seeing if they match,
2. Simple check if public IP is the same
3. Have the router agent publish known suffixes (could be used both for discovery and automatic bypass)

Some approaches may have narrow implications for a downgrade attack but could be hidden behind a toggle.

Automatic exemption of default suffix

Managed endpoints could have a toggle to automatically exempt / use the local resolver for the default domain suffix (within reason: as long as it is not "com"). Perhaps this could be subject to some criteria like "only enables when the suffix is nxdomain", which avoids security issues while still covering the 80% use case

Thanks in advance.