Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

doc: improve dns module's documentation #8747

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 78 additions & 10 deletions doc/api/dns.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -2,16 +2,32 @@

Stability: 3 - Stable

Use `require('dns')` to access this module. All methods in the dns module use
C-Ares except for `dns.lookup` which uses `getaddrinfo(3)` in a thread pool.
C-Ares is much faster than `getaddrinfo(3)` but, due to the way it is
configured by node, it doesn't use the same set of system configuration files.
For instance, _C- Ares will not use the configuration from `/etc/hosts`_. As a
result, __only `dns.lookup` should be expected to behave like other programs
running on the same system regarding name resolution.__ When a user does
`net.connect(80, 'google.com')` or `http.get({ host: 'google.com' })` the
`dns.lookup` method is used. Users who need to do a large number of lookups
quickly should use the methods that go through C-Ares.
Use `require('dns')` to access this module.

This module contains functions that belong to two different categories:

1) Functions that use the underlying operating system facilities to perform
name resolution, and that do not necessarily do any network communication.
This category contains only one function: `dns.lookup`. __Developers looking
to perform name resolution in the same way that other applications on the same
operating system behave should use `dns.lookup`.__

Here is an example that does a lookup of `www.google.com`.

var dns = require('dns');

dns.lookup('www.google.com', function onLookup(err, addresses, family) {
console.log('addresses:', addresses);
});

2) Functions that connect to an actual DNS server to perform name resolution,
and that _always_ use the network to perform DNS queries. This category
contains all functions in the `dns` module but `dns.lookup`. These functions
do not use the same set of configuration files than what `dns.lookup` uses.
For instance, _they do not use the configuration from `/etc/hosts`_. These
functions should be used by developers who do not want to use the underlying
operating system's facilities for name resolution, and instead want to
_always_ perform DNS queries.

Here is an example which resolves `'www.google.com'` then reverse
resolves the IP addresses which are returned.
Expand All @@ -34,6 +50,10 @@ resolves the IP addresses which are returned.
});
});

There are subtle consequences in choosing one or another, please consult the
[Implementation considerations section](#dns_implementation_considerations)
for more information.

## dns.lookup(domain, [family], callback)

Resolves a domain (e.g. `'google.com'`) into the first found A (IPv4) or
Expand All @@ -51,6 +71,13 @@ Keep in mind that `err.code` will be set to `'ENOENT'` not only when
the domain does not exist but also when the lookup fails in other ways
such as no available file descriptors.

`dns.lookup` doesn't necessarily have anything to do with the DNS protocol.
It's only an operating system facility that can associate name with addresses,
and vice versa.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just say it's a wrapper around getaddrinfo, there is no need to hide it :-)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saghul This information is present in the "Implementation considerations" section below, do you think it should be mentioned here instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I think it should be clear from the start that dns.lookup == getaddrinfo, IMHO it would simplify the docs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I knew there were two functions, one calling getaddrinfo in the thread pool, the other doing direct async dns via c-ares, and last time I used the dns module directly I had to spend a few minutes sifting through the documentation to figure out which of lookup() and resolve() was which... I kindof lament that the one that calls getaddrinfo isn't dns.getaddrinfo().

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saghul I agree with you, but my original concern was that by mentioning that dns.lookup == getaddrinfo in the introduction we would expose too much of the implementation's details to everyone right from the start. For instance, if we wanted to be precise for Windows users, we would need to mention GetAddrInfoW in addition to getaddrinfo (although they probably behave in a very similar way).

Instead, I thought that describing the general semantics and the concept of dns.lookup in the introduction would be sufficient, and would work for any implementation, even if these implementations change in the future. People interested in the implementation details could still consult the section that is reserved for that.

@sam-github The goal of this PR is exactly to address the problem you mentioned.


Its implementation can have subtle but important consequences on the behavior
of any Node.js program. Please take some time to consult the [Implementation
considerations section](#dns_implementation_considerations) before using it.

## dns.resolve(domain, [rrtype], callback)

Expand Down Expand Up @@ -149,3 +176,44 @@ Each DNS query can return one of the following error codes:
- `dns.ADDRGETNETWORKPARAMS`: Could not find GetNetworkParams function.
- `dns.CANCELLED`: DNS query cancelled.

## Implementation considerations

Although `dns.lookup` and `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

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,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe referring to the web browser's resolution would be more helpful than ping, given the audience?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github I don't know what our audience really is. I assume it's a mix of front-end and backend/system developers. I think adding an example that mentions the browser is a good idea, but I wouldn't remove an example that's targeted more to system/backend developers.

the behavior of the `dns.lookup` function can be tweaked by changing settings
in `nsswitch.conf(5)` and/or `resolv.conf(5)`, but be careful that changing
these files will change the behavior of all other programs running on the same
operating system.

Though the call will be asynchronous from JavaScript's perspective, it is
implemented as a synchronous call to `getaddrinfo(3)` that runs on libuv's
threadpool. Because libuv's threadpool has a fixed size, it means that if for
whatever reason the call to `getaddrinfo(3)` takes a long time, other
operations that could run on libuv's threadpool (such as filesystem
operations) will experience degraded performance. In order to mitigate this
issue, one potential solution is to increase the size of libuv's threadpool by
setting the 'UV_THREADPOOL_SIZE' environment variable to a value greater than
4 (its current default value). For more information on libuv's threadpool, see
[the official libuv
documentation](http://docs.libuv.org/en/latest/threadpool.html).

### dns.resolve, functions starting with dns.resolve and dns.reverse

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mention only upsides, and no downsides, which could/has lead to people asking, "why isn't dns.resolve the default lookup mechanism in node?".

getaddrinfo might be faster if the systems does local cacheing. getaddrinfo may be able to resolve addresses, like .local network addresses available only using mDNS, that can't be resolved at all using DNS. And I haven't tried this, but I suspect that dns.resolve also won't qualify names, so attempts to lookup names like 'mail' which might normally resolve to 'mail.yourcompany.com' will fail. These failures to sucessfully lookup names that can be found by every other application on the user's system can be a source of frustration. dns.resolve() is best reserved for bulk, parallel lookup of names known to be fully qualified and available via DNS, I think.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github Agreed, this section should be more detailed.


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 than what `dns.lookup`
uses. For instance, _they do not use the configuration from `/etc/hosts`_.