Implementation considerations
History
Although dns.lookup() and the various dns.resolve*()/dns.reverse()
functions have the same goal of associating a network name with a network
address (or vice versa), their behavior is quite different. These differences
can have subtle but significant consequences on the behavior of Node.js
programs.
dns.lookup(): void
Under the hood, dns.lookup() uses the same operating system facilities
as most other programs. For instance, dns.lookup() will almost always
resolve a given name the same way as the ping command. On most POSIX-like
operating systems, the behavior of the dns.lookup() function can be
modified by changing settings in nsswitch.conf(5) and/or resolv.conf(5),
but changing these files will change the behavior of all other
programs running on the same operating system.
Though the call to dns.lookup() will be asynchronous from JavaScript's
perspective, it is implemented as a synchronous call to getaddrinfo(3) that runs
on libuv's threadpool. This can have surprising negative performance
implications for some applications, see the UV_THREADPOOL_SIZE
documentation for more information.
Various networking APIs will call dns.lookup() internally to resolve
host names. If that is an issue, consider resolving the host name to an address
using dns.resolve() and using the address instead of a host name. Also, some
networking APIs (such as socket.connect() and dgram.createSocket())
allow the default resolver, dns.lookup(), to be replaced.
These functions are implemented quite differently than dns.lookup(). They
do not use getaddrinfo(3) and they always perform a DNS query on the
network. This network communication is always done asynchronously and does not
use libuv's threadpool.
As a result, these functions cannot have the same negative impact on other
processing that happens on libuv's threadpool that dns.lookup() can have.
They do not use the same set of configuration files that dns.lookup()
uses. For instance, they do not use the configuration from /etc/hosts.