Repository navigation
Tracking Issue: DNS features requiring c-ares support #14713
Description
There is a growing list of feature requests for the DNS module which require upstream changes for an efficient implementation within node.
- dns: support AXFR queries #14648: c-ares does not support multiple response messages for a single question, making AXFR queries impossible to implement within node.
- dns: Add DNSSEC support #14475: c-ares does not support DNSSEC, making it difficult to implement DNSSEC within node.
- DNS: query for for authority section or additional section help#634: c-ares does not appear to support parsing the additional and authority sections of DNS messages, at least not directly. An upstream API would be helpful at this point, even though it is possible to implement this within node.
- Add support for resolving CAA records #19239: c-ares does not support CAA RRs.
- It is impossible to implement iterative DNS when using the
dnsmodule. - c-ares appears to restrict the number of concurrent queries per resolver by using a single port per channel
- c-ares does not expose TTL values except for
AandAAAArrtypes. - Feat: resolver DNS accept qType ALIAS/ ANAME #27724 support
ANAMEquestions.
Activity
alexte commentedon Aug 10, 2017
IMHO a native implementation of DNS without c-ares would be more future proof.
silverwind commentedon Aug 11, 2017
It was attempted to write a JS resolver in the past, but performance wasn't up to par back then. Anyone aware of other libraries we could consider?
tniessen commentedon Aug 11, 2017
I considered writing a small DNS library tailored for Node.js as c-ares comes with some downsides and I did not find any alternatives. Our main concerns are portability (c-ares has a lot of code just to support Windows 95), performance (we should not allow significant regression) and dependability (c-ares has been tested for years). I could try to put something together, but it will take some time and we would need to test it extensively before shipping it in release lines.
TimothyGu commentedon Aug 11, 2017
Just as a question: what DNS resolvers do browsers use?
fvdm commentedon Aug 11, 2017
@TimothyGu Usually the one of the network router which most likely forwards the requests to the caching resolvers of the ISP.
silverwind commentedon Aug 11, 2017
Browsers use
getaddrinfowhich is implemented in the OS core libraries like glibc, which is also whatdns.lookupuses. The issue withgetaddrinfois that it's only purpose is name to IP resolution, and for more advanced DNS use cases (record types other than A and AAAA, or if you'd like to avoid caching) you need a actual resolver capable of constructing and parsing DNS packets.tniessen commentedon Aug 11, 2017
@fvdm I believe you are referring to DNS servers (routers usually act as DNS servers in local networks), this is not what this issue is about.
fvdm commentedon Aug 13, 2017
@tniessen I misinterpreted resolvers in the question as the part of DNS that provides the requested answers, instead of the client software that performs the requests. My apologies.
alexte commentedon Aug 14, 2017
I think there are two different topics:
For 1) I would see this in the core and as standard as possible, perhaps even using libc getaddr* functions, and optimized for speed.
2) a separate library (NPM) with full control, implemented natively, that implements all DNS protocol features, even DNSSEC etc
Trott commentedon Aug 11, 2019
This is coming up on two years of inactivity. @tniessen Anything new to add here? I'm guessing not.
16 remaining items
devsnek commentedon Mar 22, 2022
do not close pls
github-actions commentedon Sep 21, 2022
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
github-actions commentedon Mar 21, 2023
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
bnoordhuis commentedon Mar 21, 2023
@tniessen this issue has been open for 5.5 years now and, realistically, I don't expect any of the items to happen. I don't think it's a huge problem either; the dns module doesn't have to be everything for everyone, there are third-party modules that fill the gap.
I suggest we close this. Aye/nay?
renanbastos93 commentedon Mar 21, 2023
based on the time we waiting for that, let's close it. I believe that if case a problem we open again.
bradh352 commentedon Oct 25, 2023
FYI, I think c-ares will support a majority of what you need in the near future. The goal is to expose the new parser publicly probably after this upcoming release. New parser / record API is defined here:
https://github.com/c-ares/c-ares/blob/main/src/lib/ares_dns_record.h