Feature Request: Fallback nameservers when TLD matches

[altano]

I saw the documentation section on Serving non-ZeroTier records but it only allows fallback to a hosts file.

Would it be possible to allow fallback to another DNS server instead, when there is no record, even if the TLD matches the ZeroNS TLD? This would allow me to have entries for the same domain in both ZeroNS and public DNS and my end-users wouldn't have to use a different subdomain for some services. With a hosts file I'd have to replicate what I have in public DNS in my hosts file, which I'd rather not do.

e.g. I'd make ZeroNS tied to example.com, in a public DNS somewhere (let's say Cloudflare) I'd have public DNS records for serviceA.example.com and serviceB.example.com. I'd have ZeroNS bound to example.com, it would have a record for serviceC.example.com (which it could serve directly), but DNS queries for serviceA.example.com would fall through to the backup nameserver (in this case, 1.1.1.1).

[erikh]

So, fundamentally I have been opposed to this in the past as it needs to be solved in one of two ways:

• either we have to query out and potentially expose ourselves to caching problems (which include poisoning of it)
• it's a great way to MITM users w/ TLS (think if your zerotier network took, say, .com). A gentle reminder that zeronsd works at the TLD level here, and can trivially do this if a feature like this were to be patched in.

I haven't been comfortable adding the functionality for this as a result. However, perhaps there is a solution that works for everyone. I'm going to let this brew for a bit and think it over, but if you come up with solutions in the meantime, I'd love to hear them.

[erikh]

I should also point out the zeronsd should fall back to your local resolver for situations where the no match occurs, but I don't think that's what you're asking for here.

[altano]

I should also point out the zeronsd should fall back to your local resolver for situations where the no match occurs, but I don't think that's what you're asking for here.

To be clear, you mean when the TLD doesn't match. You're not saying it will fall back to the local resolver when the TLD matches but there is no record matching the query, right?

My testing validates my understanding so I hope it's correct:

# Query ZeroNSD for non-ZT domain
$ dig +short @10.147.19.196 google.com
142.250.72.174 ✅

# Query my gateway (ZeroNSD's fallback nameserver) for SAME TLD.
# This is a placeholder DNS record I added to public DNS.
$ dig +short @192.168.0.1 zt-test.norbauer.net
1.1.1.1 ✅

# Query ZeroNSD for that same public DNS record (non-ZT, but in ZT domain)
$ dig +short @10.147.19.196 zt-test.norbauer.net
❌

Your explanations make as much sense as they can to a networking newb. I think I get it. I'll devote a separate domain to my ZT network and not try to overload a single domain. Thanks!

[erikh]

To be clear, you mean when the TLD doesn't match. You're not saying it will fall back to the local resolver when the TLD matches but there is no record matching the query, right?

Correct.

Sure, a lot of people have come to this conclusion :) but we keep having the ticket brought up, I'm going to leave this one open so others can chime in if they have a good use case we can't avoid. Please feel free to mute the ticket if it bothers you. :d

thanks for the great feedback and commentary lately. It's nice to talk to people actively interested in the product.

[altano]

thanks for the great feedback and commentary lately. It's nice to talk to people actively interested in the product.

It's my pleasure. I'm just excited to be playing with some cool tech so thanks for making it.

[Codel1417]

To be clear, you mean when the TLD doesn't match. You're not saying it will fall back to the local resolver when the TLD matches but there is no record matching the query, right?

Correct.

Sure, a lot of people have come to this conclusion :) but we keep having the ticket brought up, I'm going to leave this one open so others can chime in if they have a good use case we can't avoid. Please feel free to mute the ticket if it bothers you. :d

thanks for the great feedback and commentary lately. It's nice to talk to people actively interested in the product.

Does this mean DNS will use the fallback server on the local machine or specifically the one the zeronsd is on?

Im trying to have all devices connected use the dns server set in zeronsd, overriding the DHCP DNS servers when connected. T he goal is to use direct IP when local but route through zerotier when away. This would also provide a convenient way to deploy DNS over HTTPs without the hassle of installing additional software on the clients by using a centralized proxy

Sadly it looks like it only overrides the set TLD

[altano]

Im trying to have all devices connected use the dns server set in zeronsd, overriding the DHCP DNS servers when connected.

@erikh can correct me if I’m wrong, but your Windows and Mac clients will only use the zeronsd server for dns when the domain suffix matches and will not work the way you want. It won’t funnel all dns queries to your zeronsd server and it isn’t going to get you there with tweaking.

[laduke]

That's correct.

[pacepace]

I have a lot of CNAMEs in my domain, those are not compatible with hosts files. What I have right now is a script that checks for changes on those CNAME addresses and that updates my hosts file and then restarts the zeronsd daemon. Definitely not optimal.

Having a command line switch that instructed zeronsd to fallback to the results from the local resolver for the configured TLD when it does not have an internal record would be an ideal situation for my configuration.

[erikh]

Unfortunately you're asking for a recursive DNS server; zeronsd deliberately does not support recursion due to complications with cache poisoning. The systemd agent will instruct systemd-resolved to only use zeronsd for the TLD you chose, and the "use DNS" flags on the zerotier mac and windows clients will do the same, which makes this unnecessary to add. If the zerotier team wishes to add this, that's up to them. I would strongly advise against it as it adds a mountain of complication to the service for zero gain if you're using the service appropriately. zeronsd does not support CNAME records because there is no way to express them in the API, and it would arguably be better for your situation if they did, although this is the first time in 18 months since the formation of this project that I have heard such a request. If you have CNAME records that point at zeronsd and need to adjust a resolv.conf to leverage both DNS servers, it's likely that you are configuring your DNS in a slightly broken way, as resolv.conf does not support non-recursive nameservers. Use systemd-resolved or the facilities that macos and windows provide for per-interface DNS resolution. I hope this helps you in your endeavor. What you probably want is something like https://github.com/erikh/polyresolver, which is cross platform and handles this kind of DNS resolution problem. As much as you may believe otherwise, your DNS solution is just failing very gracefully in situations it expects to succeed at. You can't expect to do recursive DNS across split-horizon boundaries with reliable results, the only reason you're succeeding at all is because of a lot of code that handles bad DNS servers in glibc, is my guess.

…

------- Original Message -------

On Tuesday, May 9th, 2023 at 1:51 AM, Mark Pace ***@***.***> wrote: I have a lot of CNAMEs in my domain, those are not compatible with hosts files. What I have right now is a script that checks for changes on those CNAME addresses and that updates my hosts file and then restarts the zeronsd daemon. Definitely not optimal. Having a command line switch that instructed zeronsd to fallback to the results from the local resolver for the configured TLD when it does not have an internal record would be an ideal situation for my configuration. — Reply to this email directly, [view it on GitHub](#118 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAET2ZWNAZBNLOERUPZCHTXFIAR5ANCNFSM5MZ6TNSQ). You are receiving this because you were mentioned.Message ID: ***@***.***>

[erikh]

One thing you could potentially do is load a hosts file into zeronsd, which would provide A records that also point at the IP addresses you are trying to CNAME, which could resolve your problem for you.

…

------- Original Message -------

On Tuesday, May 9th, 2023 at 2:31 AM, Erik Hollensbe (OSS) ***@***.***> wrote: Unfortunately you're asking for a recursive DNS server; zeronsd deliberately does not support recursion due to complications with cache poisoning. The systemd agent will instruct systemd-resolved to only use zeronsd for the TLD you chose, and the "use DNS" flags on the zerotier mac and windows clients will do the same, which makes this unnecessary to add. If the zerotier team wishes to add this, that's up to them. I would strongly advise against it as it adds a mountain of complication to the service for zero gain if you're using the service appropriately. zeronsd does not support CNAME records because there is no way to express them in the API, and it would arguably be better for your situation if they did, although this is the first time in 18 months since the formation of this project that I have heard such a request. If you have CNAME records that point at zeronsd and need to adjust a resolv.conf to leverage both DNS servers, it's likely that you are configuring your DNS in a slightly broken way, as resolv.conf does not support non-recursive nameservers. Use systemd-resolved or the facilities that macos and windows provide for per-interface DNS resolution. I hope this helps you in your endeavor. What you probably want is something like https://github.com/erikh/polyresolver, which is cross platform and handles this kind of DNS resolution problem. As much as you may believe otherwise, your DNS solution is just failing very gracefully in situations it expects to succeed at. You can't expect to do recursive DNS across split-horizon boundaries with reliable results, the only reason you're succeeding at all is because of a lot of code that handles bad DNS servers in glibc, is my guess. ------- Original Message ------- On Tuesday, May 9th, 2023 at 1:51 AM, Mark Pace ***@***.***> wrote: > I have a lot of CNAMEs in my domain, those are not compatible with hosts files. What I have right now is a script that checks for changes on those CNAME addresses and that updates my hosts file and then restarts the zeronsd daemon. Definitely not optimal. > > Having a command line switch that instructed zeronsd to fallback to the results from the local resolver for the configured TLD when it does not have an internal record would be an ideal situation for my configuration. > > — > Reply to this email directly, [view it on GitHub](#118 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAET2ZWNAZBNLOERUPZCHTXFIAR5ANCNFSM5MZ6TNSQ). > You are receiving this because you were mentioned.Message ID: ***@***.***>

[pacepace]

Here's an example, I don't think I'm using CNAMEs improperly. I CNAME my mastodon address to my mastodon hosts CDN of mastodon edges:

mastodon.mydomain.com CNAME edges.mymastodonprovider.com

The addresses that are serviced by the CNAME change frequently. I have successfully got this working with a hosts file that uses a script to chase that CNAME. Obviously not ideal.

Anyway, thank you all for considering the idea!

For those with this issue, what I've decided to do is configure DNSMASQ and I've put in static entries for my Zerotier network. So no autoconfiguration of the Zerotier addresses and no auto dns of those addresses like zeronsd provides, but I do have support for my CNAMEs and all is happy. Just need to configure DNSMASQ when I've got a new host that the Zerotier network needs to access "locally"...