AdGuard DNS vs AdGuard Home: which do you need

AdGuard DNS vs AdGuard Home in plain terms

AdGuard DNS vs AdGuard Home comes down to who runs the server. AdGuard DNS is a resolver that AdGuard runs for you: you type its hostname into your phone, or its IP addresses into your router, and you are done. AdGuard Home is open-source software that you install on your own machine, such as a home server or a VPS (virtual private server), and then point your devices at.

Both block ads and trackers the same way. They refuse to look up the names of ad servers. Neither one can see inside your apps, so neither removes YouTube ads or most in-app ads.

If you want ad blocking on one phone and you do not run a server, use AdGuard DNS. If you want a whole household covered, or you already rent a VPS and want your phone filtered on mobile data, AdGuard Home is the better fit. The rest of this guide explains why, and how to run AdGuard Home on a VPS without turning it into a tool for attackers.

What DNS blocking can and cannot do

DNS (domain name system) turns a name like ads.example.net into an IP address. A DNS blocker sits in the middle of that lookup. When a device asks for a name that is on a blocklist, the blocker does not return the real address, so the device never connects to that server. If the lookup itself is new to you, start with how DNS turns a name into an address.

This works well for ads and trackers that come from their own domains. It fails when the ad comes from the same domain as the content. The AdGuard Home FAQ says that any ad that shares a domain with content cannot be blocked by a DNS-level blocker, and it lists YouTube and Twitch ads as examples. Blocking that domain would block the video too. AdGuard's DNS filtering documentation adds that DNS filtering cannot tell different apps apart, because a DNS query carries a name, not the app that sent it.

The same filtering limits apply to both products. Choose between them for control and for where the filter runs. Do not choose either one expecting it to clean up YouTube.

What AdGuard DNS is: the hosted resolver

AdGuard DNS is the hosted service. AdGuard describes its public servers as a free, privacy-oriented DNS resolver. As of October 2026 there are three types of public server:

• Default, at dns.adguard-dns.com, blocks ads and trackers.
• Non-filtering, at unfiltered.adguard-dns.com, resolves everything.
• Family protection, at family.adguard-dns.com, uses the family filter.

Each one also has a pair of plain DNS IPv4 addresses, plus IPv6 addresses, for routers that cannot take a hostname. Copy them from the public servers page on adguard-dns.io rather than from a third-party list.

The default server also speaks encrypted DNS. DoT (DNS over TLS, where TLS is transport layer security) is at tls://dns.adguard-dns.com. DoH (DNS over HTTPS) is at https://dns.adguard-dns.com/dns-query. DoQ (DNS over QUIC) is at quic://dns.adguard-dns.com.

On Android, the Private DNS setting is where most people meet AdGuard DNS. AdGuard's Android page says that Android devices only support the DoT protocol in that field. So you type a hostname, dns.adguard-dns.com, and not a URL. The setting itself is explained in what Android's Private DNS setting actually does.

Public servers versus a private AdGuard DNS account

The public servers are anonymous and fixed. You get AdGuard's filter and nothing more. Both the public and the private service encrypt your DNS traffic. Only the private (personal) service adds customizable blocklists, custom filtering rules, request statistics, a query log, parental control and a dashboard to manage them. Each device then gets its own hostname in the form {Your_Device_ID}.d.adguard-dns.com. That is what you type into Android's Private DNS field instead of the public name.

Plan names are less clear. The AdGuard DNS license page, at adguard-dns.io/en/license.html, names four plans: Starter (free, provided by default, sign-up required), Personal, Team and Enterprise (by request). Its FAQ says AdGuard VPN subscribers get an AdGuard DNS Personal subscription as a gift. Billing is monthly or yearly, and the 30-day money-back guarantee covers 1-year subscriptions only.

How many requests or devices does the free Starter tier allow? The license page text did not show a number when we checked it on 20 October 2026, and older figures on AdGuard's blog are not a reliable answer. Check the plan comparison on the license page before you depend on a limit or a price.

What AdGuard Home is: the DNS server you run yourself

AdGuard Home is AdGuard's open-source DNS server, licensed under GPL-3.0. Its README calls it a network-wide ads and trackers blocking DNS server. You run it on your own machine. Once your router or your devices point at it, every device behind it is filtered, and no app is needed on the device.

The latest stable release on 20 October 2026 is v0.107.79, published on 18 August 2026. Its release notes include security fixes, one of them for resource exhaustion in DNS over QUIC. Do not run an older build on anything that faces the internet. Pin the version you install, either the release file from the GitHub releases page or the Docker image adguard/adguardhome:v0.107.79, and check the releases page for a newer tag first. The install itself is covered by AdGuard's getting-started page, which also links the official Docker image and a Snap package.

What you gain over the hosted service is control. The query log, the blocklists and the statistics live on your disk. The only outside party that sees your lookups is the upstream resolver you choose. What you take on is operations. You apply updates and keep it running. If it stops, name lookups stop for every device that depends on it.

The ports matter on any server. AdGuard's getting-started page lists 3000/TCP for the first-run setup, 80/TCP for the web interface, and 53/UDP for the DNS server. It tells you to check your firewall settings before the first start.

AdGuard Home on a home network

At home the setup is simple and the risk is low. Install AdGuard Home on a small always-on machine inside your network. Then set the DNS server that your router hands out by DHCP (dynamic host configuration protocol) to that machine's local IP. Every device that joins the Wi-Fi now uses it, with nothing to configure on the device.

Over IPv4, port 53 on that machine is only reachable from inside your network as long as you do not forward it on the router. IPv6 is different. Devices on an IPv6 network usually have global addresses, and Netgate's pfSense documentation notes that "IPv6 all but eliminates the need for traditional port translated NAT (PAT)". With no NAT in the way, what keeps port 53 private over IPv6 is the router's firewall, not the absence of a port forward. Check that your router drops unsolicited inbound IPv6 traffic. For a second layer, list your local IPv4 and IPv6 ranges in CIDR form under allowed_clients, so AdGuard Home accepts requests only from your own devices. With those two checks in place, the home case stays low risk.

The weakness is mobility. A phone is filtered on home Wi-Fi and unfiltered on mobile data. That gap is the usual reason people move AdGuard Home to a VPS.

Why AdGuard Home on a VPS must never answer port 53 to everyone

A VPS has a public IP address and no home router in front of it. Install AdGuard Home, leave port 53 open with the Allowed clients list empty, and you are running an open resolver: a DNS server that answers queries for any name from anyone on the internet.

Open resolvers are a known attack tool. The CISA (Cybersecurity and Infrastructure Security Agency) alert on DNS amplification attacks describes attackers using publicly accessible open DNS servers to flood a target system with DNS response traffic. Plain DNS runs over UDP, which has no handshake. So an attacker can send a query with a forged source address, the address of the victim. Your server sends its answer to the victim, and a small query can produce a much larger answer. CISA's advice to server administrators is to restrict recursion to clients on their own network.

AdGuard's own guidance points the same way. Its page on running AdGuard Home securely warns that exposing the server may expose it to DDoS (distributed denial of service) attacks. It says plain DNS should be disabled, or made unreachable from outside, when your clients can use encrypted protocols.

The configuration reference has two protection settings. ratelimit sets how many queries per second AdGuard Home should handle, and its default is 20. refuse_any refuses queries of type ANY, so attackers cannot use your server as a reflection. Both are documented as safe to disable only if the DNS server is not available from the internet. On a VPS, leave both on.

Test from a machine that is not the VPS, such as your laptop:

dig @203.0.113.10 example.com

Replace 203.0.113.10 with your VPS's public IP. If the reply has an ANSWER SECTION with an address in it, your server answers anyone. Fix that before you do anything else. A timeout or a REFUSED status is the result you want.

That leaves two sane patterns for a VPS.

Pattern 1: DNS over TLS on your own hostname, with an allow list

In this pattern the server answers only encrypted DNS, on a real hostname, and only for devices it knows. DoT is the one to get right, because it is the protocol Android's Private DNS field speaks.

You need these pieces:

• A domain name that points at the VPS, for example dns.example.com.
• A real TLS certificate for that name. AdGuard Home's encryption settings take a PEM certificate chain and a private key, and server_name must match one of the DNS names in the certificate.
• DoT on port 853. That is the port in AdGuard Home's configuration example. Android's Private DNS field asks only for a hostname, so stay on the standard port.

Check the certificate from your laptop before you touch the phone:

openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null

The output should end with Verify return code: 0 (ok). Any other code means the certificate does not match the name or is not trusted. A phone will reject that certificate too.

Lock it down with ClientIDs

A ClientID is a short name for one device, which the device sends inside the encrypted connection. AdGuard Home's clients page confirms that ClientIDs work over DoH, DoT and DoQ. Over DoT the ClientID goes in the hostname. A phone set to pixel.dns.example.com connects as the client pixel.

That hostname form needs a wildcard certificate, valid for both *.dns.example.com and dns.example.com. A wildcard certificate from Let's Encrypt needs a DNS-01 challenge, which getting a wildcard certificate with certbot and DNS-01 walks through.

Then list the clients you allow. In the web interface this is the Allowed clients field, which takes CIDRs, IP addresses or ClientIDs. In AdGuardHome.yaml it is allowed_clients under dns:

dns:
  allowed_clients:
    - pixel
    - laptop

Once that list has entries, AdGuard Home accepts requests only from those clients, and disallowed_clients is ignored. Stop AdGuard Home before you edit the file. A running AdGuard Home overwrites the file, so your change is lost.

A plain query on port 53 carries no ClientID, so it does not match the list. Close port 53 at the firewall anyway, so the server does not reply at all. On Ubuntu with ufw (see ufw firewall basics on a VPS):

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 853/tcp
sudo ufw enable
sudo ufw status verbose

ufw status verbose should list OpenSSH and 853/tcp as ALLOW IN, and nothing for port 53. Then run the dig test from your laptop again. If you run AdGuard Home in Docker with published ports, the outside test is the one that counts. Docker's documentation says traffic to a published container port is diverted before it goes through the ufw firewall settings, so ufw rules do not protect it.

On the phone, open Private DNS (the path varies by Android version, usually under Network & internet), choose the hostname option, and enter pixel.dns.example.com. Before you leave it on, read when Private DNS mode should be on or off, because a hostname that stops answering takes the phone's name lookups with it.

Keep the admin pages off the internet

Ports 3000 and 80 are the setup page and the web interface. Neither belongs on a public IP. Leave them closed in ufw and reach them through an SSH tunnel from your laptop:

ssh -L 3000:localhost:3000 you@203.0.113.10

Then open http://localhost:3000 in the laptop's browser. After setup, tunnel the admin port you picked in the wizard the same way.

Pattern 2: AdGuard Home reachable only over Tailscale or WireGuard

In this pattern AdGuard Home never faces the internet at all. Your devices reach it through a private tunnel, so you need no domain name and no certificate. The tunnel already encrypts the traffic. Tailscale is the easy way to build that tunnel, and what you can do with Tailscale covers the basics.

Install Tailscale on the VPS and on your phone, signed in to the same tailnet. Then close every public port except SSH, and allow everything that arrives through the tunnel interface:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow in on tailscale0
sudo ufw enable
sudo ufw status verbose

ufw status verbose should show Anywhere on tailscale0 as allowed. Drop the OpenSSH rule only if you already reach the VPS over SSH through Tailscale. Otherwise you lock yourself out.

Next, find the VPS's tailnet address:

tailscale ip -4

In the Tailscale admin console, open the DNS page. Under Global nameservers, add that address, then enable Override DNS servers. Tailscale's DNS documentation notes that a nameserver on a Tailscale IP address does not need subnet routing, so this is the whole setup. Every device on the tailnet now resolves through AdGuard Home whenever Tailscale is connected. When Tailscale is off, the phone goes back to its normal resolver.

Each device's queries arrive from its own tailnet address. You can list those addresses in allowed_clients if you want the same allow list as in pattern 1.

Plain WireGuard works the same way: set DNS = in each client config to the server's tunnel address, and allow port 53 only on the WireGuard interface. WireGuard vs Tailscale helps you choose between the two. If you want the Tailscale model without its hosted coordination server, Headscale, a self-hosted Tailscale control server is the usual answer.

Which one do you need?

• One phone, no server. Use AdGuard DNS. Type dns.adguard-dns.com into Private DNS. Make an account if you want a per-device hostname, your own blocklists and a query log.
• A whole household behind one router. Use AdGuard Home at home, and set it as the router's DNS server.
• Phones away from home, plus a server you already rent. Use AdGuard Home on the VPS, over DoT with ClientIDs, or over your tailnet. Never with port 53 open to the world.

If you choose AdGuard Home on a VPS, run the dig test from outside after every change to the firewall or the config. It is the one check that tells you whether you built a private resolver or an open one.

FAQ

Does AdGuard DNS or AdGuard Home block YouTube ads?

No. Both block at the DNS layer, and the AdGuard Home FAQ says any ad that shares a domain with content cannot be blocked by a DNS-level blocker. It names YouTube and Twitch ads as examples. Blocking the domain that serves those ads would also block the videos.

Is AdGuard DNS free?

The public AdGuard DNS servers are free. The private service with a dashboard, custom blocklists and a query log has a free Starter tier that needs an account, plus paid Personal, Team and Enterprise plans. Check the plan comparison on adguard-dns.io/en/license.html for current limits and prices, because those numbers change.

Can I use a ClientID with Android's Private DNS on my own AdGuard Home?

Yes. AdGuard Home accepts ClientIDs over DNS over TLS, which is the only protocol Android's Private DNS field supports. You put the ClientID in the hostname, such as pixel.dns.example.com, so the server needs a wildcard certificate that covers both *.dns.example.com and dns.example.com. Add the ClientID to allowed_clients so only your devices get answers.

Why is AdGuard Home on a VPS with port 53 open a problem?

An AdGuard Home server with port 53 open on a public IP and an empty allowed_clients list is an open resolver, and it answers anyone. Filling that list with your own IP addresses, CIDRs or ClientIDs makes AdGuard Home accept requests only from those clients. CISA describes attackers using open DNS servers to flood a target with DNS response traffic, by sending queries with the victim's address forged as the source. Serve only encrypted DNS to an allow list, or reach the server only over Tailscale or WireGuard, and confirm with dig from outside that port 53 gives no answer.