macOS 26 breaks custom DNS settings including .internal (gist.github.com)

390 points by adamamyl ↗ HN
One of those 'woke up to MacOS updates' and finding none of my dockers are reachable via dnsmasq (which I use), and low and behold, an update silently breaks custom dns resolution. Hopefully Apple will listen to the bug report I've made. Hold off on updating if you use this…

58 comments

[ 15.7 ms ] story [ 467 ms ] thread
(comment deleted)
Before others jump in: I already use Linux (and used to run FreeBSD as my desktop operating system).
(comment deleted)
If you have ScreenTime turned on. Port :8080 is occupied and your ubuntu apt-get in a docker build gets hash mismatch because they obviously modified packets. Let alone I am having another issue of unable to delete a private key in Keychain Access.

The whole macOS thing is amateur

(comment deleted)
I run a setup like that on my (outdated) Yosemite machine to provide multiple private TLDs for local deployment/development needs.

I set that up in like 2014? Even back then it was known already that the quick /etc/resolver way was the deprecated way to do things. So I guess they finally killed that feature off?

The proper (more awkward) way is to use scutil directly (which then stores the settings in some binary plist somewhere, I assume).

Maybe try this and see if it still works afterwards?

Still wishing for the day apple is split into the hardware and the software company. I want their silicon, but I will never use their (arguably terrible) operating system. If I can't run my own kernel and kernel modules then it's a device that I don't own. Firmware is alright in some cases, but my laptop next to me is running core boot just to prove a point.
Papercuts like this are why I moved away from macOS.

I will say, I don't love the use of LLMs to write these bug reports. It's probably fine if reviewed, but at least review for things like "worked on macOS 25", which obviously didn't exist. If that wasn't caught, how sure are you that the rest of the report is accurate? We all want the bugs fixed, but people are going to start throwing out the obviously LLM written reports rather than have to validate each claim, since the author probably didn't.

> but people are going to start throwing out the obviously LLM written reports rather than have to validate each claim,

So nothing will change as Apple is renown for throwing out reports?

Has anyone found a working workaround yet? I use dnsmasq for .local dev routing and held off updating after seeing this but curious if there is a viable path forward short of waiting for Apple to patch it.
Solved this type of shenanigans some years ago with this.

New-UnboundInterface.sh - linux/rhel-like specific

    # create a bridge interface for Unbound
    # because Docker...
    IFTYPE=bridge
    IFNAME=unbound0
    IPADDR=10.53.0.1
    IPADDR6=fd53:fd53:fd53::1
    nmcli connection add type $IFTYPE ifname $IFNAME
    nmcli connection modify $IFTYPE-$IFNAME ip4 $IPADDR/32
    nmcli connection modify $IFTYPE-$IFNAME ipv4.dns $IPADDR
    nmcli connection modify $IFTYPE-$IFNAME ip6 $IPADDR6/64
    nmcli connection modify $IFTYPE-$IFNAME ipv6.dns $IPADDR6
    nmcli connection up $IFTYPE-$IFNAME

    firewall-cmd --new-zone=unbound --permanent
    firewall-cmd --zone=unbound --permanent --change-interface=$IFNAME
    firewall-cmd --zone=unbound --permanent --add-service=dns
    firewall-cmd --reload
00-localinterface.conf

    # should be placed in /etc/unbound/conf.d
    # bind to a specified IP address, allow access
    server:
            interface: 10.53.0.1
            interface: fd53:fd53:fd53::1
            access-control: 10.53.0.1/32 allow
            access-control: fd53:fd53:fd53::1/128 allow
91-allow-docker-containers.conf

    # allow queries from the Docker "bridge"
    server:
            access-control: 172.18.0.1/16 allow
I've been using macOS since OS X Tiger and I wasn't aware of this feature.
It also seemingly broke removing Safari cookies on a per website basis, something I often used to stop Google's scummy tracking across all their services if you just want to sign into YouTube.
FYI the phrase is "lo and behold"

Thank you for the heads up.

Bit off-topic. I mostly use Linux and I'm of the opinion that it's miles better than Windows, but I don't fully understand why people say MacOS looks bad?

Ignoring the current Tahoe mess, MacOS felt relatively polished. I'm purely talking about UX here, as the OS is evidently buggy. The most popular Gnome themes are a re-impl of MacOS, so I can't be the only one.

There are many examples of the UX going backwards or getting unnecessarily reinvented with each release, which is attributed to the feature‑creep culture at Apple. One notable example would be the notification dialog.
I think you gotta actually try to use it as your main OS to hit some of the snags. It can browse the web just fine, but I couldn't get sshfs working. There were strange global keyboard shortcuts, rarely actually used, breaking common shortcuts like ctrl + left/right arrow (fixable, but not super trivially). Homebrew is better than nothing but pretty jank in practice. Repeatedly I'd see graphical stuff installed from there was declared broken and I was pressured to delete it, or I'd have to reapprove some security thing after an update and add it back to the dock. Just lots of friction everywhere. I couldn't seem to consistently keep windows the same size and in the same spots, but they were almost right which made it more maddening. It was like they'd slide around slightly after a reboot or changing monitors. Speaking of monitors, low DPI fonts on macOS look inexcusably horrible. The same monitors I've used for years displaying similar stuff just looked absolutely awful on macOS compared to GNU/Linux. I never was able to fix this. I suspect in their pushing of hidpi and their own hardware they've mangled and abandoned classic resolutions and fonts. This one can barely even be discussed online because everyone's drank the hidpi koolaid and will call you poor or perverse or something. There was also a horribly annoying issue when trying to use a MBP like a desktop. If left inactive too long, I couldn't seem to wake and unlock it with my external keyboard and mouse connected to a dock. I had to open the laptop lid, log in there, re-allow my input devices, then close the lid. I also had to repeatedly go through that wizard that tries to identify your keyboard layout by having you press the key beside each shift key, as if it'd never seen my keyboard before. I have used this same keyboard on GNU/Linux and Windows, there's no equivalent to that needed, I don't really get it.

It's all bad enough that I have a very expensive machine collecting dust until Asahi supports multi-monitors fully. It was a good reminder of how important software and familiarity is, and how much you stand to lose by just chasing after better specs at all costs. I really just wanted my exact usual setup with a spec bump (which I eventually got when I upgraded from my T440p to a T14 Gen 5).

As for positives of macOS... I like the unix-y bits, what's left of them. If I have to retrieve pictures off an old Mac for someone's funeral board, the find command I know and love is there, and a familiar shell as well. I just can't live in macOS full time. It's not good enough for me.

(comment deleted)
I am not familiar with dnsmasq at all (is this machine-local?), but absolutely love my PiHole hardware — you can even create rules which intercept hard-coded-IP DNS request and/or httpsDNS. You can also hard-code/intercept .TLD to local service IPs.

Programs like LittleSnitch never really seem like "enough" for me, because the computer has to boot before DNS filtering comes online. It also has the design error (IMHO) of pre-resolving IP addresses before clicking Accept/Deny(all).

A great blockrule for your personal firewalls would be to ban (at top level) icloud.com, apple.com, &c; system updates can then be performed manually using guides like <http://www.mrmacintosh.com>. Of course: this breaks everything (in exactly the way I prefer to compute).

*.localhost works out of the box doesn’t it? You don’t need dnsmasq at all to have multiple hostnames pointing to 127.0.0.1.
A couple iOS versions ago, Apple broke self-signed certificates... crippling mobile development by preventing the use of HTTPS to communicate with a local server.

It makes you wonder why they were messing around in these areas at all at this point.

(comment deleted)
Apple container CLI configures internal domains (`container system dns`) by adding an internal resolver and it worked for me when I specified an actual domain previously handled by external DNS and it showed up as a custom resolver.

Here’s a GitHub comment showing someone on MacOS 26 with a `.test` domain, which you claim is broken: https://github.com/apple/container/issues/856#issuecomment-3... —- maybe you are configuring it incorrectly.

It's not quite the same, but I've moved to using *.localhost for all my local web dev work. All modern browsers will resolve *.localhost to 127.0.0.1 internally. No need to setup any DNS resolvers or edit your hosts file.

But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()