Tracking Issue: DNS features requiring c-ares support

[tniessen]

There is a growing list of feature requests for the DNS module which require upstream changes for an efficient implementation within node.

• [ ] https://github.com/nodejs/node/issues/14648: c-ares does not support multiple response messages for a single question, making AXFR queries impossible to implement within node.
• [ ] https://github.com/nodejs/node/issues/14475: c-ares does not support DNSSEC, making it difficult to implement DNSSEC within node.
• [ ] https://github.com/nodejs/help/issues/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.
• [ ] https://github.com/nodejs/node/issues/19239: c-ares does not support CAA RRs.
• [ ] It is impossible to implement iterative DNS when using the dns module.
• [ ] 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 A and AAAA rrtypes.
• [ ] https://github.com/nodejs/node/issues/27724 support ANAME questions.

FYI @bagder @daviddrysdale

cc @addaleax @refack @silverwind @alexte

[alexte]

IMHO a native implementation of DNS without c-ares would be more future proof.

[silverwind]

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]

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]

Just as a question: what DNS resolvers do browsers use?

[fvdm]

@TimothyGu Usually the one of the network router which most likely forwards the requests to the caching resolvers of the ISP.

[silverwind]

Browsers use getaddrinfo which is implemented in the OS core libraries like glibc, which is also what dns.lookup uses. The issue with getaddrinfo is 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]

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

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

I think there are two different topics:

1. Resolving names to numbers, a function most applications need.
2. In depth DNS queries with full tweekability and full DNS response parsing, only needed for few applications.

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]

This is coming up on two years of inactivity. @tniessen Anything new to add here? I'm guessing not.

[ad-m]

We can consider https://github.com/getdnsapi/getdns/blob/develop/README.md as alternative, maintained, DNSSEC-capable, TTL-capable library: https://github.com/getdnsapi/getdns/blob/develop/README.md

[addaleax]

@ad-m I think that would require quite a bit of porting work, but if somebody’s up for that, why not.

[devsnek]

Interestingly getdns has first-class support for libuv :eyes:

[ad-m]

@devsnek, there's NodeJS binding too 👀 https://github.com/getdnsapi/getdns-node

[devsnek]

I've started looking into using getdns in core.

[renanbastos93]

NodeJS currently use c-ares to resolve queries DNS but is not so good it because it doesn't support all queries types. Even so, I thought we replacing it to another approach I have two ideas:

1 - We use the module miekg/dns in Golang Ask: Can we import the module of Golang on NodeJS core?

2 - We find another package with this support to all queries types.

Another problem we have those third-party libs to DNS in NodeJS is bad.

Refer issue https://github.com/nodejs/node/issues/33299

[devsnek]

@renanbastos93 that would require us adding a dependency on golang's compiler, and it also seems that library doesn't have a stable c api.

[renanbastos93]

that would require us adding a dependency on golang's compiler, and it also seems that library doesn't have a stable c api.

it's okay, thanks for explaining to me. Another approach we can implement these features to make a fork origin c-ares.

[devsnek]

@nodejs/node-gyp @nodejs/gyp could i get some assistance with porting getdns's cmake config to gyp? I have stripped out a bunch of the unneeded config (tests and libev support and such): https://gist.github.com/devsnek/04666f858ae6c3ebbc43c04edd1c6a38. I'm not sure what to do with those configure_file parts.

[bnoordhuis]

@devsnek One solution: generate them for different targets, then check them in and tweak include_dirs based on OS and/or target_arch. That's how we vendor c-ares and openssl.

[marsonya]

This is coming up on one year of inactivity and open for more than 3 years. @tniessen, any update on this issue?

[github-actions[bot]]

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.

[devsnek]

do not close pls

[github-actions[bot]]

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.