How to configure DNS: Windows, router, Android and server

In short. "Configure DNS" means two different jobs. The first is changing the DNS server (resolver) your device uses to turn names into IP addresses — done in the network settings of Windows, macOS, Android, or once on the router. The second is publishing DNS records for your own domain (A, CNAME, MX, NS) in the panel that hosts the zone. The instructions do not overlap, so start by deciding which one you need.

Below: both jobs step by step, commands for every operating system, how to set domain records without breaking mail, and a dedicated section for "I changed it and nothing happened".

Start here: which job is yours

The same phrase brings in readers with opposite problems. Check the table before you change anything.

Job	Sign this is your case	Where it is changed	What to read below
Change the resolver on your device	Sites load slowly or not at all, your ISP replaces error pages, you want ad filtering or encrypted queries	OS network settings, or once on the router	Sections on Windows, macOS and Android, router, browser
Configure records for your domain	You bought a domain and are connecting hosting, mail, or verifying ownership in a webmaster console	The zone control panel: at the registrar, the host, or a separate DNS provider	Section on A, CNAME, MX and NS records
Run your own DNS server	Your own infrastructure, internal names, an Active Directory domain, a caching resolver on the LAN	On the server: BIND, unbound, the DNS role in Windows Server	Section on running your own DNS server

The costliest mistake here is fixing the wrong job. If your own site will not open for visitors, changing DNS servers on your laptop is pointless — visitors use their own resolvers. The reverse is also true: if other people's sites will not load for you, editing your domain records changes nothing.

How to configure DNS on Windows 10 and Windows 11

In Windows, DNS servers are set per network adapter: Wi-Fi and Ethernet are configured separately. If you typed the addresses into the Wi-Fi adapter while the machine is on a cable, nothing changes. That is the single most common reason behind "I set it and it does not work".

Through Settings — Windows 11 and recent Windows 10 builds

The path: Settings → Network & Internet → Wi-Fi (or Ethernet) → properties of the active connection → the DNS server assignment entry → switch from Automatic (DHCP) to Manual → enable IPv4 → enter the preferred and alternate addresses. Labels shift between builds, so follow the logic rather than the exact wording: pick the adapter first, then switch DNS assignment to manual.

Windows 11 exposes DNS encryption in the same dialog. If the resolver supports DNS over HTTPS and the system recognises it, encryption is enabled right there, without third-party software.

Through Control Panel — works on every version

Press Win+R, type ncpa.cpl and hit Enter. Then: right-click the adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) → Properties → "Use the following DNS server addresses". This path is identical on Windows 10 and 11 and survives whatever the Settings app renames next.

If IPv6 is enabled on the adapter but its DNS entries are still automatic, the system may keep asking your ISP's resolver over IPv6 — and your new addresses will not always be used. Either set DNS for IPv6 as well, or uncheck the protocol if you do not need it.

Through the command line and PowerShell — faster and repeatable

Both sets of commands need a console running as administrator. Substitute your own adapter name — the first command prints it.

:: list network adapter names
netsh interface show interface

:: set primary and secondary DNS for the "Ethernet" adapter
netsh interface ip set dns name="Ethernet" static 1.1.1.1 primary
netsh interface ip add dns name="Ethernet" 1.0.0.1 index=2

:: go back to receiving addresses from DHCP
netsh interface ip set dns name="Ethernet" dhcp

# PowerShell: which DNS servers are in use on every interface
Get-DnsClientServerAddress -AddressFamily IPv4

# set the DNS list for one interface
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

# reset to defaults (receive from DHCP again)
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

# clear the DNS client cache
Clear-DnsClientCache

You can verify without leaving the console: ipconfig /all prints a "DNS Servers" line per adapter, and Get-DnsClientServerAddress returns the same list in machine-readable form. If the old addresses are still there, you configured a different adapter.

How to configure DNS on macOS, Linux, Android and iPhone

macOS

In the interface: System Settings → Network → select the active service (Wi-Fi or Ethernet) → Details → DNS tab → add addresses with the plus button. The terminal is faster and less ambiguous:

# list network services (you need the names for the next commands)
networksetup -listallnetworkservices

# set DNS for the "Wi-Fi" service
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1

# check what was written
networksetup -getdnsservers "Wi-Fi"

# restore automatic assignment from DHCP
sudo networksetup -setdnsservers "Wi-Fi" Empty

# which resolvers the system actually uses
scutil --dns | head -20

Linux

On modern distributions /etc/resolv.conf is generated automatically, so editing it by hand is pointless. Configure whichever service manages it — usually NetworkManager or systemd-resolved.

# systemd-resolved: see the servers used per interface
resolvectl status

# NetworkManager: list connection profiles
nmcli connection show

# set DNS on a profile and stop it taking addresses from DHCP
sudo nmcli connection modify "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes

# apply: bring the connection back up
sudo nmcli connection up "Wired connection 1"

If /etc/resolv.conf is a symlink to a systemd-resolved file, your hand edits survive until the next DHCP lease renewal or reboot at best. Checking takes one command: ls -l /etc/resolv.conf. If it is a symlink, configure through nmcli or resolvectl instead.

Android

Android has two separate mechanisms and they are constantly confused.

Private DNS is a system-wide setting that applies to both Wi-Fi and mobile data. The path: Settings → Network & Internet → Private DNS (vendor skins may bury it under Advanced or Connections). The important detail: this field takes a provider hostname, not an IP address, because the mechanism runs over DNS over TLS. For example dns.google for Google Public DNS or one.one.one.one for Cloudflare. An IP address will be rejected — that is expected behaviour, not a bug.

Static addresses for one Wi-Fi network are set while editing that network: switch the IP type from DHCP to Static, and DNS 1 and DNS 2 fields appear. This applies only to that network and requires entering the device IP by hand — get the address or prefix wrong and you lose connectivity entirely.

iPhone and iPad

The path: Settings → Wi-Fi → the "i" icon next to the network → Configure DNS → Manual → remove the received addresses and add your own. The setting is bound to that specific Wi-Fi network and has to be repeated elsewhere. On mobile data the resolver cannot be changed by built-in means — the carrier's servers are used unless a configuration profile or an encrypted-DNS app is installed.

If you want a deeper walkthrough focused purely on switching resolvers, there is a separate guide on how to change your DNS server.

How to configure DNS on a router — one change for every device

This is the best return on effort: phones, TV, console and guests all pick up the new resolver automatically. Router web interfaces have two different places for this, and the difference matters.

• DNS on the WAN side — the servers the router itself uses. It affects the router's own lookups and, on some firmware, what it hands to clients.
• DNS on the LAN/DHCP side — the addresses the router distributes to devices as a DHCP option. This is the field that decides which resolver your laptops and phones actually see.

Many firmware builds hand clients the router's own LAN address rather than a public one: the router acts as a local DNS proxy and queries upstream itself. In that case your adapter properties show something like 192.168.1.1 — that is normal behaviour, not a misconfiguration.

Devices do not pick up a router-side change instantly — they get it when the DHCP lease renews. To avoid waiting, reconnect Wi-Fi on the device or reboot the router. Some hardware — TVs, streaming sticks, certain smart speakers — ignores the assigned servers and talks to a resolver hardcoded in firmware; at the router level that can only be handled by redirecting port 53 traffic, if the firmware supports such rules.

How to configure DNS in a browser: DoH and why system settings stop working

Modern browsers can bypass the operating system entirely and resolve names over DNS over HTTPS, defined in RFC 8484. Queries travel encrypted to the chosen resolver and look like ordinary HTTPS traffic to the network.

In Chrome and Chromium-based browsers the setting sits in the security section as "Use secure DNS": keep your current provider's resolver or pick another from the list. Firefox calls it "DNS over HTTPS" in privacy settings, with a provider choice and a protection mode.

Here is the practical consequence that derails half of all troubleshooting: if DoH is on in the browser, your system-level DNS change does not apply to it. Running nslookup in a console returns one answer while the browser opens a different site, because the two are asking different servers. Account for that when verifying: either turn DoH off first, or verify with system tools and treat the browser as a separate case.

The second consequence is about privacy. DoH hides your lookups from the network operator, but not from the resolver itself — whoever runs it still sees every domain you ask for. Encryption changes who you trust, not whether you trust someone.

Which DNS server to choose: public resolvers

Always enter two addresses: if the first is unreachable, the system falls back to the second. Mixing two different operators in one pair is a popular idea with a hidden cost — when the primary fails you silently move to a resolver with a different filtering policy. For predictable behaviour, use the primary and secondary pair of the same operator.

Resolver	IPv4	IPv6	Notes
Cloudflare	1.1.1.1, 1.0.0.1	2606:4700:4700::1111, 2606:4700:4700::1001	Filtering variants exist: 1.1.1.2 blocks malware domains, 1.1.1.3 also blocks adult content
Google Public DNS	8.8.8.8, 8.8.4.4	2001:4860:4860::8888, 2001:4860:4860::8844	No content filtering; the most recognisable addresses, often used as a reference during diagnosis
Quad9	9.9.9.9, 149.112.112.112	2620:fe::fe, 2620:fe::9	Blocks domains from threat feeds; a separate address, 9.9.9.10, serves the unfiltered variant
AdGuard DNS	94.140.14.14, 94.140.15.15	available, see the operator's documentation	Drops ad and tracker domains at the DNS level — noticeable on devices that cannot run a blocker
OpenDNS	208.67.222.222, 208.67.220.220	available, see the operator's documentation	Historically focused on category filtering and parental controls

Resolver speed depends on how close its nearest point of presence is to you, and that is individual: one operator wins on your network and loses on the next one. There is no universally fastest address, so measure it yourself. A comparison with selection criteria lives in the guide to the best public DNS servers.

Changing your resolver does not make your connection faster. It only shortens name-to-address lookups — typically tens of milliseconds on the first request to each new domain. The effect is noticeable when your ISP's resolver is overloaded, far away, or rewrites answers for non-existent domains into an ad page. Do not expect video to load faster.

How to configure domain DNS records: A, CNAME, MX and NS

This is the second job — the one for domain owners. Records are edited in the zone control panel, and the first question is always the same: whose panel is it. The zone is served by whoever is listed in the domain's NS records. If NS points at your host while you are editing records at the registrar, your changes never reach the world.

Type	What it sets	Example value	What to watch
A	Name to IPv4 address	203.0.113.10	The main site record; the domain root is usually written as @ in the name field
AAAA	Name to IPv6 address	2001:db8::10	Add it only if the server truly answers over IPv6, otherwise some clients wait for a timeout
CNAME	Name to another name	site.example.net.	Not allowed at the domain root, and cannot coexist with other records of the same name
MX	Mail servers for the domain	10 mx1.example.com.	The value is a hostname, never an IP, and that name must not be a CNAME. The number is priority: lower wins
TXT	Arbitrary text	"v=spf1 include:_spf.example.com ~all"	SPF, DKIM, DMARC and domain ownership verification
NS	Zone delegation	ns1.example-dns.net.	Changed at the registrar; decides which panel controls the domain at all
SOA	Zone parameters	serial, refresh, retry, expire, minimum	The minimum field sets the TTL of negative answers — see RFC 2308
SRV	Service host and port	0 5 5060 sip.example.com.	Telephony, messaging, Active Directory service records
CAA	Who may issue certificates	0 issue "letsencrypt.org"	A mistake here breaks automated certificate issuance
PTR	Address to name (reverse zone)	set by the network owner	Configured at your host or ISP, not in your zone; matters for mail delivery

A minimal record set for a site with mail looks like this when the panel shows the zone as text:

; site: domain root and www
@       300  IN  A      203.0.113.10
www     300  IN  CNAME  example.com.

; mail: priority 10 is primary, 20 is the backup
@       3600 IN  MX     10 mx1.example.com.
@       3600 IN  MX     20 mx2.example.com.

; sender policy and reporting
@       3600 IN  TXT    "v=spf1 include:_spf.example.com ~all"
_dmarc  3600 IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

; who may issue certificates for the domain
@       3600 IN  CAA    0 issue "letsencrypt.org"

Four rules people trip over most often:

• The trailing dot. In zone text, mx1.example.com. with the dot is a fully qualified name, while mx1.example.com without it gets expanded to mx1.example.com.example.com. Web panels usually add the dot for you, but when editing a zone file by hand it is mandatory.
• CNAME at the domain root is forbidden. The root already carries SOA and NS records, and CNAME tolerates no neighbours. If a service asks for a CNAME on the root, look for ALIAS, ANAME or "CNAME flattening" in the panel — those return the result as an A record.
• MX points to a name, not an IP. And that name must resolve through an A or AAAA record rather than an alias. Receiving mail servers are entitled to reject anything else.
• Lower the TTL in advance. A day before a migration set the TTL to 300 seconds, switch the records, confirm everything works, then restore the usual value. Changing the TTL at migration time achieves nothing: the world is still running on the previously cached value.

A breakdown of every record type with examples lives in the separate guide to DNS records. Mail-related records are quickest to verify with the MX lookup and the SPF, DKIM and DMARC audit.

Before editing anything, find out where the domain is delegated. Check the NS records and registrar data through WHOIS. If they point at your hosting provider while you are editing the zone at the registrar, you are editing a copy nobody queries.

How to set up your own DNS server

The phrase "set up a DNS server" hides three unrelated tasks. Identify yours, or you will follow the wrong manual.

Authoritative server for a zone — BIND

You need this when you want to answer for the domain yourself instead of using a provider's panel. A minimal zone looks like this:

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
        2026081501  ; serial: increment on every edit
        7200        ; refresh
        3600        ; retry
        1209600     ; expire
        300 )       ; minimum: TTL for negative answers

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
ns1     IN  A       203.0.113.53
ns2     IN  A       198.51.100.53
@       IN  A       203.0.113.10
www     IN  CNAME   example.com.

# validate the config and the zone file before restarting anything
named-checkconf
named-checkzone example.com /etc/bind/db.example.com

# apply the changes
sudo rndc reload example.com

# confirm the server answers for itself
dig @127.0.0.1 example.com SOA +short

The operational rule that matters most: the SOA serial must increase on every edit. A serial that did not grow means secondary servers will not pull the update and will keep serving stale data — while you hunt for the problem everywhere except that one number.

A production setup needs at least two servers on different networks: a single-server zone lives exactly until its first reboot. Any VPS will do for that, or you can take secondary DNS as a service from a third-party operator.

The DNS role in Windows Server

The typical scenario is an internal Active Directory zone. Installation and basic setup take a handful of commands:

# install the DNS role together with management tools
Install-WindowsFeature -Name DNS -IncludeManagementTools

# create a primary forward lookup zone
Add-DnsServerPrimaryZone -Name "example.local" -ZoneFile "example.local.dns"

# add an A record
Add-DnsServerResourceRecordA -Name "app" -ZoneName "example.local" -IPv4Address "192.168.10.20"

# forward external queries to a public resolver
Set-DnsServerForwarder -IPAddress "1.1.1.1","1.0.0.1"

Never point domain-joined machines at public DNS servers. Clients stop finding domain controllers, which breaks sign-in, group policy and file shares. Clients must use the internal DNS server, and that server forwards external queries outward through forwarders.

A caching resolver on the LAN — unbound or dnsmasq

Worth running when you want faster repeat lookups in an office, resolution for internal names, or control over where DNS queries go. The security-critical part is restricting who may ask:

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes

# check the configuration before restarting
unbound-checkconf

# confirm from outside that the server does NOT answer strangers
dig @<server-public-address> example.com A

A resolver that answers the whole internet is called an open resolver and sooner or later becomes part of an amplification attack: the attacker sends small queries with a spoofed victim address, and the bulky answers land on the victim. The outcome is abuse complaints, upstream filtering and wasted traffic. Check whether port 53 is reachable from outside with the port scanner and close it to everyone but your own network.

How to check that DNS is configured correctly

Verification answers two different questions: "which resolver is my machine using" and "what does the world return for my domain". Do not mix them — the commands differ.

Which servers your device uses

:: Windows
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4

# macOS
scutil --dns | grep nameserver

# Linux with systemd-resolved
resolvectl status

# Linux without systemd-resolved
cat /etc/resolv.conf

What a specific server answers for your domain

# short answer from the system resolver
dig example.com A +short

# the same question asked of two public resolvers directly
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

# who is authoritative for the zone, and what that server itself says
dig example.com NS +short
dig @ns1.example.com example.com A +short

# mail records and the full delegation path from the root
dig example.com MX +short
dig example.com +trace

:: the same on Windows without installing dig
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=MX example.com
nslookup -type=NS example.com

The key technique: compare what your system resolver returns with what the zone's authoritative server returns. If they match, the change has landed. If they differ, something along the path is serving cache and you simply wait for the TTL to expire.

Clearing caches

:: Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
sudo resolvectl flush-caches

Browsers keep their own cache: Chrome and its relatives clear it on the internal page chrome://net-internals/#dns, and elsewhere a full restart of the program helps — closing the tab does not.

Checking from outside instead of from your own machine

Your computer is a poor judge: it sees its own cache, its own resolver and its own network. Look at the domain from the outside:

• DNS record lookup — what A, AAAA, MX, NS, TXT and other types return right now, without your local cache in the way.
• DNS propagation check — how resolvers in different countries see the same domain. While some locations still return the old address, some of your visitors still land on the old site.
• Monitoring — continuous watch over the domain and its records, so you learn about a change or a disappearance before your users report it.

What to do if the DNS settings did not apply

Work down the list — causes are ordered by how often they turn out to be the real one.

1. The wrong adapter was configured. The classic: addresses typed into Wi-Fi properties while the machine is on a cable. Check with ipconfig /all or resolvectl status, which print the servers of the active connection.
2. The cache was not cleared. The old answer sits in the OS cache and, separately, in the browser cache. Clear both, with the command above and on the browser's internal page.
3. DoH is enabled in the browser. The browser asks its own resolver over HTTPS and ignores the system setting. Turn secure DNS off and repeat the check.
4. DHCP overwrote the settings. On Linux this happens on lease renewal if you edited /etc/resolv.conf directly. Set DNS on the NetworkManager profile and add ipv4.ignore-auto-dns yes.
5. A VPN or corporate client is running. Those replace the resolver by design for the duration of the session. Disconnect the tunnel and test again.
6. IPv6 DNS is still automatic. The system may prefer the ISP's IPv6 resolver. Set addresses for IPv6 too, or disable the protocol on the adapter.
7. The hosts file overrides everything. It is consulted before any DNS query. Check C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on macOS and Linux — a line left over from an old debugging session outlives every resolver setting.
8. The TTL has not expired. For the domain-records job: while a cached answer lives, the world sees the old value. Negative answers are cached separately, so if you queried a name before creating the record, "no such domain" is cached as well.
9. Records were edited in the wrong panel. The domain is delegated to one set of NS while the zone is being edited somewhere else. Compare the NS records with the panel you have open.

If the browser still reports a name resolution error after all of that, there is a focused walkthrough for that specific case in the article on fixing DNS_PROBE_FINISHED_NO_INTERNET.

Frequently asked questions

Which is better, 8.8.8.8 or 1.1.1.1?

Both are reliable and either is a fine default. In practice the difference comes down to the latency to the nearest point of presence on your network and to operator policy: whether you want malware, ad or adult content filtering. Measure both from where you are and keep the faster one.

Does changing DNS make the internet faster?

It only shortens name-to-address lookups — usually tens of milliseconds on the first request to each new domain, after which the cache takes over. Bandwidth and download speed do not change. A noticeable gain happens when the ISP resolver is overloaded, distant, or rewrites answers.

How long until the new settings take effect?

Changing the resolver on a device works immediately after the cache is cleared. A domain record change spreads across the world within its TTL — commonly from a few minutes to a day. Changing the domain's NS servers takes the longest: hours, sometimes a couple of days.

Can I configure DNS without administrator rights?

Changing system network settings, no — that needs administrator rights. Enabling DNS over HTTPS in a browser usually works without them, since the setting lives in the user profile unless group policy forbids it.

Router or per-device: which is better?

The router, when you want to cover the whole network at once, including devices with no usable settings of their own. The device, when only that one machine needs a different resolver, or when the router is not yours. Device settings win: they override whatever the router handed out.

Is using a public DNS resolver safe?

The operator of a public resolver sees which domains you look up — exactly as your ISP did before the change. DoH and DoT encrypt the query in transit but do not hide it from the resolver itself. So the real choice is not whether to encrypt, but who gets to keep that history.

Checklist: configuring DNS correctly

• You decided which job you are doing: changing your own resolver, or editing your domain's records.
• For a resolver: you configured the adapter that is actually in use and entered two addresses, primary and backup.
• IPv6 is handled: either DNS is set for it too, or the protocol is disabled on the adapter.
• If you configured the router, you checked the DNS field in the LAN/DHCP section, not only on WAN, and reconnected the devices.
• You know whether DoH is enabled in your browser and account for it when verifying.
• For a domain: you confirmed through WHOIS where the zone is delegated and are editing records in the right panel.
• MX points at a hostname backed by an A record, and there is no CNAME at the domain root.
• The TTL was lowered before the migration and restored afterwards.
• OS and browser caches are cleared, and the system resolver's answer matches the authoritative server's.
• You verified the result from outside with the record lookup and the propagation map, not only on your own machine.