# AdGuard DNS: blocking at the resolver, with every encrypted transport > AdGuard DNS is a public resolver that blocks trackers before the request ever leaves your network, and it encrypts the lookup in whichever protocol you prefer. The readme is unusually honest about the trade-off, since DNS-level blocking cannot do the cosmetic work that a browser extension does, and the repository is a complete server you can run yourself. **AdguardTeam/AdGuardDNS** — Public DNS resolver that protects you from ad trackers - Repository: https://github.com/AdguardTeam/AdGuardDNS - Website: https://adguard-dns.io/ - Stars: 964 · Forks: 83 - Language: Go - License: AGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/adguardteam-adguarddns ## One resolver for every device on the network The description is short and the positioning is different from the usual ad blocker pitch. AdGuard DNS is a public DNS resolver that protects you from ad trackers. The readme expands it as an alternative solution for tracker blocking, privacy protection and parental control, easy to set up and free to use, providing a necessary minimum of best protection against online ads, trackers and phishing no matter what platform and device you use. That last clause is the whole argument. A browser extension protects one browser on one device, and every device in a house is a separate installation, and a locked down corporate laptop is a separate problem again. Pointing the router at a resolver puts the filtering underneath all of it, including the smart television, the games console and the guest's phone, and it costs one change to one setting. The basic feature list names the three things you get. Blocking trackers network-wide with no additional software required, and the readme points out you can set it up on your router to block ads on all devices connected to your home wireless network. Protection from phishing and hazardous websites and from malvertising, which is malicious ads. And a family protection mode that blocks access to all websites with adult content and enforces safe search in the browser, in addition to the usual ad blocking and browsing security. The implementation is Go, the licence is AGPL 3.0, the project is not archived, and the last push was on 2026-10-19. ## Why encrypt the lookup at all The DNS privacy section is the argument for the encrypted transports, and it is worth reading because it explains the whole design. If you use the regular client-server protocol, you are at risk of your DNS requests being intercepted and, subsequently, eavesdropped and or altered. The readme gives a concrete example, that in the United States the Senate voted to eliminate rules that restricted internet service providers from selling their users' browsing data, and it notes that DNS is often used for censorship and surveillance purposes at the government level. All of that is possible because of the lack of encryption, and AdGuard DNS provides a solution. It supports all known DNS encryption protocols including DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC and DNSCrypt. The list is the point. These are the four protocols that exist for this purpose, and the project supports all of them, so a resolver has to be configured to speak whichever one your clients and your network will accept. DNS-over-HTTPS is the one browsers can use natively, which makes it the practical choice for a mixed network of modern devices, and the others cover the cases where a browser cannot be configured or where the network operator objects to a particular protocol. On top of that, the project publishes a no-logs privacy policy, meaning that browsing activity is not recorded. For a resolver, that promise is about the whole business model, because a DNS server sees every hostname every device on the network looks up, and that is a complete history of what everyone in the building is doing. ## The readme admits what DNS blocking cannot do There is a question in the readme with the heading about whether AdGuard DNS can replace a traditional blocker, and the answer is worth quoting in substance because it is the honest core of the comparison. It depends. DNS-level blocking lacks the flexibility of the traditional ad blockers, because there is no cosmetic page processing, so in general traditional blockers provide higher quality. Cosmetic filtering is the part of ad blocking that removes the empty space a hidden ad leaves behind, and it cannot be done at the resolver, because the resolver never sees the page. It sees a name and it answers with an address or with nothing. That is a real limitation and it is worth understanding before you move a household or an organisation over. A browser extension can hide the gap an ad leaves, and it can apply rules that depend on the page, and it can be given an exception list per site. A resolver cannot do any of that. What it can do is stop the request, which is the part that saves bandwidth and stops the tracker from seeing you at all, and that is the part a company cares about when it rolls this out across a fleet. The wording of the readme is also a signal about the product's intent. It positions the resolver as a complement, not a replacement, and the family mode as an addition rather than a competitor to a parental control system. ## The personal account and the API The personal account is where the project becomes interesting for a technical user. Signing up for a personal AdGuard DNS account gives access to five things. You can manage devices and their settings in one place. You can manage the blocklists that are used to block ads. You can view statistics on the DNS queries, on the companies and on the countries your devices try to connect to. You can maintain your own set of rules in the user rules section, using a flexible rules system with its own documented syntax. And there is an API for integrating with it if you need that. The statistics are the feature that changes behaviour rather than just adding information. A per-company breakdown of who your devices are talking to is the report that makes somebody in an organisation decide to act, and it is a report you cannot get from a browser extension because an extension only sees one device. The rules system is the feature that changes capability. With a filter syntax you can write your own rules rather than only choosing from the maintained lists, and the documentation for that syntax is a separate page, as is the API documentation. For a self-hosted deployment, the same capabilities are what the configuration file and the API of your own server give you, and the readme's mention of the rules system and the API as first-class links is a hint about how much of the hosted product is also in the open source server. ## The server: Go, with the pieces you would expect The repository is a complete resolver rather than a wrapper, and the dependency list describes it accurately. The core is the DNS library from the same organisation, the URL filtering library that does the actual blocking, the DNSCrypt implementation, and a QUIC library for the encrypted transport. On the operational side there is a Redis client, a connection pool library, a caching library, a probabilistic counting library used for the statistics, a MaxMind database reader for the country lookups, a Prometheus client for metrics, a gRPC stack, an environment variable parser for configuration, and the Sentry client for error reporting. Two details are worth noticing. The DNS server is a separate module inside the repository, with its own go.mod and go.sum, which means the resolver is versioned separately from the rest, and there is a workspace file so the two are built together. And the module requires a very recent Go toolchain, which tells you the project tracks the language closely. The repository also has the things a server needs that are not code: a Dockerfile with a comment header that instructs the author to bump a project version number whenever the build changes meaningfully, so that a stale layer can be detected, a configuration example file, a hacking document, a documentation directory, a scripts directory, a staticcheck configuration, and a changelog. The licence is the AGPL in version 3, and the copyright line names AdGuard Software Ltd for the period from 2022 to 2026. ## Build conventions that say how the project is run The Makefile and the Dockerfile are worth reading for the conventions rather than the commands, because they describe how a commercial open source project keeps its build honest. The Makefile declares itself POSIX-compliant, and there is a comment explaining that hyphens are allowed in target names for now but that may change. The macros are deliberately not named with the obvious names, because GNU make would export them as environment variables with a literal value, which is not what the build wants, so they use a dot in the name instead. The toolchain version is pinned, the proxy is pinned, the telemetry is off, and the build is reproducible with a revision and a branch taken from git unless they are supplied. The Dockerfile comments are a numbered set of guidelines about layer caching, preferring build arguments over environment variables so the final image does not carry them, using the output stage only with a scratch base, using a dockerignore file so the context stays small, and adding a cache buster argument to stages so the build can be rerun when needed. The base image is a builder image from the same organisation, pinned to a Go toolchain version. Between the two files there is a repeated convention that has nothing to do with the build: a comment at the top of each file that explains it is used to check local copies, and a version number to bump when the file changes significantly. That is a small piece of engineering aimed at a specific failure, where somebody edits a Dockerfile in a pull request and the continuous integration passes because the stale layer is still cached. ## Conclusion AdGuard DNS suits a household or an organisation that wants one setting to cover every device on the network, including the ones that cannot run an extension, and that wants its lookups encrypted on the way out. It is a poor fit if you need the cosmetic filtering of a browser extension, since the readme says plainly that DNS-level blocking does not do that work, and a poor fit if you need per-device exception lists that a resolver cannot express. Before you deploy the server yourself, read the configuration example and the hacking notes, and decide which blocklists and upstream resolvers you are willing to trust with the entire DNS traffic of your network. ## FAQ ### What does AdGuard DNS block? Trackers and ads network-wide with no extra software on the device, plus protection from phishing, hazardous websites and malvertising. There is also a family protection mode that blocks adult content and enforces safe search in the browser. ### Which encrypted DNS protocols does AdGuard DNS support? All of the known ones: DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC and DNSCrypt. The project also publishes a no-logs privacy policy, meaning browsing activity is not recorded. ### Can AdGuard DNS replace a browser extension blocker? The readme says it depends, and explains that DNS-level blocking lacks the flexibility of traditional blockers because there is no cosmetic page processing, so traditional blockers generally provide higher quality. A resolver stops the request but never sees the page, so it cannot remove the space an ad leaves behind. ### What can a personal AdGuard DNS account do? Manage devices and their settings in one place, manage the blocklists used to block ads, view statistics on the DNS queries and on the companies and countries your devices connect to, maintain your own rules with the flexible rules system, and use the API to integrate with the service. ## Sources - [AdguardTeam/AdGuardDNS on GitHub](https://github.com/AdguardTeam/AdGuardDNS) - [Issues](https://github.com/AdguardTeam/AdGuardDNS/issues) - [License: AGPL-3.0](https://github.com/AdguardTeam/AdGuardDNS/blob/master/LICENSE) - [Project website](https://adguard-dns.io/) - [README](https://github.com/AdguardTeam/AdGuardDNS/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adguardteam-adguarddns