Your server needs a DNS resolver to look up domain names — for outgoing connections, package updates, sending mail and so on. This is a different thing from the nameservers that serve your domains to the world.
Recommended resolvers
We recommend configuring resolvers from two different operators rather than two addresses belonging to one. If one operator has an outage, the second continues to answer.
| Operator | IPv4 | IPv6 |
|---|---|---|
| Cloudflare | 1.1.1.1, 1.0.0.1 |
2606:4700:4700::1111, 2606:4700:4700::1001 |
8.8.8.8, 8.8.4.4 |
2001:4860:4860::8888, 2001:4860:4860::8844 |
|
| Quad9 | 9.9.9.9, 149.112.112.112 |
2620:fe::fe, 2620:fe::9 |
A sensible pairing is one address from each of two operators — for example 1.1.1.1 and 8.8.8.8. Quad9 additionally filters domains known to distribute malware, which some administrators prefer and others find gets in the way; it is a matter of preference rather than of correctness.
What choosing a resolver does and does not do
It affects how quickly and reliably your server resolves names, and nothing else. In particular, the resolver your server uses has no bearing on how your own sites are reached by visitors, and it does not protect the server against attacks — those are separate matters, covered in How to point a domain to your server and Is DDoS protection available for servers?
Where resolvers are configured
The setting is part of your server's network configuration:
- Ubuntu — the
nameserverssection of the netplan file in/etc/netplan/; - Debian —
dns-nameserversin/etc/network/interfaces, or/etc/resolv.confdepending on the configuration; - RHEL-based systems —
nmcli connection modify "connection" ipv4.dns "1.1.1.1 8.8.8.8"; - Windows Server — the adapter's IPv4 and IPv6 properties.
See Network configuration instructions for the details of each.
Note that editing /etc/resolv.conf directly is often futile: on most current systems the file is regenerated automatically, and your change disappears at the next restart. Set the resolvers where the network configuration is defined instead.
Checking that it works
dig example.com resolvectl status
The first confirms that resolution works; the second, on systems using systemd-resolved, shows which resolvers are actually in use — which is not always the ones you think you configured.
A note on privacy
Public resolvers see every domain your server looks up. For most servers this is unremarkable, but if that matters for your project, the alternative is to run your own recursive resolver on the server, which resolves names directly rather than through a third party. Open a ticket if you would like to discuss that.