dns.resolveSrv returns EBADRESP for all existing SRV records on macOS since v26.6.0 (c-ares 1.34.8)

Start with the dns.resolveSrv entry point and reproduce the reported command on macOS, comparing the bundled c-ares 1.34.8 behavior with earlier versions. Check the SRV response handling against the working dig result and earlier Node.js releases; done means existing SRV records resolve successfully without regressing the other DNS record types.

Version

v26.9.0 (also v26.6.0, v26.7.0, v26.8.0, v26.8.1)

Platform

Darwin 24.6.0 arm64 (macOS 15.6.1, build 24G90)

Subsystem

dns

What steps will reproduce the bug?

require('dns').resolveSrv('_caldavs._tcp.google.com', (e, r) => console.log(e ? `ERROR ${e.code}: ${e.message}` : r))

How often does it reproduce? Does it reproduce on all platforms?

Every time, on macOS arm64. resolveSrv fails for every SRV name that exists; names that do not exist still return ENOTFOUND correctly. It is not resolver-specific — it fails identically against the system resolver, 8.8.8.8, 1.1.1.1 and 9.9.9.9, while dig parses the same response correctly from the same resolver.

Only SRV is affected. On the same broken build, resolve4, resolve6, resolveMx, resolveTxt, resolveNs, resolveCname, resolveCaa, resolveSoa and resolveNaptr all succeed.

What is the expected behavior? Why is that the expected behavior?

[ { name: 'calendar.google.com', port: 443, priority: 5, weight: 0, type: 'SRV' } ]

This is what v26.5.0 and earlier return, and it matches the record dig SRV _caldavs._tcp.google.com returns on the same machine.

What do you see instead?

ERROR EBADRESP: querySrv EBADRESP _caldavs._tcp.google.com

Additional information

Bisected on the same machine and network. The break lines up exactly with the bundled c-ares bump from 1.34.6 to 1.34.8 in v26.6.0:

Reproduced with several unrelated public SRV names (_caldavs._tcp.google.com, _sip._udp.sip.voice.google.com), so it is not specific to one zone or response shape.

Practical impact: any mongodb+srv:// connection string fails to connect on affected versions, because that scheme performs an SRV lookup before connecting. The TXT lookup the same driver performs against the same hostname succeeds, so it is specifically the SRV query that fails.

This may share a root cause with #62326 (dns.resolveSrv failing since v24.13.0) and the incomplete fix in #61453, but that report is Windows-only and surfaces as ECONNREFUSED; this is macOS and surfaces as EBADRESP, so filing separately.