Repository navigation
dns.resolveMx returns invalid result in Node <22 #53708
Description
Version
v20.15.0
Platform
linux & docker
Subsystem
dns
What steps will reproduce the bug?
I have this code:
const dns = require('dns');
const ign = dns.resolveMx("blek.cz", (err, addresses) => console.log([err, addresses]));
And results:
$ docker run -ti node:16 node
[ null, [ { exchange: 'blekmx1.blek.cz', priority: 100 } ] ]
$ docker run -ti node:18 node
[ null, [ { exchange: 'blek.cz', priority: 100 } ] ]
$ docker run -ti node:20 node
[ null, [ { exchange: 'blek.cz', priority: 100 } ] ]
$ docker run -ti node:20-alpine node
[ null, [ { exchange: 'blek.cz', priority: 100 } ] ]
$ docker run -ti node:22 node
[ null, [ { exchange: 'blekmx1.blek.cz', priority: 100 } ] ]
How often does it reproduce? Is there a required condition?
Might be system/resolver dependent. Also there should be something unusual about this particular domain
What is the expected behavior? Why is that the expected behavior?
$ dig +short mx blek.cz
100 blekmx1.blek.cz.
What do you see instead?
Bare "blek.cz" host even don't have SMTP port open so it makes emails undeliverable
Additional information
No response
Activity
JQuags commentedon Jul 4, 2024
I am able to reproduce this on freebsd (13.3) with blek.cz and visa.com but not gmail.com and other domains however unlike the above test it also is an issue in v22.3.0 installed from ports.
targos commentedon Jul 5, 2024
I verified that it was fixed by #53155 in Node.js 22.3.0.
Probably due to this (from c-ares changelog):
avivkeller commentedon Jul 6, 2024
Does that make this is a known limitation?
targos commentedon Jul 6, 2024
No
avivkeller commentedon Jul 6, 2024
So, IIUC the solution would be to backport c-ares/c-ares@d7c14a1?
targos commentedon Jul 6, 2024
No, the solution is to cherry-pick or backport #53155. That's why I added lts-watch- labels to it.
avivkeller commentedon Jul 6, 2024
Oh, thanks, I don't know that much about backporting, thanks for the info!