Repository navigation
Feature. Set DNS server port for DNS client #7903
Description
Activity
We could add support for port numbers.
dns.setServers()is currently glue forares_set_servers(), which ignores port numbers, but that could be changed toares_set_servers_ports(), which respects them.Can you explain your use case though? I've never seen a DNS server on a non-standard port, not even in testing setups.
It's mainly for an e2e test suite to be run on a production server that already is serving DNS. I didn't want to have to spin up another server or shutdown the existing DNS server. Maybe to reduce impact, we could keep the existing behavior and have an options flag to use the ares_set_server_ports() function?
I've added the 'feature request' label.
Pull requests welcome but I won't vouch they'll get accepted. It seems like a rather esoteric feature when you can't even configure /etc/resolv.conf to use a non-standard port.
System resolvers rarely allow non-standard ports - rightfully so - but application resolvers often do allow them for various reasons.
I wouldn't consider Node.js to be a system level resolver and thus supporting non-standard ports might not be so "esoteric feature".
In addition to network domains, DNS can be used for other purposes. For example as a P2P service discovery protocol, where use of custom ports is desired. In this case, port is not used to differentiate the technical protocol, but the type of content served.
Right now, Node.js can not be used to implement clients for these kinds of service discovery implementations; or at least not by using it's built-in resolver.
Not against it, but also not really thrilled about a likely required sync-style method like
dns.setPort(if we wanna keep the API consistent withsetServers), for cases where you want to use the system's servers on an alternative port.I'd generally recommend dns-socket which can do pretty much everything tools like
digcan do.To be honest, the entire DNS module is a bit ripe for refactoring. There are challenges with
setServers()when it's called at the wrong time and the APIs are a bit messy in general. I'm not against making this change, but perhaps we should give some thought to more extensive changes?Yeah,
dnsis lacking both feature-wise and API-wise. Adding more API surface now is not going to make a future transition easier, so I think that should be kept in mind.I remember seeing some discussion / PRs for transitioning to pure JS DNS resolver.
What is the status of that?
@mscdex Just curious, what type of performance degradation? DNS isn't exactly a high frequency, high bandwidth protocol by it's nature.
I'd expect native c-ares to offer better latency and more queries per second, but does minor performance degradation even matter for a any real world DNS usage scenario?
6 remaining items
I've never seen a DNS server on a non-standard port, not even in testing setups.
https://www.consul.io/docs/agent/dns.html
by default, consul runs their DNS service on udp/8600.Reacted by Sharif Nassar, Ryan Goltry, Colin Curtin, Richard Fung, Julien Lecomte and Engineer+1 for custom port
I run two different DNS resolvers on my production box. One of them runs with normal settings and is for the system and generic apps, the other is for an app that requires custom settings and very short cache retention.
For now I'm going to use
dns-socketnative-dns to resolve this, but I believe the dns module should support custom ports.Edit: switched to native-dns as I can't get dns-socket to work somehow.
I also want to run the dnsmasq service locally on a non-standard port, and then query against it with my nodejs app (since my node app runs on port 53).. I want to leverage the dnsmasq caching etc..
- added a commit that references this issue
on Jun 16, 2017 - added a commit that references this issue
on Jun 29, 2017 - added a commit that references this issue
on Jul 11, 2017 - added a commit that references this issue
on Jul 18, 2017
the Docs on the DNS client say that the dns.setServers(servers) method will strip out any custom ports provided. "If a port specified on the address it will be removed."
I'm curious if there is a specific reason for not wanting to support it, or is it planned to be supported?