This issue just serves as heads up and a tracking issue. I have kicked off a refactoring the dns subsystem within core. The current implementation is aging, inefficient, and rather inflexible. As part of the effort to implement QUIC and HTTP/3, and in order to better address seamless interop between HTTP's 1, 2 and 3, support for a couple of new DNS record types is ideal (specifically, the SVCB and HTTPS record types defined in https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/04/). There have also historically been a number of performance issues with the DNS implementation that would be good to finally get addressed.
This issue just serves as heads up and a tracking issue. I have kicked off a refactoring the dns subsystem within core. The current implementation is aging, inefficient, and rather inflexible. As part of the effort to implement QUIC and HTTP/3, and in order to better address seamless interop between HTTP's 1, 2 and 3, support for a couple of new DNS record types is ideal (specifically, the SVCB and HTTPS record types defined in https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/04/). There have also historically been a number of performance issues with the DNS implementation that would be good to finally get addressed.
I've started the clean up in a new PR here: https://github.com/nodejs/node/pull/38172
This PR modernizes the organization of the cares_wrap code, eliminates some duplicated code, and should make it easier to maintain.
The next step will be to start tackling some of the inefficient code patterns in the C++ code. These changes should be non-breaking.
Following that, I will look at introducing support for new record types. Those changes should be semver-minor.
Lastly, I will look at making additional performance and architectural changes that will likely be semver-major.