Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

Original Article ↗ Hacker News Discussion ↗

A bug in the Little Snitch 6.1 firewall caused its DNS encryption feature to be bypassed in some cases on macOS, initially raising fears that Apple’s new Sequoia release was circumventing system-level DNS privacy tools. Further investigation showed the issue was specific to Little Snitch and quickly fixed in version 6.1.1, but it reignited concerns about Apple’s complex, evolving networking stack, the reliability of user‑space DNS proxies, and applications that bypass system DNS settings for their own resolvers. Commenters also debated the status of traditional APIs like `getaddrinfo()`, the challenges of encrypted DNS on modern OSes, and who should ultimately control DNS resolution: the operating system, the app, or the network owner.

Scope and nature of the bug

  • Initial blog implied a macOS Sequoia DNS-encryption bypass; later investigation showed:
    • The behavior existed at least since macOS 14.5 Sonoma.
    • Final update: it was specific to Little Snitch 6.1’s DNS encryption proxy, not a general macOS bug, and fixed in 6.1.1.
  • Some felt the HN title and early framing overstated Apple’s responsibility; others argued that if the OS offers a DNS proxy API, any code path that bypasses it is still an OS-level problem.

DNS proxies, APIs, and Apple’s networking stack

  • Little Snitch implements encrypted DNS by acting as a system DNS proxy; some resolver paths (e.g., via getaddrinfo()) did not go through that proxy.
  • Commenters note Apple removed kernel extensions and replaced them with user-space network-filter APIs, but some traffic has historically bypassed these.
  • macOS has multiple DNS/network paths: POSIX APIs, CFNetwork, Network.framework, browser-specific resolvers, etc., making a single control point hard.

getaddrinfo vs. “modern” APIs and POSIX discussion

  • Debate over labeling getaddrinfo() as “low-level legacy”:
    • Many see it as the standard POSIX/UNIX, cross-platform way to resolve names.
    • Others emphasize Apple’s preference for higher-level “connect-by-name” APIs (Network.framework, CFNetwork) that enable Happy Eyeballs and other optimizations.
  • Long tangent on POSIX compliance:
    • macOS is/was POSIX-certified; Linux and BSDs are mostly compatible but not certified.
    • Some argue portability via POSIX is valuable; others call it “lowest common denominator” and prefer platform-specific features.

Sequoia firewall and DNS/UDP breakage

  • Reports that macOS 15 Sequoia’s firewall, when set to “block incoming connections,” can break DNS/UDP and web browsing for some apps.
  • Workarounds mentioned: changing DNS servers, toggling app local-network permissions, or disabling the firewall; some issues traced to third‑party filters (e.g., antivirus network extensions).

Control over DNS vs. app-specific resolvers

  • Strong disagreement over apps bypassing system DNS:
    • Some want all DNS to honor OS settings and firewalls; apps doing their own DNS/DoH are described as effectively malware-like.
    • Others defend app-level DNS (e.g., browsers, IoT devices) for reliability, privacy, or per-app configuration.
  • Network admins describe enforcing DNS centrally (Pi-hole, intercepting port 53, allowlisting IPs that come only from “trusted” DNS lookups), but note DoH and hardcoded IPs make this a cat‑and‑mouse game.