Internal DNS server for proxy to upstream DNS

[JamesHammy]

Hi folks,

Bit of an odd one. We use SecureConnect and Umbrella SWG in a multi-site MX environment. All local LAN/WAN traffic traverses the SecureConnect tunnel but for reasons I won't bore you with, we need to exclude certain domains from the tunnel and breakout locally. Because we use our local DNS servers (AD-integrated DNS) for internal resolution, we can't use DNS-based VPN exclusions on the MX.

Pre-req: We run a local Microsoft domain and I need to retain local DNS resolution to access domain resources.

I need to set some of our internal VLANs' DHCP config to have the MX105 perform the initial DNS resolution. The only way I can see this is possible is by configuring the DHCP scope's DNS servers as 'proxy to upstream DNS'. Having read a bunch of Meraki KB articles, it's clear that this 'proxy' mechanism works as follows:

1. Endpoint queries the MX 'DNS server'
2. MX forwards request to the local LAN interface (we have several LAN interfaces so not sure which it would even use?)
3. MX's local LAN forwards request to the primary WAN uplink's DNS servers
4. Endpoint gets its DNS query resolved

But here's the challenge. Our WAN interfaces use external DNS servers so that we can retain uplink health monitoring capabilities (we use both WAN interfaces on independent leased lines).

If we put aside losing WAN monitoring, is it actually supported to set our internal DNS servers on the WAN interfaces?

Any help would be great!

This is the article I've been referencing:

• https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/DHCP/C....

[ww]

Maybe you can achieve/configure local dns resolve from the mx itself.

https://documentation.meraki.com/SASE_and_SD-WAN/MX/Operate_and_Maintain/How-Tos/Local_DNS_Service_o...

[JamesHammy]

Thanks for the link. I actually read through that document too but the problem is, I don't want to run a custom DNS service on the appliance itself. We'd have to manually manage the entries, which would be totally impractical in a domain environment, with hundreds of laptops that all use dynamic DNS updates. I just want the MX to forward the requests to our internal DNS servers.

[RWelch]

The WAN DNS settings are intended for public or ISP-provided DNS servers, which are required for proper MX operation, including Internet connectivity checks, Dashboard communication, and VPN registration.

Using internal DNS servers on the WAN interface can disrupt these functions.

[JamesHammy]

Thanks and that was exactly my concern. In my mind, especially given Meraki devices are 100% cloud-managed, WAN interfaces should only ever be configured with external DNS addresses.

The biggest challenge with proxying DNS requests from the MX, where we must retain local resolution for the domain, is the following line in the guide:

• Proxy to upstream DNS
  Clients will send DNS requests to the LAN interface of the MX, which will then proxy those requests to the DNS server(s) configured for its primary Internet uplink.

Doing the above completely sidesteps any local resolution so the machine will effectively fall off the domain. If we were pure cloud and had no domain, this whole problem would go away.

[RWelch]

To retain local DNS resolution for domain resources, configure your DHCP scopes to hand out your internal DNS servers directly to clients. This allows clients to resolve internal resources while still using public DNS for Internet-bound queries. 

[JamesHammy]

Yes, we've always had DHCP hand out our internal DNS servers to clients and this works perfectly for normal use.

Our problem is that I cannot do DNS-based VPN tunnel exclusions on the MX devices, unless the client initially uses the MX to query DNS. Obviously, once our client has queried our internal DNS server, the actual internet traffic sails through the MX as IP addresses and ports, so it can't see the domain names or URLs. This means unless we put IP-based tunnel exclusions on the MX, which would be impossible to manage for our use case, all internet traffic hits the tunnel.

I suspect the fact that the MX can only do layer-4 inspection is why we have such a problem. Layer-7 would obviously mean the traffic's domain name / URL woudl be sniffed out and rules applied?

I suspect