Repository navigation
No DNS Search Domain support in C-Ares calls #17850
Description
- Version: node:9.2.0-slim (Docker image)
- Platform: Linux 8f48fe466727 4.9.49-moby 1 SMP Fri Dec 8 13:40:02 UTC 2017 x86_64 GNU/Linux
- Subsystem: dns
It would seem that currently, Node.js calls through the C-Ares DNS resolver (resolve4() and resolve6()) don't support search domains.
Is this a bug? If not, are there current or planned configuration options to specify them?
Should this issue be cross-posted to the C-Ares repository?
To make reproduction of this issue easier, I created a Docker-based repository that you can find here:
https://github.com/Mickael-van-der-Beek/node-dns-test
PS: Be careful to not use Alpine Linux as Docker based image due to muslc being used and not glibc. I will create a ticket about this in their repository later.
EDIT: Might be related to this issue that was supposedly fixed in the past: #9799
Activity
bnoordhuis commentedon Dec 25, 2017
This is about node.js not honoring the
domainorsearchattribute in/etc/resolv.conf? That's because we callares_query(), notares_search().ares_query()does not take search domains into account.ares_search()cannot be the default because it makes up tonum_search_domains + 1queries but we could add a{ search: true }option.Mickael-van-der-Beek commentedon Dec 25, 2017
@bnoordhuis I see, good to know. Thanks for the quick answer.
The situation we encountered at my company is that we use a VPN to connect to our Kubernetes cluster. Services can have multiple instances and use DNS hostnames to load balance to one or the other (through KubeDNS). We also put these hostnames behind subdomains of one of our domains so that even development services benefit of our TLS certificate.
Since the hostnames are a bit long outside of the Kubernetes internal network, we let the VPN access the Kuberenetes DNS resolver to allow for short-hand service hostnames usage on our development machines.
@bcorijn Correct me if I'm wrong?
Not the most common use case of course, more of a convenience thing. So I understand if this isn't a priority.
It did take us a bit of time to understand why certain apps were affected or not because some DNS resolutions used
dns.lookup()which worked fine in this case and others were usingdns.resolve()which didn't.Manicqin commentedon Mar 4, 2018
Hi, If this issue is still open I can take it.
bnoordhuis commentedon Mar 4, 2018
@Manicqin You mean adding a
searchoption? Go for it; no one is working on it, AFAIK.Add Support for resolving DNS using search list for host-name loopkup.
UtkarshGupta-CS commentedon Jun 10, 2018
@Manicqin will you be able to resolve this issue or can I take up this issue?
UtkarshGupta-CS commentedon Jun 11, 2018
@bnoordhuis Can I work on this issue?
bnoordhuis commentedon Jun 11, 2018
Sure. The other pull request looks to have stalled.
SirR4T commentedon Aug 10, 2018
@bnoordhuis took a shot in #22226 , based on your review suggestions in #19548 . complete noob at C++, though, so might require a bit of handholding. Also, need guidance in writing tests.
fhinkel commentedon Oct 30, 2019
Should this remain open?
github-actions commentedon Mar 4, 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 Apr 4, 2022
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.