ZeroTier and DNS
-
I swear I replied to this last night... Maybe my brain is just foggy from the onslaught of new sounds...
At any rate, I checked and did not assign a static IP to my ZT interface. So I went back and did so. It still did not show up as available under the Bindings on the DHCP server. I am thinking it may be a windows issue. What I plan to do is spin up a small Linux VM and install ZT and a DHCP server and see what happens.
-
@adam-ierymenko -- You guys are pretty much doing "DHCP" in your own way by letting ZT pick out and assign IP addresses. Are there any plans to allow us to specify DNS servers that can be assigned to the ZT Interface (Kinda like how a DHCP server would hand them out as well) ? This could be done as a Network-wide option.
-
I could have sworn that @adam-ierymenko mentioned the possibility of using your own DHCP server to assign IPs to the ZT interfaces. That should give you want you want.
-
@adam.ierymenko said:
A lot of our users will place their intranet's DNS under their domain and use that -- so e.g. ours is int.zerotier.com and git.int.zerotier.com resolves to an internal IP. This will work regardless of what DNS servers you are actually using.
Sometimes that's not an option. In that case the best thing might be to manually override DHCP DNS and set your intranet's servers as your DNS servers. ZeroTier does not itself depend upon DNS to work properly, and this is why.
I don't understand how this solves the DNS issue. Can you provide more information?
-
@Dashrender No, we're not doing this if that's what you mean:
https://en.wikipedia.org/wiki/Split-horizon_DNS
We're just putting our intranet IPs under our main domain. Doesn't matter since nobody without intranet access can actually access these systems and they're not advertised anywhere.
I'm thinking that there's a need here for some kind of DNS solution to work with ZeroTier, but in the interest of sanity and avoiding feature explosion I'm reticent to actually build it into ZeroTier itself. Instead I think it should maybe be another app, something that serves DNS locally and makes decisions about where to get the actual DNS information from.
I wonder if anyone's already written anything like this? I know on *nix we have dnsmasq and other similar services.
-
These kinds of problems are why Pertino had to create their own DNS hack (for lack of a better word) to solve these types of problems.
-
@adam.ierymenko said:
I'm thinking that there's a need here for some kind of DNS solution to work with ZeroTier, but in the interest of sanity and avoiding feature explosion I'm reticent to actually build it into ZeroTier itself. Instead I think it should maybe be another app, something that serves DNS locally and makes decisions about where to get the actual DNS information from.
I wonder if anyone's already written anything like this? I know on *nix we have dnsmasq and other similar services.
Much as Pertino did. They leverage your existing Windows DNS servers and have a special app that runs inside the Pertino network and handles your DNS.
-
With ZT installed on one of my servers, and that interface getting DHCP from ZT, the interface is registering itself in my AD's DNS system. Non ZT machines are now resolving to the ZT IP address instead of the local network IP. Though it seems non deterministic, that just might be my limited exposure so far.
-
@Dashrender said:
With ZT installed on one of my servers, and that interface getting DHCP from ZT, the interface is registering itself in my AD's DNS system. Non ZT machines are now resolving to the ZT IP address instead of the local network IP. Though it seems non deterministic, though that just might be my limited exposure so far.
That's what we found with the Pertino system too.
-
Does anyone know if this comes up in other situations? Seems like the one-layer-down issue is getting AD to work in a multi-network environment.
-
Obviously if you go 'all in' with SDN then your private IPs will just work always, but not everyone can do that.
-
@adam.ierymenko said:
Does anyone know if this comes up in other situations? Seems like the one-layer-down issue is getting AD to work in a multi-network environment.
That is correct. But generally you don't run into these issues except when building a full mesh.
-
@adam.ierymenko said:
Does anyone know if this comes up in other situations? Seems like the one-layer-down issue is getting AD to work in a multi-network environment.
I'm trying to recall how this is solved in a traditional VPN setup. VPN server on the edge of my network, I connect while I'm at home. The IP I get from the VPN server includes my office's DNS server as well as an IP. But even then, I've had issues where things don't resolve correctly, so I'm sure this isn't a new problem.
-
@Dashrender said:
I'm trying to recall how this is solved in a traditional VPN setup. VPN server on the edge of my network, I connect while I'm at home. The IP I get from the VPN server includes my office's DNS server as well as an IP. But even then, I've had issues where things don't resolve correctly, so I'm sure this isn't a new problem.
DHCP because you only connect to the VPN when remote. You are handling the whole process manually and just don't realize that that is what is happening. You are manually choosing to tell the system when you are or are not in the office.
-
@scottalanmiller said:
@Dashrender said:
I'm trying to recall how this is solved in a traditional VPN setup. VPN server on the edge of my network, I connect while I'm at home. The IP I get from the VPN server includes my office's DNS server as well as an IP. But even then, I've had issues where things don't resolve correctly, so I'm sure this isn't a new problem.
DHCP because you only connect to the VPN when remote. You are handling the whole process manually and just don't realize that that is what is happening. You are manually choosing to tell the system when you are or are not in the office.
I don't follow. While my post started out asking how we solved this with before, I ended by saying it really never was solved.
The DNS servers provided to the VPN client weren't reliably more authoritative with responses than the local connection DNS servers. I basically had to setup a host file for anyone who was mobile to ensure IP connectivity for them.
-
@Dashrender said:
The DNS servers provided to the VPN client weren't reliably more authoritative with responses than the local connection DNS servers. I basically had to setup a host file for anyone who was mobile to ensure IP connectivity for them.
That should not happen. I've done VPNs for decades and never ran into that issue. What was causing DNS to not work well when on the VPN?
-
@scottalanmiller said:
@Dashrender said:
The DNS servers provided to the VPN client weren't reliably more authoritative with responses than the local connection DNS servers. I basically had to setup a host file for anyone who was mobile to ensure IP connectivity for them.
That should not happen. I've done VPNs for decades and never ran into that issue. What was causing DNS to not work well when on the VPN?
Maybe the fact that I have a split brain DNS?
-
@Dashrender said:
Maybe the fact that I have a split brain DNS?
Split horizon, I hope that you mean. Split brain would mean that it is confused and handing out bad entries from a confused cluster failover.
-
Why are you using split horizon?
-
@scottalanmiller said:
Why are you using split horizon?
I've actually never heard this term before - I've only ever seen split brain.
Just to make sure we're on the same page (and correct my term usage):
I have internal DNS for the same FQDN space and a separate DNS on the internet.
