Things were working great until I was troubleshooting why machines are not enrolling with Entra and Intune.
The way the referenced post is set up has *.ad.domain.com intercepted, so all DNS queries for the subdomain resolve to the Ziti interface. That is causing a problem when enrollment is looking for a proxy at wpad.ad.domain.com, which doesn’t exist, so it shouldn’t resolve, and it’s causing a problem when I check the machines domain registration status.
What I’d really like to do is push down an internal caching DNS resolver for clients to use while they’re connecting to OpenZiti, and have a service/host/intercept that allows that DNS traffic through via an IP address intercept. That way my internal caching resolver can forward *.ad.domain.com queries to the AD servers, and I don’t have to open anything up publicly.
Is this possible? Is there a better way to accomplish this?
I think it’s possible, but if I’m understanding you then you’d need to somehow set up the hosts with your DNS server so that clients would use it. Maybe you already have this in place (or a plan to do it)?
The host in question doesn’t exist at all. The built in Windows services look for it, but since it can resolve it via Ziti (because of the wildcard) and not connect to it, it considers it an error different than receiving a NX response from the DNS service.
Similar to how some email clients might look for autoconfig.domain.com or autodiscover.domain.com; if I don’t have an autoconfig service, the Ziti DNS service will still resolve it via a *.domain.com wildcard and resolve it to one of the 100.64.x.x addresses, even though the actual DNS record doesn’t actually exist anywhere else.
I think I follow you - at the very least you don’t want ZDEW’s name server to resolve these hostnames that clients might try to probe, such as “wpad”, etc. We currently don’t have a way to do that when intercepting a wildcard domain (although we’ve had an idea to implement more modifiers on intercept hostnames, e.g. ‘!wpad.ad.domain.com’). That approach might be an option, but I could image it being fussy and fragile to get the list of hostname exclusions right.
My previous comment about setting up the “hosts with your DNS server” was referring to Windows DNS configuration, assuming you were going to try the IP intercept approach that you mentioned.
So if you had a DNS server running somewhere that provides the answers (or non-answers) that you want, you’d need to somehow add its IP to the DNS settings of the Windows hosts. Your Ziti service could then intercept the DNS server’s IP (and presumably subnet(s) that will catch any answers returned by the DNS server).
This is where the issue I’m having with all of this comes in.
I can push an internal DNS server down through Active Directory GPO, but that will require OpenZiti to be connected in order for it to use it (because it would be an “internal” DNS server). However, if OpenZiti is not connected, that DNS server is not reachable, and AD doesn’t provide any way to say “hey, when OpenZiti is not connected, remove this DNS server from the list”
It needs to be a DNS server that is accessible “internal only” because ad.domain.com, and all records under it, should not be exposed to the public internet.
So that’s why I was hoping we could “push” down a DNS server for the client to use after OpenZiti establishes a connection. That way OpenZiti would connect, the services would be setup so that I could have one that routes to the DNS server by IP address, and then the DNS server would be pushed down and everything would remain “zero trust”.
The ultimate end-goal I am trying to accomplish with all of this is to have machines be part of our Active Directory domain, but everything setup using zero-trust with OpenZiti so that we don’t have to expose anything to the public internet or setup traditional perimeter-based VPNs, while also not worrying about whether or not they’re in an office, at home, or somewhere else in the world.