The issue is also present on iOS, but not tvOS. I assume that’s because iCloud Private Relay is not available there.

More mDNSResponder logs: 2025-04-14 10:16:07.886 Df mDNSResponder[18627:44e303] [com.apple.mDNSResponder:Default] DNS service (1/3) -- id: 1, type: Do53, source: sc, scope: none, interface: /0, servers: {192.168.31.53:53}, domains: {.}, attributes: {a-ok, aaaa-ok}, interface properties: {ipv4, ipv6}, use count: 1 2025-04-14 10:16:07.886 Df mDNSResponder[18627:44e303] [com.apple.mDNSResponder:Default] DNS service (2/3) -- id: 2, type: Do53, source: sc, scope: interface, interface: en0/13, servers: {192.168.31.53:53}, domains: {.}, attributes: {a-ok, aaaa-ok}, interface properties: {ipv4, ipv6}, use count: 1 2025-04-14 10:16:07.886 Df mDNSResponder[18627:44e303] [com.apple.mDNSResponder:Default] DNS service (3/3) -- id: 3, type: Do53, source: sc, scope: interface, interface: ipsec0/22, servers: {[fd00:976a::9]:53, [fd00:976a::10]:53}, domains: {.}, attributes: {aaaa-ok}, interface properties: {ipv6}, use count: 1 ... 2025-04-14 10:16:10.346 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:mDNS] [R54] DNSServiceBrowse START -- service type: _smb._tcp., domain: home.arpa., flags: 0x0, interface index: 0, client pid: 18638 (dns-sd), 2025-04-14 10:16:10.346 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:mDNS] [R54] DNSServiceBrowse -> SubBrowser START -- qname: _smb._tcp.home.arpa. (64023839) 2025-04-14 10:16:10.347 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:Default] [R0->Q12962] Question assigned DNS service 1 2025-04-14 10:16:10.347 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:mDNS] [Q12962] mDNS_StartQuery_internal START -- qname: _smb._tcp.home.arpa. (64023839), qtype: SOA 2025-04-14 10:16:10.348 Db mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:Default] [R54->Q54619] Retrying path evaluation -- qname: _smb._tcp.home.arpa., qtype: PTR, reason: ResolverUUID may be stale 2025-04-14 10:16:10.348 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:Default] [R54->Q54619] Question for _smb._tcp.home.arpa. (PTR) assigned DNS service -- (null) 2025-04-14 10:16:10.348 Df mDNSResponder[18627:44e32e] [com.apple.mDNSResponder:Default] [Q54619] DetermineUnicastQuerySuppression: Query suppressed for _smb._tcp.home.arpa. PTR (no DNS service) 2025-04-14 10:16:10.348 Db mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q12962] Creating session to 192.168.31.53 2025-04-14 10:16:10.348 Df mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q12962] Sent 37-byte query #1 to 192.168.31.53 over UDP via any/0 -- id: 0x38FF (14591), flags: 0x0100 (Q/Query, RD, NoError), counts: 1/0/0/0, _smb._tcp.home.arpa. IN SOA? 2025-04-14 10:16:10.356 Df mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q12962] Received acceptable 108-byte response from 192.168.31.53 over UDP via any/0 -- id: 0x38FF (14591), flags: 0x8500 (R/Query, AA, RD, NoError), counts: 1/0/1/0, _smb._tcp.home.arpa. IN SOA?, home.arpa. 60 IN SOA ns.home.arpa. nobody.invalid. 1 3600 1200 604800 60 2025-04-14 10:16:10.356 I mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q12962] Querier concluded -- reason: response 2025-04-14 10:16:10.356 Df mDNSResponder[18627:44e326] [com.apple.mDNSResponder:Default] [Q12962] Handling concluded querier: _smb._tcp.home.arpa. SOA IN 2025-04-14 10:16:10.356 Df mDNSResponder[18627:44e326] [com.apple.mDNSResponder:mDNS] [Q12962] mDNS_StopQuery_internal STOP -- name hash: 64023839 2025-04-14 10:16:10.365 Df mDNSResponder[18627:44e309] [com.apple.mDNSResponder:Default] [R54->Q54619] Starting long-lived DNS polling -- polling interval: 15 min 2025-04-14 10:16:10.366 Df mDNSResponder[18627:44e309] [com.apple.mDNSResponder:Default] [R54->Q29523] Question for _smb._tcp.home.arpa. (PTR) assigned DNS service -- id: 4, type: ODoH, source: nw, scope: uuid (353A4F9C-CEF5-4CEE-93AD-4697BB0318D7), interface: /0, servers: {}, domains: {}, attributes: {a-ok, aaaa-ok, fail-fast, allows-failover}, interface properties: {ipv4, ipv6}, resolver config: {provider name: odoh.cloudflare-dns.com, provider path: /dns-query}, use count: 1 2025-04-14 10:16:10.368 Db mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q29523] Creating session to odoh.cloudflare-dns.com 2025-04-14 10:16:10.368 I mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q29523] Querier session event -- type: ready, error: 0/0x0 noErr 2025-04-14 10:16:10.370 Df mDNSResponder[18627:44e326] [com.apple.mdns:resolver] [Q29523] Sent 128-byte query #1 to odoh.cloudflare-dns.com over HTTPS via any/0 -- id: 0x0000 (0), flags: 0x0100 (Q/Query, RD, NoError), counts: 1/0/0/1, _smb._tcp.home.arpa. IN PTR?, . OPT 512 0 {EDE, code: 0}, {Padding, <70 zero bytes>} 2025-04-14 10:16:10.496 I mDNSResponder[18627:44e326] [com.apple.mdns:dns_service] Reporting success for service id: 4 2025-04-14 10:16:10.496 Df mDNSResponder[18627:44e309] [com.apple.mdns:resolver] [Q29523] Received acceptable 468-byte response from odoh.cloudflare-dns.com over HTTPS via any/0 -- id: 0x0000 (0), flags: 0x8183 (R/Query, RD, RA, NXDomain), counts: 1/0/1/1, _smb._tcp.home.arpa. IN PTR?, home.arpa. 604800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800, . OPT 1232 0 {Padding, <339 zero bytes>} 2025-04-14 10:16:10.496 I mDNSResponder[18627:44e309] [com.apple.mdns:resolver] [Q29523] Querier concluded -- reason: response

Assuming I'd want to provide a similar profile for my own app, what are the signing requirements for the Unified Logging System to recognize it and reveal masked values? Is this even available to general audience?

This is mentioned in RFC 6763 Section 11: The part of the query name may also be derived a different way, from the host's IP address. The host takes its IP address and calculates the logical AND of that address and its subnet mask, to derive the 'base' address of the subnet (the 'network address' of that subnet, or, equivalently, the IP address of the 'all-zero' host address on that subnet). It then constructs the conventional DNS "reverse mapping" name corresponding to that base address, and uses that as the part of the name for the queries described above. For example, if a host has the address 192.168.12.34, with the subnet mask 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, and to discover the recommended automatic browsing domain(s) for devices on this subnet, the host issues a DNS PTR query for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." I suppose mDNSResponder (stub DNS resolver on macOS) uses this approach not just for DNS-SD but in general.

Okay, confirmed that disabling iCloud Private Relay fixes the issue. Reported as FB17214559.

I'm a bit puzzled regarding why both Finder (Connect to Server->smb://gateway.home.arpa) and Safari (https://gateway.home.arpa) can successfully connect but dns-sd fails to resolve. AFAIK they both refer to the same stub resolver (mDNSResolver): $ dns-sd -q gateway.home.arpa. A DATE: ---Sat 12 Apr 2025--- 10:29:38.633 ...STARTING... Timestamp A/R Flags IF Name Type Class Rdata 10:29:38.634 Add 40000002 0 gateway.home.arpa. Addr IN 0.0.0.0 No Such Record $ dns-sd -q gateway.home.arpa. AAAA DATE: ---Sat 12 Apr 2025--- 10:29:41.623 ...STARTING... Timestamp A/R Flags IF Name Type Class Rdata 10:29:41.624 Add 40000002 0 gateway.home.arpa. AAAA IN 0.0.0.0 No Such Record

deleted

In the logs I see: Question for _smb._tcp.home.arpa. (PTR) assigned DNS service -- id: 7, type: ODoH, source: nw, scope: uuid (353A4F9C-CEF5-4CEE-93AD-4697BB0318D7), interface: /0, servers: {}, domains: {}, attributes: {a-ok, aaaa-ok, fail-fast, allows-failover}, interface properties: {ipv4, ipv6}, resolver config: {provider name: oblivious.r15.doh.dns.akasecure.net, provider path: /dns-query}, use count: 1 Which suggests that the mDNSResponder service attempted to forward .home.arpa. domain via ODOH, which is wrong per my interpretation of RFC 8375.

Thank you Kevin. I just found that there is the mDNSResponder configuration profile provided by Apple, which has the following payload: <key>PayloadContent</key> <array> <dict> <key>PayloadDisplayName</key> <string>Logging Payload For mDNSResponder/srp-mdns-proxy.</string> <key>PayloadIdentifier</key> <string>com.apple.system.logging.ED3E600C-83D8-44D0-BF5B-8A7F889CDBDE</string> <key>PayloadType</key> <string>com.apple.system.logging</string> <key>PayloadUUID</key> <string>ED3E600C-83D8-44D0-BF5B-8A7F889CDBDE</string> <key>PayloadVersion</key> <integer>1</integer> <key>Subsystems</key> <dict> <key>com.apple.mDNSResponder</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Info</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Sensitive</string> </dict> </dict> <key>com.apple.mdns</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Info</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Sensitive</string> </dict> </dict> <key>com.apple.srp-mdns-proxy</key> <dict> <key>DEFAULT-OPTIONS</key> <dict> <key>Enable-Oversize-Messages</key> <true/> <key>Level</key> <dict> <key>Enable</key> <string>Debug</string> <key>Persist</key> <string>Info</string> </dict> <key>Privacy-Enable-Level</key> <string>Private</string> </dict> </dict> </dict> </dict> </array> I wonder whether the value of <string>Sensitive</string> alongside the fact that the profile is signed by Apple allows to unmask the redacted parts in the logs. Update Looks like it worked! I understand it did not enable compile-time exclusions, but other than that seems to work. Or do I miss something?

FWIW the Wi-Fi network has the "Private Wi-Fi address" option set to Fixed but "Limit IP address tracking" set to Enabled. I'm an iCloud subscriber and iCloud Private Relay is on.

Thank you. Assuming I know what I'm looking for (I'm debugging why macOS does not display my Wire-Area DNS-SD services), can I calculate the hash separately to search the logs?

I since found that /Library/Filesystems is user-writable (but requires root). In order to expose mount_<filesystem> to autofs, the following directory can be added: /Library/Filesystems/<filesystem>.fs └── Contents └── Resources └── mount_<filesystem>

Are these agents owned by Apple or by some other 3rd party?

FWIW I have file the bug via Feedback Assistant: FB11958573

Interesting. I suspect that’s because the Applications folder is only writable by admin But the user that's launching the app is an admin (me). Anyway, why does writability of /Applications or even /Applications/.app affects the behavior? Isn't the actual value of the quarantine attribute stored in a db somewhere else, per-user?