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

[aadamyan]

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:

Node	bundled c-ares	resolveSrv
22.18.0	1.34.5	OK
26.0.0	1.34.6	OK
26.5.0	1.34.6	OK
26.6.0	1.34.8	EBADRESP
26.7.0	1.34.8	EBADRESP
26.8.0	1.34.8	EBADRESP
26.8.1	1.34.8	EBADRESP
26.9.0	1.34.8	EBADRESP

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.

[avivkeller]

I can't reproduce on v26.9.0:

➜  repros npx envinfo

  System:
    OS: macOS 27.0
    CPU: (10) arm64 Apple M5
    Memory: 6.03 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 26.9.0 - /Users/avivkeller/.local/state/fnm_multishells/65712_1789998832980/bin/node
    Yarn: 1.22.22 - /Users/avivkeller/.npm-global/bin/yarn
    npm: 11.19.1 - /Users/avivkeller/.local/state/fnm_multishells/65712_1789998832980/bin/npm
    pnpm: 11.26.0 - /Users/avivkeller/.npm-global/bin/pnpm
    bun: 1.4.2 - /opt/homebrew/bin/bun
    Deno: 2.9.6 - /opt/homebrew/bin/deno
  Managers:
    Cargo: 1.98.1 - /Users/avivkeller/.cargo/bin/cargo
    Homebrew: 7.0.4 - /opt/homebrew/bin/brew
    pip3: 26.2.1 - /opt/homebrew/bin/pip3
    RubyGems: 3.0.3.1 - /usr/bin/gem
  Utilities:
    7z: 17.05 - /opt/homebrew/bin/7z
    CMake: 4.4.3 - /opt/homebrew/bin/cmake
    Make: 4.4.1 - /opt/homebrew/opt/make/libexec/gnubin/make
    GCC: 21.0.0 - /opt/homebrew/opt/ccache/libexec/gcc
    Git: 2.54.0 - /usr/bin/git
    Clang: 21.0.0 - /opt/homebrew/opt/ccache/libexec/clang
    Ninja: 1.13.2 - /opt/homebrew/bin/ninja
    FFmpeg: 9.0.1 - /opt/homebrew/bin/ffmpeg
    Curl: 8.7.1 - /usr/bin/curl
    OpenSSL: 3.6.4 - /opt/homebrew/bin/openssl
    ccache: 4.14 - /opt/homebrew/bin/ccache
  Servers:
    Apache: 2.4.67 - /usr/sbin/apachectl
  Virtualization:
    Docker: 29.5.3 - /usr/local/bin/docker
    Docker Compose: 5.1.4 - /usr/local/bin/docker-compose
  SDKs:
    iOS SDK:
      Platforms: DriverKit 27.0, iOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, watchOS 27.0
  IDEs:
    IntelliJ: 2026.2.1
    VSCode: 1.138.0 - /usr/local/bin/code
    Claude Code: 2.1.278 - /Users/avivkeller/.local/bin/claude
    Codex: 0.154.0 - /opt/homebrew/bin/codex
    Vim: 9.1 - /usr/bin/vim
    Xcode: 27.0/27A266a - /usr/bin/xcodebuild
  Languages:
    Bash: 5.3.15 - /opt/homebrew/bin/bash
    Go: 1.27.1 - /opt/homebrew/bin/go
    Java: 26.0.2.1 - /usr/bin/javac
    Perl: 5.34.1 - /usr/bin/perl
    Python: 3.14.7 - /opt/homebrew/opt/python@3.14/libexec/bin/python
    Python3: 3.14.7 - /opt/homebrew/bin/python3
    R: 4.6.1 - /usr/local/bin/R
    Ruby: 2.6.10 - /usr/bin/ruby
    Rust: 1.98.1 - /Users/avivkeller/.cargo/bin/rustc
    Zig: 0.16.0 - /opt/homebrew/bin/zig
  Databases:
    SQLite: 3.54.0 - /usr/bin/sqlite3
  Browsers:
    Brave Browser: 153.1.95.104
    Chrome: 153.0.8010.48
    Safari: 27.0

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

[aadamyan]

Thanks for taking a look. You can't reproduce it because one claim in my original report is wrong — and unfortunately it's the one that would have pointed you at the cause. This is resolver-dependent. Re-tested today on the same machine and the same build:

resolver	resolveSrv on v26.9.0
8.8.8.8 / 1.1.1.1 / 9.9.9.9, set explicitly	OK — 18/18 across 3 rounds, both dns.setServers() and new dns.Resolver()
system resolver (172.20.10.1)	EBADRESP

I got that line wrong when I filed it; sorry for the runaround.

The trigger is the wire format of the response

That system resolver is an iOS Personal Hotspot DNS proxy, and it emits the SRV TARGET as a compression pointer. Google Public DNS writes it out in full. Same record either way — calendar.google.com:443:

172.20.10.1   ... 0005 0000 01bb 08 "calendar" c01a                      rdlength 0x11  <- compressed
8.8.8.8       ... 0005 0000 01bb 08 "calendar" 06 "google" 03 "com" 00   rdlength 0x1b  <- literal

Network-independent repro (replays both captured responses from a local UDP socket — no DNS server, no particular network):

node v22.18.0  (c-ares 1.34.5)     compressed -> OK        literal -> OK
node v26.5.0   (c-ares 1.34.6)     compressed -> OK        literal -> OK
node v26.6.0   (c-ares 1.34.8)     compressed -> EBADRESP  literal -> OK
node v26.7.0   (c-ares 1.34.8)     compressed -> EBADRESP  literal -> OK
node v26.8.1   (c-ares 1.34.8)     compressed -> EBADRESP  literal -> OK
node v26.9.0   (c-ares 1.34.8)     compressed -> EBADRESP  literal -> OK

Root cause — already known upstream

c-ares 1.34.7 shipped c-ares/c-ares#1190, which made the parse path reuse the write-side RFC 3597 policy and reject compression pointers in RDATA for types outside the RFC 1035 set — SRV included. Node picked it up in the 1.34.6 → 1.34.8 bump in v26.6.0, which is exactly where my bisect landed.

RFC 3597 §4 asks receivers to be more lenient than senders, and calls out SRV by name:

Receiving servers MUST decompress domain names in RRs of well-known type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV (although the current specification of the SRV RR in [RFC2782] prohibits compression, [RFC2052] mandated it, and some servers following that earlier specification are still in use).

Upstream tracking:

• SRV replies with compressed TARGET rejected since 1.34.7, breaking SSSD/Samba AD integration (regression from #1190) c-ares/c-ares#1287 — same regression, reported 2026-09-01, breaking SSSD/Samba AD service discovery. Fedora and ALT Linux have both reverted the commit downstream.
• Accept compressed SRV/SIG/NAPTR names when parsing responses c-ares/c-ares#1290 — proposed fix (a separate, more permissive allow-list for the read path). Open and unreviewed since 2026-09-03.
• Go went through the identical cycle: net: cannot resolve SRV records with compressed targets golang/go#36718, strict check removed in Go 1.23.

Why it's worth tracking on the Node side

mongodb+srv:// performs an SRV lookup before connecting, so on any network whose resolver compresses SRV targets, every Atlas connection string fails on Node >= 26.6.0. Verified here against a real cluster hostname: the hotspot returns three SRV records whose targets all use c029 pointers; v26.5.0 parses them, v26.9.0 returns EBADRESP. iOS Personal Hotspot and Samba AD DC both compress, so tethered developers and corporate AD networks are the two populations that hit this.

There's nothing to fix in Node's own code — but this reached users as a silent break in a patch-level c-ares bump, so it seems worth tracking c-ares#1290 for the next update. Happy to keep this open as the Node-side tracking issue, or close it in favour of the upstream one — whichever you prefer.

Repro script

// Self-contained repro — no network, no specific DNS server needed.
// Serves two canned SRV responses for _caldavs._tcp.google.com, captured off the wire:
//   A) TARGET as a compression pointer (iOS Personal Hotspot DNS proxy, Samba AD DC, ...)
//   B) TARGET written out in full      (Google Public DNS, Cloudflare, Quad9, ...)
// Both decode to the same record: calendar.google.com:443.
const dgram = require('dgram')
const dns = require('dns')

const RESPONSES = {
  'compressed TARGET':
    'cc3481800001000100000000085f63616c64617673045f74637006676f6f676c6503636f6d0000' +
    '210001c00c002100010000113100110005000001bb0863616c656e646172c01a',
  'literal TARGET':
    'cc3481800001000100000000085f63616c64617673045f74637006676f6f676c6503636f6d0000' +
    '210001c00c0021000100005460001b0005000001bb0863616c656e64617206676f6f676c650363' +
    '6f6d00'
}

const serve = hex => new Promise(resolve => {
  const canned = Buffer.from(hex, 'hex')
  const s = dgram.createSocket('udp4')
  s.on('message', (msg, rinfo) => {
    const out = Buffer.from(canned)
    msg.copy(out, 0, 0, 2) // echo the query id
    s.send(out, rinfo.port, rinfo.address)
  })
  s.bind(0, '127.0.0.1', () => resolve(s))
})

const lookup = port => new Promise(resolve => {
  const r = new dns.Resolver()
  r.setServers([`127.0.0.1:${port}`])
  r.resolveSrv('_caldavs._tcp.google.com', (e, recs) =>
    resolve(e ? `ERROR ${e.code}` : JSON.stringify(recs)))
})

;(async () => {
  console.log(`node ${process.version}  (c-ares ${process.versions.ares})\n`)
  for (const [label, hex] of Object.entries(RESPONSES)) {
    const s = await serve(hex)
    console.log(`  ${label.padEnd(20)} -> ${await lookup(s.address().port)}`)
    s.close()
  }
})()