DNS NAT translation not working for newer MacOS

[tato386]

My NAT policies have DNS translation enabled so that queries resolve to internal private IPs of servers when available.  This works fine for PC users but I have noticed that Macs running Ventura and newer OS resolve the public IP.  On the VLAN with the problem I am using Cisco Umbrella OpenDNS servers.  I believe the Macs are doing encrypted DNS with the OpenDNS servers and the FTD (v7.1) only translates unencrypted DNS queries.  I am assuming that decrypting these DNS queries is not an option and/or fairly difficult but is there should be an easy way to block Macs from negotiating encrypted DNS and having them fall back to legacy DNS?  The solution needs to be implemented at the firewall level since these are unmanaged Macs.

TIA,

Diego 

[Marius Gunnerud]

Well this is quite odd.  Are the PCs and the Mac's on the same subnet?  If you do an nslookup for the domain and specify the internal DNS server, is it successful?

[tato386]

Yes, they are on the same network.  This drove me crazy for a while.  NSLOOKUP works because I suppose it isn't using encrypted DNS.

But ping and web browsing get public IP and fail.

[MHM Cisco World]

Why you dont bypass the dns (encrypted) request from ftd policy.

Here even if it encrypt it will not drop by ftd.

[tato386]

That is what I am trying to do but I believe DoH uses 443 which I can't block and I can't block the OpenDNS IP addresses either.  I guess maybe a rule to block 443 to OpenDNS and/or rule to allow *only* TCP/UDP 53 to the OpenDNS IPs might work.

[Marius Gunnerud]

What you could do is let the hosts resolve the domain to the public IP using their encrypted DNS, then we know that users will be using the public IP.  This way you can use Destination NAT and translate the public IP of the server to the private IP.  Now, if the Mac and server are on the same subnet, you will have an issue with asynchronous routing to sort out.  If not then all should be good.

[tato386]

Not sure I wanna add Destination NAT to the equation at this point.  My rule to block everything but TCP/UDP 53 towards the Umbrella servers is not getting any hits.  Maybe I need to get some packet captures from these Macs so I can pinpoint the behavior and create a rule that matches whatever they are doing and block it.  I believe I read somewhere that they might be using their own DNS servers and ignoring the DHCP assigned DNS.

[tato386]

After analyzing traffic I see the Macs using 146.112.41.2 for DNS over HTTP (tcp/443).  And a quick google search shows that these are in fact the Umbrella servers.  Cisco Umbrella Enhances Support of DNS Over HTTPS - Cisco Umbrella

I guess some logic in newer Mac OS say that if DHCP gives me the Umbrella 208 IPs I am going to use the 146 equivalents?  I am simply going to block all traffic to 146.112.41.2 and .3 and see how the Macs respond.

[adamwin]

The Umbrella endpoint agent does not utilize DoH. The 146.112.41.2 address is definitely our DoH server though. It's possible that someone has their browser or OS configured to use doh.umbrella.com or these IP addresses. 

Blocking 208.67.22x.22x and 146.112.41.x on UDP and TCP 443 should force devices on the network to fall back to plaintext DNS on UDP 53, which your network device should be able to inspect and NAT. 

[tato386 · Accepted solution]

So what happened is that I added blocks for TCP/443 to all the popular DNS servers.  As I did that the Mac kept switching to other IPs so I added blocks to those as well and eventually I guess the Mac ran out of DNS servers to send TCP/443 packets to.  Here is my current list of IPs I block TCP/443 to:

Umbrella: 208.67.220.220, 208.67.222.222, 146.112.41.2, 146.112.41.5

Google: 8.8.8.8, 8.8.4.4, 146.112.61.106

Apple: 17.253.2.117

BoltDNS: 3.161.225.92, 3.161.225.120