[GH-ISSUE #2022] [AmneziaWG macOS] DNS servers from config not applied to system resolver #880

New issue

Open

opened 2026-10-13 20:30:30 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-13 20:30:30 +00:00

Owner

Originally created by @lexfrei on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2022

Component

AmneziaWG for macOS (amneziawg-apple)

Description

DNS servers specified in the WireGuard configuration file are not properly registered with the macOS system resolver. While dig can resolve hostnames using the configured DNS server, applications (Safari, Chrome, etc.) and dscacheutil cannot resolve internal domains.

Environment

macOS Tahoe 26.1 (Darwin 25.1.0)
MacBook Pro 16-inch (Nov 2023), Apple M3 Pro
AmneziaWG 1.0.1 (6)

Configuration

[Interface]
PrivateKey = <redacted>
Address = 10.8.1.5/32
DNS = 172.16.0.1, 1.0.0.1
# ... AWG obfuscation parameters ...

[Peer]
PublicKey = <redacted>
AllowedIPs = ::/0, 0.0.0.0/0
Endpoint = example.com:48142

Observed Behavior

dig works correctly — queries go through tunnel DNS:

$ dig internal.home.example.com
;; ANSWER SECTION:
internal.home.example.com.  0  IN  A  172.16.10.19
;; SERVER: 172.16.0.1#53

System resolver fails — dscacheutil returns empty:

$ dscacheutil -q host -a name internal.home.example.com
(no output)

scutil --dns shows resolver with Supplemental flag:

resolver #1
  nameserver[0] : 172.16.0.1
  nameserver[1] : 1.0.0.1
  if_index : 27 (utun4)
  flags    : Supplemental, Request A records   <-- should not be Supplemental
  reach    : 0x00000003 (Reachable,Transient Connection)
  order    : 104400

Browsers cannot resolve internal domains — "Safari Can't Find the Server"

Expected Behavior

DNS servers from config should be registered as the primary resolver (not Supplemental) when AllowedIPs = 0.0.0.0/0 is set, matching the behavior of the official WireGuard.app.

Workaround

Creating a manual resolver file works:

sudo mkdir -p /etc/resolver
echo "nameserver 172.16.0.1" | sudo tee /etc/resolver/home.example.com

Analysis

I compared the source code of AmneziaWG and official WireGuard.app. The DNS configuration in PacketTunnelSettingsGenerator.swift is identical:

if !tunnelConfiguration.interface.dns.isEmpty {
    dnsSettings.matchDomains = [""] // All DNS queries must first go through tunnel's DNS
}

The matchDomains = [""] should route all DNS through the tunnel, but macOS registers it as Supplemental instead of primary resolver.

Possibly related to how/when setTunnelNetworkSettings is called, or to code signing differences affecting Network Extension trust level.

References

Related Apple Developer Forums discussion about inconsistent matchDomains behavior: https://developer.apple.com/forums/thread/133338

Originally created by @lexfrei on GitHub (Nov 26, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2022 ## Component AmneziaWG for macOS (amneziawg-apple) ## Description DNS servers specified in the WireGuard configuration file are not properly registered with the macOS system resolver. While `dig` can resolve hostnames using the configured DNS server, applications (Safari, Chrome, etc.) and `dscacheutil` cannot resolve internal domains. ## Environment - macOS Tahoe 26.1 (Darwin 25.1.0) - MacBook Pro 16-inch (Nov 2023), Apple M3 Pro - AmneziaWG 1.0.1 (6) ## Configuration ```ini [Interface] PrivateKey = <redacted> Address = 10.8.1.5/32 DNS = 172.16.0.1, 1.0.0.1 # ... AWG obfuscation parameters ... [Peer] PublicKey = <redacted> AllowedIPs = ::/0, 0.0.0.0/0 Endpoint = example.com:48142 ``` ## Observed Behavior 1. **`dig` works correctly** — queries go through tunnel DNS: ``` $ dig internal.home.example.com ;; ANSWER SECTION: internal.home.example.com. 0 IN A 172.16.10.19 ;; SERVER: 172.16.0.1#53 ``` 2. **System resolver fails** — `dscacheutil` returns empty: ``` $ dscacheutil -q host -a name internal.home.example.com (no output) ``` 3. **`scutil --dns` shows resolver with `Supplemental` flag**: ``` resolver #1 nameserver[0] : 172.16.0.1 nameserver[1] : 1.0.0.1 if_index : 27 (utun4) flags : Supplemental, Request A records <-- should not be Supplemental reach : 0x00000003 (Reachable,Transient Connection) order : 104400 ``` 4. **Browsers cannot resolve internal domains** — "Safari Can't Find the Server" ## Expected Behavior DNS servers from config should be registered as the primary resolver (not `Supplemental`) when `AllowedIPs = 0.0.0.0/0` is set, matching the behavior of the official WireGuard.app. ## Workaround Creating a manual resolver file works: ```bash sudo mkdir -p /etc/resolver echo "nameserver 172.16.0.1" | sudo tee /etc/resolver/home.example.com ``` ## Analysis I compared the source code of AmneziaWG and official WireGuard.app. The DNS configuration in `PacketTunnelSettingsGenerator.swift` is identical: ```swift if !tunnelConfiguration.interface.dns.isEmpty { dnsSettings.matchDomains = [""] // All DNS queries must first go through tunnel's DNS } ``` The `matchDomains = [""]` should route all DNS through the tunnel, but macOS registers it as `Supplemental` instead of primary resolver. Possibly related to how/when `setTunnelNetworkSettings` is called, or to code signing differences affecting Network Extension trust level. ## References - Related Apple Developer Forums discussion about inconsistent `matchDomains` behavior: https://developer.apple.com/forums/thread/133338

bsakaguchi referenced this issue

2026-10-13 21:19:13 +00:00

[PR #880] [MERGED] add artifact with translations and update Russian translation #2164