Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

socket.connect does not use specified localAddress for DNS lookup #14617

Closed
isaaczinda opened this issue Aug 4, 2017 · 3 comments
Closed

socket.connect does not use specified localAddress for DNS lookup #14617

isaaczinda opened this issue Aug 4, 2017 · 3 comments
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. dns Issues and PRs related to the dns subsystem. net Issues and PRs related to the net subsystem.

Comments

@isaaczinda
Copy link

Version: 8.2.1
Platform: Windows 10, x64
Subsystem: DNS / Net

I am establishing a TCP connection to a remote server over a cellular modem. However, I have not made the cellular modem the primary network adapter. I have made the modem's interface metric very high, so that by default sockets still open over WiFi. Because of this configuration, I have to specify the modem's IP if I want to connect using it.

However, when I run this code, the DNS lookup fails. For repro: my primary network adapter is a wireless network card, and I am connected to a local network that does not have internet access. I am connected over ethernet (second priority). I am connected to a USB cellular modem (lowest priority)

var net = require('net');

var sock = net.Socket();
const options = {
    localAddress: "192.168.10.2", // address of a cellular modem
    host: "google.com",
    port: 5000
};

sock.connect(options);

sock.on('lookup', function(err, address, family, host) {
    console.log(address);
    // address variable has '10.0.0.1', not the actual address of the server
});

I was able to get to the bottom of this problem. The DNS lookup fails because dns.lookup() (used by default) does not use the network adapter that the socket tries to connect over. As I understand it, dns.lookup() uses a system tool that uses the primary network adapter. I don't think this is desirable behavior, but am not sure what to do about it. If a function exists in core that allows users to do DNS lookup over a specific network adapter, this should become the new default for sockets. If this function does not exist, I would like to see it added.

@mscdex mscdex added dns Issues and PRs related to the dns subsystem. dgram Issues and PRs related to the dgram subsystem / UDP. net Issues and PRs related to the net subsystem. labels Aug 4, 2017
@bnoordhuis
Copy link
Member

Just so we're on the same page, the .localAddress option uses the address as-is, it doesn't do DNS resolution. I infer that isn't what you meant but I mention it in case I inferred wrong.

As I understand it, dns.lookup() uses a system tool that uses the primary network adapter.

Not quite. dns.lookup() uses a system tool, period.

It sounds like the system resolver is configured incorrectly. That is not a node.js issue; you would have the same problem in another language or runtime.

@bnoordhuis
Copy link
Member

No follow-up so I'll assume this is working for you. Closing.

@kodmanyagha
Copy link

Just so we're on the same page, the .localAddress option uses the address as-is, it doesn't do DNS resolution. I infer that isn't what you meant but I mention it in case I inferred wrong.

As I understand it, dns.lookup() uses a system tool that uses the primary network adapter.

Not quite. dns.lookup() uses a system tool, period.

It sounds like the system resolver is configured incorrectly. That is not a node.js issue; you would have the same problem in another language or runtime.

how can I configure system resolver correctly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. dns Issues and PRs related to the dns subsystem. net Issues and PRs related to the net subsystem.
Projects
None yet
Development

No branches or pull requests

4 participants