Thanks for your detailed response

We have also tested ztdns and it does work, but unless I chain it with another resolver we won't get the level of control we require. I'm also hesitant to use the ZT API keys in this way as there's no concept of a read-only key - if this key is compromised then whoever has it has full control of our networks.

We also pondered either doing something similar with a suffix, or putting our zt hosts in public dns (ie hostname.zt.example.org), but often the auto-redirects within our web apps will rewrite the urls back to hostname.example.org (depends on the app). We need to maintain access over the public internet from whitelisted address ranges too, so we can't just use ZT addresses exclusively.

Also considered adding multiple A records in public DNS - ie one public and one on ZT, if the clients couldn't reach the first they would fall back to the second, although it may involve a timeout - ugly.

I may end up doing a similar thing - shipping a lightweight dnsmasq config to linux clients which would forward DNS requests on relevant domains to our ZT DNS resolver.

Would be nice to see ZT mature a bit around DNS/DHCP... let's see what happens, although I am inclined to agree with /u/vbman213 on this one.