ZeroTier and DNS issues

coliver

@colliver How are these DNS records "learned?" What is the mechanism? Does the client computer enumerate its interface addresses to AD, or does AD learn them by listening to the network?

Also in the scenario described above:

(1) Is the desire to use the ZeroTier network as the main "company LAN" and run AD over that?

(2) Or is the desire to use ZeroTier for other purposes and keep the main company LAN from getting polluted by its addresses?

These are obviously different use cases. I imagine #1 might actually be easier than #2, but that's a greenfield approach.

I don't use ZeroTier at the moment. I'm pretty sure the AD client sets their own DNS entry when they register with the domain controller (someone please correct me if I'm wrong).

I think @Dashrender was going for option 2 in this case.

adam.ierymenko

Hmm... so perhaps the problem is that the AD client is enumerating its addresses and choosing the wrong one. If so, I think the thing to do would be to look into Windows' logic for choosing the "primary" interface and/or AD's logic for choosing which IP address(es) reported by clients to name as their primary.

You would think Windows would be smart enough to set AD DNS to IPs within the IP block managed by AD, but that probably assumes too much.

coliver

@adam.ierymenko said:

Hmm... so perhaps the problem is that the AD client is enumerating its addresses and choosing the wrong one. If so, I think the thing to do would be to look into Windows' logic for choosing the "primary" interface and/or AD's logic for choosing which IP address(es) reported by clients to name as their primary.

You would think Windows would be smart enough to set AD DNS to IPs within the IP block managed by AD, but that probably assumes too much.

In the past with Pertino we were able to change the default adapter on the Pertino clients to the physical adapter (moving it up in the list). That seemed to fix the issue for us... not sure if that would solve the issue here or not.

adam.ierymenko

Hmm... so the question is: how does Windows determine a priority list for adapters and which one is 'default?' Answering that question seems more elegant than highjacking DNS.

adam.ierymenko

Root of the problem is that none of these protocols (DNS, AD, DHCP, etc.) were designed for a world in which a client can belong to more than one network.

adam.ierymenko

??? Could this perhaps be helpful?

https://support.microsoft.com/en-us/kb/2526067

coliver

@adam.ierymenko said:

??? Could this perhaps be helpful?

https://support.microsoft.com/en-us/kb/2526067

Yep, that's what I ended up doing. It worked out for what we needed.

adam.ierymenko

@scottalanmiller I wonder then: why all the DNS magic if the issue can be solved by simply setting connection priority? Or did the under the hood DNS magic solve a different issue?

Dashrender

Adam, Welcome to ML! thanks for taking the time to join and post!

Here's my setup.

I have a DC (DC2) that is also a file server that has ZT installed on it. I have one client laptop that also has ZT installed and connects to the DC/Fileserver just fine.

The problem, as you surmised, is that the ZT adapter registered itself with DNS when it came online. My DNS server now has two IP addresses for this DC.

Hold on to you seat, I'm going to spill a whole lot more information.

I discovered a problem when I was on DC1 trying to ping DC2. When I typed

 ping dc1

I received the IP address for the ZT adapter, and the request timed out (there's no route to get there on my network).
Even pinging

 ping dc1.domain.com

didn't work, same result.
At first I had completely forgotten about my installation of ZT on DC2 and even though IP provided by the above ping tests wasn't something listed in my external DNS (Split brain DNS) I recall having weird DNS issues in the past when IPv6 was enabled. I disabled IPv6 on DC1, tried the ping test again, wala! it worked.

I started digging around a bit more trying to figure out where this oddball 10.x.x.x address was coming from and then I bumped into my install of ZT. OK mystery solved.

I jumped into DNS and found the second DNS record for DC2 with the ZT IP.

Now I'm asking myself - what keeps DNS from giving the ZT IP to internal Windows clients when they are querying for DC2?

This lead me to the desire to remove the second entry, but I couldn't just delete it from DNS, the next time the adapter refreshes on DC2 it will simply be re-added. So someone suggested removing the checkmark next to "Register this connection's addresses in DNS" under Adapter settings > ZT adapter > IPv4 > Advanced button > DNS tab. Sadly that didn't work. Why you ask? Because Windows won't allow you to access the DNS tab if you don't manually assign an IP address to the adapter, and ZT is using DHCP. Now I'm guessing there is a registry key I could change - but before I went that far, I started this thread.

Upon further consideration I also realized that I don't want to remove the ZT IP from DNS, because then my ZT client would no longer be able to use DNS to find DC2.

Hopefully this is enough to get started.

Dashrender

@adam.ierymenko said:

??? Could this perhaps be helpful?

https://support.microsoft.com/en-us/kb/2526067

This would not have solved my issue, ZT wasn't installed on DC1, so there was nothing to change.

adam.ierymenko

@Dashrender

"Upon further consideration I also realized that I don't want to remove the ZT IP from DNS, because then my ZT client would no longer be able to use DNS to find DC2."

Oh my. The horror. Let me check my understanding. What you want (ideally) is:

(1) Clients on the regular network get regular network addresses when they resolve things, especially the DCs.

(2) Clients on the ZeroTier network get ZeroTier network addresses when they resolve things, especially the DCs.

... but DNS and AD were not designed for multi-path or multi-network use.

I think I might understand Pertino's hack now. They hacked multipath into DNS by rewriting DNS queries or responses based on which networks you belong to. (???)

If this were a greenfield deployment I'd suggest using ZeroTier as the company LAN and binding AD only to that. This is what we'd call the "fully virtualized network." We have some distributed teams doing that and it works fine, though they had to do a bit of hackery to coax AD into preferring the ZT interface.

Here's an idea, though we have not tried this:

Don't run ZeroTier on the domain controllers. Instead, set up a Linux VM and bridge the DC's network to the ZeroTier network. Then set up the ZT network to assign IPs within the main network's range but in a region that will not be handed out on the main network by its DHCP servers. Now when clients join ZT they get another main network IP address and from the perspective of any clients on the main network they now have two connections to it. It looks as if they have two network cards with two cables plugged into the same switch (which is legal, and each will get a different IP).

Then set the physical interface to higher priority on the clients. When connected to the LAN, clients will go over that. When off-site, clients will go through ZT.

Now you no longer have two address spaces, so DNS will just have one IP.

Dashrender

That solution looks good for a primarily mobile user, so you'll have little concern about having two DNS entries for the client in DNS. This is a problem when you are trying to manage the client devices, you can run into the same problem as my two IP addressed DC.

But I see the potential for a lot of problems for someone who is in and out, and finding themselves most of the time having two DNS entries.

adam.ierymenko

On further thought, I wonder if it would work if ZT were given the same IP scheme as the main network, but were set to a lower priority on all machines. Then it would be used as an alternate path and only if the main network were not available.

This might be something we'd want to officially support: "shadow network" use case?

adam.ierymenko

@Dashrender Yes, I can see issues as well. Unfortunately I can't see a clean solution that doesn't involve either changing the layout of things or some form of client-side hackery. But I want to think about this a bit longer.

Dashrender

I'll agree that DNS doesn't handle mulit-homed computers well - well that's to say that our ability to use DNS effectively when a device has more than one registered IP is poor at best.

AD itself doesn't care about IP space other than it's ability to reference DNS to find a device, which is a mandate, but not what I would call a failing or falter on the part of AD.

adam.ierymenko

@Dashrender Can you go up a level and out of the realm of technical details and explain what you're actually attempting to accomplish? Is this a road warrior use case or something else like inter-site collaboration?

Dashrender

@scottalanmiller or anyone who uses Pertino, Are the Pertino addresses registered to your AD's DNS servers?

scottalanmiller

@Dashrender said:

@scottalanmiller or anyone who uses Pertino, Are the Pertino addresses registered to your AD's DNS servers?

Yes, that is how the machines locate each other.

dafyre

In this instance, couldn't we just let the company DHCP assign IP addresses across the bridge?

Dashrender

So this is for someone who has a network with both Pertino enabled endpoints, and NOT enabled endpoints.

Do you ever have an issue where a local client is trying to reach a DC that is multi-homed (local LAN and Pertino)? if so, what was the issue? was it that DNS was giving you the Pertino IP?