dns: Add DNSSEC support

[fvdm]

• Version: 8.2.1
• Platform: 64-bit (OSX 10.17, Ubuntu Server 17.04)
• Subsystem: dns.js

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:

• Basic support to simply allow RRSIG records in the result, instead it returns an EBADRESP error while the requested resource is perfectly valid.
• Basic support to request RRSIG records, i.e. a RRSIG rrtype for dns.resolve() and a new dns.resolveRrsig() method.
• DNSSEC verification, to confirm the returned answer is valid. Perhaps with a new method like 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 hostname on the shell. For example,

// DNSSEC signed, but works fine
dns.resolve ('myhostname.net', 'A', console.log);
[ '37.97.204.102' ]

is similar to:

$ dig myhostname.net a

;; ANSWER SECTION:
myhostname.net.		1382	IN	A	37.97.204.102

while requesting ANY rrtype returns an error:

// DNSSEC signed, does not work
dns.resolve ('myhostname.net', 'ANY', console.log);

{ Error: queryAny EBADRESP myhostname.net
    at errnoException (dns.js:50:10)
    at QueryReqWrap.onresolve [as oncomplete] (dns.js:236:19)
  code: 'EBADRESP',
  errno: 'EBADRESP',
  syscall: 'queryAny',
  hostname: 'myhostname.net' }

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.

[mscdex]

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.

[XadillaX]

I think we should open an Issue on c-ares first?

[bnoordhuis]

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.

[tniessen]

@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 😕

[bnoordhuis]

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:

1. dns.lookup() transparently supports DNSSEC if the system resolver does.
2. dns.resolve() and friends do not.

Closing, blocked on upstream support.

[fvdm]

What'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)

[bnoordhuis]

@fvdm Performance. The system resolver is usually fuller featured but it tends to fall over when you do 10,000 lookups in parallel.