macOS 26 breaks custom DNS settings including .internal

The latest macOS 26 update stealthily sabotages a long-standing custom DNS feature, rendering /etc/resolver/ files useless for non-IANA TLDs like .internal. This "silent papercut" breaks critical local development environments, from Docker to Kubernetes, frustrating developers who rely on predictable system behavior. The bug not only creates cumbersome workarounds but also fuels broader HN discussions on Apple's increasingly developer-hostile operating system choices.

Score

Comments

Highest Rank

on Front Page

First Seen

Mar 19, 3:00 PM

Last Seen

Mar 19, 7:00 PM

Rank Over Time

The Lowdown

macOS 26 has introduced a significant regression for developers, silently breaking custom DNS resolution for certain top-level domains (TLDs) by ignoring configurations in /etc/resolver/. This issue impacts a widely used and documented mechanism crucial for local development workflows.

The system's mDNSResponder now intercepts queries for custom TLDs (e.g., .internal, .test, .lan, or arbitrary custom TLDs) and incorrectly treats them as mDNS, completely bypassing the specified unicast nameserver in /etc/resolver/ files.
This /etc/resolver/ mechanism, documented in man 5 resolver and relied upon for over a decade, is essential for local development setups using tools like dnsmasq, Docker Desktop, Vagrant, and Kubernetes (minikube, kind, k3d).
Notably, .test, a TLD explicitly reserved by RFC 6761 for local testing, is also affected, despite clear specifications that resolvers should handle it via normal DNS.
The failure is insidious: scutil --dns still reports the correct resolver configuration, but applications using getaddrinfo() fail to resolve hostnames, receiving silent "Unknown host" errors without diagnostic logging.
The only immediate workaround is to manually add entries to /etc/hosts, which is highly impractical for dynamic development environments where host entries change frequently.

This bug creates substantial friction for macOS developers, forcing reliance on cumbersome workarounds and undermining years of established best practices, reinforcing concerns about Apple's commitment to its developer ecosystem.

The Gossip

Apple's Developer Despair

Many commenters express frustration with Apple's perceived tendency to break established developer workflows and introduce "papercuts" that make macOS less developer-friendly. Some wish for Apple's software and hardware divisions to split, while others cite these issues as reasons for migrating to other operating systems like Linux. General criticisms about macOS's "amateur" tendencies and system update policies are also prevalent.

DNS Detours & Developer Dilemmas

The discussion delves into potential workarounds and alternative approaches for managing local DNS. Some suggest that the `/etc/resolver/` method might be deprecated and propose using `scutil` directly. Others explore network-level solutions like PiHole or provide detailed configurations for `unbound` on Linux, highlighting the complexity developers face when system-level features fail. Many are actively seeking or sharing viable short-term solutions to avoid updating macOS.

LLM Language Lapses

A tangent emerged regarding the use of Large Language Models (LLMs) for writing bug reports, prompted by the original author's mention of using Claude. Critics argue that LLM-generated reports, if not thoroughly reviewed, can contain inaccuracies (like citing "macOS 25"), making them less trustworthy. There's debate on the ethics of using LLMs for formal communication, with some arguing it's fine for drafts if followed by human review, while others express a preference for imperfect human-written text over potentially inauthentic AI output.