Repository navigation
dns: Add DNSSEC support #14475
Description
Activity
FWIW you should already be able to use DNSSEC via
dns.lookup()(which is what all of node core uses by default) if your system resolver is properly configured.For c-ares (which powers
dns.resolve*()), there does not seem to be DNSSEC support yet, so I think that would need to be added upstream first.I think we should open an Issue on c-ares first?
This issue has been open for two weeks with no movement. Anyone want to take it up with the c-ares maintainers? FWIW, I follow the c-ares mailing list and there has been little discussion on DNSSEC so far.
@bnoordhuis My recent inquiry to their mailing list didn't get any attention, and the only relevant PR I can find is c-ares/c-ares#20, which was closed after more than two years without being merged, and with months of inactivity 😕
Yes, I saw that PR. I think the conclusion has to be that upstream support isn't going to happen anytime soon.
For people coming here through search engines, the status at the time of writing is that:
dns.lookup()transparently supports DNSSEC if the system resolver does.dns.resolve()and friends do not.
Closing, blocked on upstream support.
Reacted by Gus Narea, Jelle De Loecker and VladWhat's the point of having two different dns libs integrated into one? Why not simply remove the c-ares dependency and refactor the dns.js methods to use the system resolver, just like
dns.lookup()already does?Edit: Sorry, I didn't notice the issue ref regarding c-ares. (iOctocat doesn't list them)
@fvdm Performance. The system resolver is usually fuller featured but it tends to fall over when you do 10,000 lookups in parallel.
I'd be happy to contribute https://github.com/relaycorp/dnssec-js to the standard library. Would there be any interest in this? We've been using it in VeraId for a few years.
With today's security requirements and Node.js being an important framework, DNSSEC support and validation are becoming very important for all sorts of applications ranging from API clients to IoT devices.
Node dns.js is missing:
EBADRESPerror while the requested resource is perfectly valid.rrtypefordns.resolve()and a newdns.resolveRrsig()method.dns.setVerify(true)to not cause interface trouble.I don't know much about the technical part of DNSSEC and how to implement it in Node, but I did notice the results are in line with
dig hostnameon the shell. For example,is similar to:
$ dig myhostname.net a ;; ANSWER SECTION: myhostname.net. 1382 IN A 37.97.204.102while requesting ANY
rrtypereturns an error:compared to dig with clearly the DS and RRSIG included:
$ dig myhostname.net any ;; ANSWER SECTION: myhostname.net. 83764 IN NS ns1.transip.net. myhostname.net. 964 IN A 37.97.204.102 myhostname.net. 83764 IN DS 1560 7 1 B564B27573CEC3AC428BA606B4656A0CF85F5B2E myhostname.net. 964 IN AAAA 2a01:7c8:aac3:41b::1 myhostname.net. 83764 IN NS ns0.transip.nl. myhostname.net. 83764 IN NS ns2.transip.eu. myhostname.net. 83764 IN RRSIG DS 8 2 86400 20170730051458 20170723040458 57899 net. nDlnsdcnLynmq7U+wKUYRjV8NBiRo/YcnqtBdM4Sgp8lmNwB6EN97Dbn MpIm+lqnj+r6kWHPQ1fpTZBhBR4qrC+V3WIWaImM0fNVOGaLh3DUgcMn mkXpyJCQmVxcT/0g7F3+tuOuY+/loCe8nQD4gWXizBOO294v1bmPktBB xZ0=I think that the moment DS and RRSIG records are part of the result Node does not recognize it and thus fails to parse the rest.