Feature. Set DNS server port for DNS client

[amit777]

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?

[bnoordhuis]

We could add support for port numbers. dns.setServers() is currently glue for ares_set_servers(), which ignores port numbers, but that could be changed to ares_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.

[amit777]

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?

[bnoordhuis]

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.

[imyller]

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.

[silverwind]

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 with setServers), 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 dig can do.

[jasnell]

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?

[silverwind]

Yeah, dns is 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.

[imyller]

I remember seeing some discussion / PRs for transitioning to pure JS DNS resolver.

What is the status of that?

[jasnell]

@mscdex can comment more specifically but it stalled out due to an inability to get the necessary performance.

[mscdex]

@jasnell Yep.

[imyller]

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