Node.js dns.resolve () vs dns.lookup ()

Question

I need to find this node in the corresponding IP address in Node.js. There seem to be two own methods:

> dns.resolve('google.com', (error, addresses) => { console.error(error); console.log(addresses); }); QueryReqWrap { bindingName: 'queryA', callback: { [Function: asyncCallback] immediately: true }, hostname: 'google.com', oncomplete: [Function: onresolve], domain: Domain { domain: null, _events: { error: [Function] }, _eventsCount: 1, _maxListeners: undefined, members: [] } } > null [ '216.58.194.174' ] 

and

 > dns.lookup('google.com', (error, address, family) => { console.error(error); console.log(address); console.log(family); }); GetAddrInfoReqWrap { callback: { [Function: asyncCallback] immediately: true }, family: 0, hostname: 'google.com', oncomplete: [Function: onlookup], domain: Domain { domain: null, _events: { error: [Function] }, _eventsCount: 1, _maxListeners: undefined, members: [] } } > null 216.58.194.174 4 

Both return the same IPv4 address. What is the difference between dns.lookup() and dns.resolve() ? Also, which is more efficient for multiple queries per second?

Answer 1

The dns documentation already describes the difference:

Although dns.lookup () and the various functions dns.resolve * () / dns.reverse () have the same goal - to associate a network name with a network address (or vice versa), their behavior is completely different. These differences can have minor but significant consequences for the behavior of Node.js.

<ns> dns.lookup ()
Under the hood, dns.lookup () uses the same operating system features as most other programs. For example, dns.lookup () will almost always resolve the given name in the same way as the ping command. On most POSIX-like operating systems, the behavior of the dns.lookup () function can be changed by changing the settings in nsswitch.conf (5) and / or resolv.conf (5), but note that changing these files will change the behavior of all other programs running on the same operating system.

Although the dns.lookup () call will be asynchronous in terms of JavaScript, it is implemented as a synchronous call to getaddrinfo (3), which is executed on libuv threadpool. Since libuv threadpool has a fixed size, this means that if for some reason the getaddrinfo (3) call takes a long time, other operations that can be performed on libuv threadpool (for example, file system operations) will have degraded performance. To mitigate this problem, one possible solution is to increase the size of libuv threadpool by setting the environment variable UV_THREADPOOL_SIZE to a value greater than 4 (the current default value). For more information about libuv threadpool, see the libuv Official Documentation.

dns.resolve (), dns.resolve * () and dns.reverse ()
These functions are implemented very differently than dns.lookup (). They do not use getaddrinfo (3), and they always perform a DNS query on the network. This network connection is always asynchronous and does not use libuv threadpool.

As a result, these functions cannot have the same negative effect on other processing that occurs on libuv threadpool, which dns.lookup () may have.

They do not use the same set of configuration files than dns.lookup () uses. For example, they do not use the configuration from / etc / hosts.

As for concurrency, you are better off using dns.resolve*() because these requests do not fall into the thread pool, while dns.lookup() requests are executed because they invoke the DNS DNS solution, which usually blocks (although now there are some asynchronous interfaces, but they are not always implemented everywhere).

Currently, node internally uses dns.lookup() for any automatic DNS resolution, for example, when you pass the host name http.request() .