Config option to prevent zeronsd from changing Central's DNS settings

[aplum]

Feature request

In our environment, we'd like ZT Central to be configured with a different search domain and DNS server address than zeronsd. Currently, zeronsd changes Central's config to match its own at startup. Could a config option be added to zeronsd to prevent this behaviour? Something like --no-auto-config-central or --auto-config-central=false.

I've never used Rust before, but I'd be willing to attempt a PR if this feature's accepted. Looks like it would just require adding a flag/config option, and a condition around this call?

Our use case / environment

Our environment is as follows:

• Networks:
  • Multiple offices connected with site-to-site VPNs (Networks of 192.168.1.0/24, 192.168.2.0/24).
  • Remote access VPN for devices outside the offices (192.168.3.0/24).
  • One ZeroTier network deployed on some clients, to fill some gaps where our main RA VPN isn't sufficient (192.168.4.0/24).
• A Debian VM with net.ipv4.ip_forward=1 (per these docs) on a separate network 192.168.111.0/24 in an office, joined to ZeroTier. ZeroNS is installed on this VM. IPs are 192.168.4.1 and 192.168.111.2.
• Appropriate routing configured between all the networks.
• Main DNS servers are on the office networks (192.168.1.2, 192.168.2.2).
• Main search domain: sub.company.tld (e.g. client1 would be client1.sub.company.tld).
• ZeroNS domain: zt.sub.company.tld (e.g. client1 – if it's on ZeroTier – would also exist at client1.zt.sub.company.tld).
• Our main DNS server delegates the zt.sub.company.tld zone to ZeroNS (using the IP 192.168.4.1, since ZeroNS doesn't listen on the VM's non-ZeroTier address).

In ZT Central, we want to use sub.company.tld and 192.168.1.2 (main DNS server).

The problem is that ZeroNS changes Central's config to zt.sub.company.tld and 192.168.4.1. So if I'm on client1 on ZeroTier and want to ping server1, it will try to ping server1.zt.sub.company.tld, but server1 isn't on ZeroTier so this won't work.

Of course, if we want to ping a zerotier client we'll need to use its FQDN of client1.zt.sub.company.tld. Slightly inconvenient, but an acceptable tradeoff; we may decide to add zt.sub.company.tld to our search domain list in the future, but currently it looks like Central only supports setting a single search domain, so we'd be back to things behaving differently on ZT clients unless Central adds support for multiple domains.

Current workaround

For anyone interested, my current workaround is to change Central's config when the ZeroNS VM reboots. Just a crontab entry of @reboot /path/to/fix-zt-central-dns.sh, with fix-zt-central-dns.sh as follows:

#!/bin/bash

sleep 30
curl --no-progress-meter \
    --request POST \
    --url https://api.zerotier.com/api/v1/network/$MY_NETWORK_ID \
    --header "authorization: token $(< /path/to/zt_central_token)" \
    --header "content-type: application/json" \
    --data '{ "config": { "dns": { "domain": "sub.company.tld", "servers": ["192.168.1.2", "192.168.2.2"] } } }' > /dev/null

(This could be improved by running whenever zeronsd (re-)starts instead of at reboot, this was simpler and good enough for now.)

Alternative feature designs

In our case, an all-or-nothing flag would be ideal. Though maybe some users would find value in being able to control whether ZeroNS updates the domain, servers, both, or none; for example, the flag might look like --auto-config-central=domain. Personally I think this would be unnecessary complexity, since the values for domain and servers are unlikely to change often, and are easy enough to change manually when they do.

[laduke]

Thanks for writing that up. I think it makes sense. You want your clients to use 192.168.1.2 for sub.company.tld. They can get to this server via a zerotier "router". 192.168.1.2 will ask zeronsd regarding any zt.sub.company.tld names. zeronsd clobbers the search-domain and servers on central.

I guess another alternative would be having flags to specify those values, if they are different than the default.

-d zt.sub.company.tld --central-domain=sub.company.tld --central-server=192.168.1.2 --central-server=192.168.2.2

can't think of good flag names at the moment.

a --no-configure-central type option sounds easiest.

any thoughts, @someara

I'm not sure if we're able to cut a release soon. Would you be ok building from source for a bit?

edit: a --no-configure option would let zeronsd run with an api token that doesn't have write access. it would only need read access.

[aplum]

Thanks for writing that up. I think it makes sense. You want your clients to use 192.168.1.2 for sub.company.tld. They can get to this server via a zerotier "router". 192.168.1.2 will ask zeronsd regarding any zt.sub.company.tld names. zeronsd clobbers the search-domain and servers on central.

All correct!

I guess another alternative would be having flags to specify those values, if they are different than the default.

IMO I don't see why zeronsd should bother with adding this sort of feature. These values tend to be set once and never changed, so doing that in Central vs zeronsd isn't a big deal – and if they are changed, a potential issue could be that you change the values in Central, but forget about the zeronsd config so a month later zeronsd gets restarted and changes them back to the old values. EDIT: Actually you'd likely need to change the domain configured in zeronsd as well, so maybe this issue would only happen if you're only changing IPs.

I'm not sure if we're able to cut a release soon. Would you be ok building from source for a bit?

Realistically I'm not sure I'll be able to work on a PR any time soon, so I'll be sticking with my workaround for a bit anyway 🙂.

edit: a --no-configure option would let zeronsd run with an api token that doesn't have write access. it would only need read access.

That would be a nice side effect for us!

[aplum]

Not that I would actually bother with this, but would this no-configure-central option allow for running multiple zeronsd instances on the same network, e.g. for high availability of the delegated DNS zone? Is there anything else in zeronsd preventing that?

[laduke]

give that a shot if you get a chance

[erikh]

There's nothing preventing you, but honestly, it screams of a future UX issue, so I avoided it when I was working on the project. Hope that adds context.

------- Original Message ------- On Thursday, March 23rd, 2023 at 4:02 PM, Travis LaDuke @.***> wrote:

give that a shot if you get a chance

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[laduke]

Would love to hear your thoughts. The default is still "yes"

[erikh]

well if someone enables it, but the domain doesn't match what the daemon thinks the domain should be in the API, you're probably gonna have issues.

In the non-domain case, it should pull the settings from the API, otherwise DNS responses aren't going to match because after the API call, zeronsd doesn't really do much synchonously with the API to confirm that the TLD in use is the TLD that's expected.

------- Original Message ------- On Thursday, March 23rd, 2023 at 4:07 PM, Travis LaDuke @.***> wrote:

Would love to hear about it

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[aplum]

In the non-domain case, it should pull the settings from the API, otherwise DNS responses aren't going to match

Do you mean that when no-configure-network is enabled, zeronsd should use the search domain (and IP?) configured in Central? That would break our use case. All of our clients (ZT and non-ZT) use the search domain sub.company.tld which we already have DNS servers for, and those DNS servers delegate the zone zt.sub.company.tld to zeronsd. So if zeronsd found sub.company.tld in Central and decided to use that for itself, the delegation would no longer work properly.