Macbook not resolving Local DNS

I'm going to take a stab in the dark here and point the finger at IPv6.

Are you using IPv6 in your LAN? Do you have IPv6 addresses configured in your local DNS server?

There are many subtleties to IPv6 vs. IPv4 and while the default OS settings seem to work for most people, you may be the exception.

Since you mention resolv.conf and hosts, I'll assume you're competent in the shell, which makes this a little easier.

First, a couple of tests.

In terminal, run:

dig

at the bottom of the output (ignore the stuff in the middle for now), it will tell you the address of the server used for the query:

;; Query time: 9 msec
;; SERVER: 2600:1700:1155:3120::1#53(2600:1700:1155:3120::1)
;; WHEN: Tue Apr 29 12:00:56 PDT 2025
;; MSG SIZE  rcvd: 811

Here you can see a SERVER: response with an IPv6 address, indicating that my system is using IPv6 by default.

Contrast that with:

dig -4

which forces an IPv4 query, and I get:

;; Query time: 9 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Apr 29 12:02:21 PDT 2025
;; MSG SIZE  rcvd: 811

and you can see the IPv4 server address.

Does this match your experience? or does your default dig use IPv4?

More importantly, do the IP addresses match what you expect for your DNS server?

If not, then we need to work out why your system is using a different DNS server (could be malware, could be misconfiguration...).

If they are correct, drill down to query a specific hostname on your lan:

dig localserver
dig -4 localserver

What do you get?

What do you get if you use a FQDN for your local server?

dig localserver.local
dig -4 localserver.local

(or whatever would be appropriate for your local network).

As the last test, turn off (at least temporarily) IPv6 in Settings -> Network -> <interface> -> Details -> TCP/IP -> Configure IPv6 and re-run the tests.

Hopefully that will be enough to target next steps. Once we know which is working (or not) we can figure out what to do about it.

Your client is using 10.2.4.10 as the DNS server of record. Is that the IP address of your Windows Domain Controller?

If that's the case, and a query to that server for an address of a device on the LAN returns the public IP, then I think the problem lies in the Windows DNS server configuration, not with the client.

Either that, or the Mac is using an IP address that the DNS server doesn't think is 'internal' and therefore is returning the external/public address.

I don't know enough about Windows DNS Server to be able to help much there, other than knowing in most other DNS systems, such as BIND, there's a system of split DNS where different zone data is presented based on the client's IP (e.g. client on the LAN get a certain result, while clients from the external network get a different (or no) result). It sounds like this is the root of the problem (no pun intended), but I'm at a loss as to why this changed with the recent OS update.

Just to clarify something. Does the server you are trying to reach really have a ".local" TLD?

Dig is a tool to query nameservers. The results that it returns may be unrelated to your how devices actually resolve names.

You did print "localserver.local". Is that your DNS server? I don't know if that is an obfuscated version or if it really does end in ".local". If so, then all bets are off - for everything. All local names are managed with mDNS. You can use "dscacheutil -q host -a name example.com" to run a query from the command line. It doesn't have any debugging features. But it will tell you what's happening from a client's perspective.

Just because something was working for 8 years doesn't mean it hasn't been wrong for 8 years.

Darn, I was hoping IPv6 would be the trigger, but if that's off everywhere, it's a little more opaque.

Are you running your own internal DNS server? or are you relying on Bonjour/Autoconf for automatic name mapping on the LAN?

Fair point on the .local - I was assuming obfuscation, but I should know better and ask :)

I also admit I was initially pointing fingers at IPv6, and that didn't pan out... maybe I was over-thinking :)

.local aside, I hear what you're saying about dscacheutil, but there is a difference. dscacheutil, as its name suggests, will honor local caches and such, but it will ultimately be populated with data such as dig returns. Indeed, dscacheutil may mask a DNS server problem, which is where my mind went, whereas dig could expose it.

Until we get more detail from the OP, it's hard to know for sure.

Camelot wrote:

I hear what you're saying about dscacheutil, but there is a difference. dscacheutil, as its name suggests, will honor local caches and such, but it will ultimately be populated with data such as dig returns. Indeed, dscacheutil may mask a DNS server problem, which is where my mind went, whereas dig could expose it.

Certainly. I wish there was a tool that would really show all the steps of DNS resolution. Something like:

query: example.com

check /etc/hosts (not found)

check mDNS (not found)

check resolver 1: yada, yada, yada

check resolver n: yada, yada, yada

I think it's possible that this is a real undefined edge case of when the DNS server itself has a ".local" suffix. I don't know what would happen there.

Have you happened to find a solution? I'm on a Windows domain, local dns (adguard) is not resolving from the mac. Recently even local ips typed in manually to vnc (still works from a web browser) stopped working. There's something fishy though, because if I use a tailscale address for the same devices it all works. It's only the 192.168.0.0/23 addresses that aren't working too, because a UNIFI sitemagic with a 10.0.0.0/24 resolves just fine locally..

I'm losing my mind on this one, everything I think it's going to be isn't working. dig is resolving my local domain to cloudflare instead of going local like every other device we have... pis, windows, linux, just the mac isn't working right.