Using kubectl to interact with AKS Manager in Azure over Ziti on macOS

Tunneler Apps Ziti Desktop Edge for MacOS
1

I am trying to use kubectl to make configuration changes on the AKS cluster I deployed in Azure. The cluster is private and the manager is not reachable from the Internet I can reach the cluster manager over Ziti from my windows 10 machine, but not my mac (version Monterey). The dns of my server is not a fake name. The top domain is .azmk8s.io. It looks like the issue is with the dns resolution. When I capture the dns packets using wireshark, I don’t see an attempt to forward this dns query to the Ziti internal resolver at 100.64.0.2. If I use the curl, I see no issues. Has anyone seen/experienced a similar issue on mac by any chance?

2

Are you using dig or nslookup (or might kubectl behave similarly)? They both have caveats in their man pages, e.g.:

macOS NOTICE
       The dig command does not use the host name and address resolution or the DNS query routing mechanisms used by
       other processes running on macOS.  The results of name or address queries printed by dig may differ from those
       found by other processes that use the macOS native name and address resolution mechanisms.  The results of DNS
       queries may also differ from queries that use the macOS DNS routing library.

On macOS ZDE, check Advanced Settings (the :gear: icon on the lower left). You’ll see curl and other apps behave differently from dig and nslookup when “Intercept DNS by matching domains” is enabled.

Can you try with “Intercept DNS by matching domains” disabled (if not already)?

3

Thanks! That worked.

4

What exactly does that mean “by matching domain”? domain as in top, sub, etc?

5

From Apple docs:

matchDomains
A list of domain strings used to determine which DNS queries will use the DNS resolver settings contained in this object.

Discussion
This property is used to create a “split DNS” configuration, where only hosts in certain domains are resolved using the tunnel’s DNS resolver settings. Hosts not in one of the domains in this list are resolved using the system’s default resolver.

If matchDomains contains the empty string it becomes the default domain. This is how a split-tunnel configuration can direct all DNS queries first to the VPN DNS servers before the primary DNS servers.

If the VPN tunnel becomes the network’s default route, the servers listed earlier by NEDNSSettings become the default resolver and the matchDomains list is ignored.

Run scutil --dns with it enabled and compare to when disabled and you’ll have a good idea of what it does.

Basically, if you are configured to intercept “fred.shed” it will route “*.fred.shed” to the tunnel, tunnel “fred.shed” over Ziti, and proxy anything else caught by "*.fed.shed" to fallback DNS (you can configure the fallback DNS address or allow ZDE to auto-determine it). This limits the amount of DNS traffic ZDE sees, which is helpful in some scenarios.

Otherwise, when “by matching domain” is disabled, all DNS traffic flows through ZDE, and all non-intercepted names are proxied to the fallback DNS.

1 Like
6

Cool, I see the difference now with scutil. Thanks!

7

matchDomains when enabled works like NRPT in windows.

2 Likes