You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My basic understanding of zeronsd is that it would provide a DNS service for all peers of a given network so that I won't need to add these IPs to all hosts files of those peers. I could then access all peers through peer.my.corp by "normal means" (i.e. http, ssh etc.)
What I can't do is ping ping: laptop.my.corp Name or service not known
Which I can kind of understand, since the dig command explicitly checks on the zero-one IP of that server - how would ping and its upstream resolver know to use 172.30.42.248 for my.corp...
Now in the docs, the example to add echo "1.2.3.4 test" >> /etc/hosts doesn't really help - what is 1.2.3.4 supposed to represent here and how would that help?
Anyway, so "Most Linux distributions, by default, do not have per-interface DNS resolution out of the box" - enter zerotier-systemd-manager, right?
Basically, my limited understanding on how this is supposed to work then is that zeronsd (via the zerotier-systemd-manager) needs "to tell" the existing resolver about the clients/IPs managed by zero-one, but it's not clear to me at all how that happens.
https://github.com/zerotier/zerotier-systemd-manager says to "Ensure systemd-networkd is properly configured and resolvectl works as intended." - what does that exactly mean? Generically, resolvectl works on that box, because I can do plain dns lookups and pings to hosts not managed by zeronsd and I see no errors in either systemctl status zerotier-systemd-manager.timer nor systemctl status zeronsd-, the latter says clearly Adding new record laptop.my.corp - so I suppose everything is kind of working as intended?
But now how would the plain vanilla resolver know to ask zeronsd for IP addresses on my.corp? Wouldn't that require some change to /etc/resolve.conf - which, out-of-the-box looks like this:
It appears as if there is some magic sauce somewhere which I fail to see yet and which doesn't work when following the instructions only... And this is just on the server which runs zeronsd, as for the laptop in this example, which runs windows: Its DNS server is set to a PiHole which clearly doesn't yet know about zeronsd, what do I need to set there in order to get results for zeronsd managed IPs? A secondary DNS server on the windows box (the pihole isn't a client in the zero-one network)
Seems to me I'm missing some basic understanding here which I can't dig out of the available docs... Any help is appreciated!
The text was updated successfully, but these errors were encountered:
On your windows machine, You can just go set "Allow DNS Configuration" for your network in Zerotier One, and it'll automatically work (domain names in your search domain of your Zerotier network will ask your ZeroNSD server for IPs, while other domains go through your pihole)
On your debian box, you need to setup systemd-networkd (replaces /etc/network/interfaces functionality) to use zerotier-systemd-manager, then zerotier-cli set <networkid> allowDNS=true and this will let you use Zerotier domain names to ping/connect from the debian box to somewhere else (not needed if you are fine with IPs). You could also manually set it up without networkd but I didn't went that route.
My basic understanding of zeronsd is that it would provide a DNS service for all peers of a given network so that I won't need to add these IPs to all hosts files of those peers. I could then access all peers through peer.my.corp by "normal means" (i.e. http, ssh etc.)
So I've installed zeronsd 0.5.2 on a debian 11 box together with zerotier-systemd-manager, by basically following the steps in https://github.com/zerotier/zeronsd/blob/main/docs/quickstart.md and I've set
on that box.
What I can do on that box is this:
What I can't do is ping
ping: laptop.my.corp Name or service not known
Which I can kind of understand, since the dig command explicitly checks on the zero-one IP of that server - how would ping and its upstream resolver know to use 172.30.42.248 for my.corp...
Now in the docs, the example to add
echo "1.2.3.4 test" >> /etc/hosts
doesn't really help - what is 1.2.3.4 supposed to represent here and how would that help?Anyway, so "Most Linux distributions, by default, do not have per-interface DNS resolution out of the box" - enter zerotier-systemd-manager, right?
Basically, my limited understanding on how this is supposed to work then is that zeronsd (via the zerotier-systemd-manager) needs "to tell" the existing resolver about the clients/IPs managed by zero-one, but it's not clear to me at all how that happens.
https://github.com/zerotier/zerotier-systemd-manager says to "Ensure systemd-networkd is properly configured and resolvectl works as intended." - what does that exactly mean? Generically, resolvectl works on that box, because I can do plain dns lookups and pings to hosts not managed by zeronsd and I see no errors in either systemctl status zerotier-systemd-manager.timer nor systemctl status zeronsd-, the latter says clearly
Adding new record laptop.my.corp
- so I suppose everything is kind of working as intended?But now how would the plain vanilla resolver know to ask zeronsd for IP addresses on my.corp? Wouldn't that require some change to /etc/resolve.conf - which, out-of-the-box looks like this:
It appears as if there is some magic sauce somewhere which I fail to see yet and which doesn't work when following the instructions only... And this is just on the server which runs zeronsd, as for the laptop in this example, which runs windows: Its DNS server is set to a PiHole which clearly doesn't yet know about zeronsd, what do I need to set there in order to get results for zeronsd managed IPs? A secondary DNS server on the windows box (the pihole isn't a client in the zero-one network)
Seems to me I'm missing some basic understanding here which I can't dig out of the available docs... Any help is appreciated!
The text was updated successfully, but these errors were encountered: