ZeroTier and DNS



  • @adam-ierymenko What is the recommended way to setup DNS to ensure endpoints interact with your office DNS correctly?

    Let's assume a Windows PC joined to an office AD Domain. You install ZT on it, then leave the building.

    When you get to Starbucks you join their wireless network, getting the DNS servers their system provides. Now what?

    As far as I can tell, the ZT network doesn't have any DNS servers listed (at least by default), so how do I interact with my office DNS servers for resolution?



  • 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.



  • So int.zerotier.com and git.int.zerotier.com are on your public DNS server, not part of your internal network, right?

    Are you running split brain DNS?



  • I tried setting DHCP up on my ZT network using Windows. .. sadly, Windows does not list the ZT Interface to serve DHCP on.

    I will try a Linux install and see what happens.



  • @dafyre said:

    I tried setting DHCP up on my ZT network using Windows. .. sadly, Windows does not list the ZT Interface to serve DHCP on.

    I will try a Linux install and see what happens.

    Do you have a static IP address on the interface for ZT? If not, you can't give out DHCP requests via the interface.



  • 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.


  • Service Provider

    @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.


  • Service Provider

    @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.


  • Service Provider

    @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.


  • Service Provider

    @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.


  • Service Provider

    @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?


  • Service Provider

    @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.


  • Service Provider

    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.


  • Service Provider

    @Dashrender said:

    I've actually never heard this term before - I've only ever seen split brain.

    Split Brain is a cluster failure condition. 🙂

    https://en.wikipedia.org/wiki/Split-brain_(computing)


  • Service Provider

    @Dashrender said:

    I have internal DNS for the same FQDN space and a separate DNS on the internet.

    Yup, that is Split Horizon.

    Although I could see why that would be mistaken as a failure condition.


  • Service Provider

    What is the purpose in your split horizon? Why are you serving out something to the public from your internal DNS servers?




  • Service Provider

    Very weird. I guess they are either just confused or they are trying to make a point that it is a failure condition that should be avoided.