# mullvad/dns-blocklists for Mullvad DNS filtering

> mullvad/dns-blocklists is an Ansible-based source for the DNS blocking lists used by Mullvad encrypted DNS and VPN relay DNS services. It is useful for understanding Mullvad's filtering combinations and upstream sources, but it is not a standalone consumer DNS client or resolver.

**mullvad/dns-blocklists** — Lists and configuration for our DNS blocking service

- Repository: https://github.com/mullvad/dns-blocklists
- Stars: 1,991 · Forks: 98
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mullvad-dns-blocklists

## Mullvad's DNS blocking data model

This repository solves a narrow infrastructure problem: defining the DNS blocklists that Mullvad imports for its encrypted DNS and VPN relay DNS services. It is aimed at operators and contributors who work with the service configuration, not at users looking for a ready-made DNS application. The README says that the lists are used by server types represented as `doh` for encrypted DNS servers and `relay` for VPN servers, also called VPN relays.

The blocklists are organized by filtering purpose. Advertising entries include oisd-small, the Frellwits Swedish hosts file, AdguardDNS, popup-ad filtering, a Mullvad custom file, and Adguard's mobile filter. Tracker entries cover EasyPrivacy and several Hagezi device-specific lists, together with a Mullvad tracker list. Malware filtering uses a Mullvad custom list, URLhaus, and a Hagezi threat-intelligence mini list. Adult-content filtering uses oisd-nsfw and a Mullvad custom list, while gambling filtering uses Hagezi gambling lists. Social-media files are generated by scripts in `scripts/` and placed in `files/social`.

That separation matters because the repository is not one universal denylist. The effective filtering policy depends on the service category and the selected combination. The README points users to `COMBINATIONS.md` for the combinations of DNS content blockers, which is the practical entry point for deciding what a particular Mullvad DNS endpoint includes.

## Ansible generation and upstream list flow

The visible architecture is an Ansible playbook plus inventory variables, templates, scripts and generated or imported files. The repository contains `playbook.yml`, `ansible.cfg`, `inventory/`, `templates/`, `scripts/`, `files/` and `output/`. The README specifically identifies `inventory/group_vars` as the place where the lists imported by each server type are defined. It also identifies `inventory/group_vars/all.yml` as the location for `dns_blocklists_exclude`, with exceptions split per blocklist.

The data flow is therefore configuration to generated DNS blocking files. The inventory describes which upstream lists belong to a service category, while exceptions can remove or tolerate problematic entries. Social-media blocking has a separate generation path: scripts under `scripts/` produce files under `files/social`. The repository layout suggests that the output and template directories participate in producing the files consumed by the service, although the README does not give a complete command sequence for running the playbook.

The service boundary is also explicit. Encrypted DNS endpoints use hostnames such as `dns.mullvad.net`, `adblock.dns.mullvad.net`, `base.dns.mullvad.net`, `extended.dns.mullvad.net` and `family.dns.mullvad.net`. The README says that TLS and HTTPS are offered for these options. By contrast, VPN relay DNS uses the lists defined for the `relay` server type. A change in a list can therefore affect a DNS service classification rather than every DNS request made through a Mullvad VPN connection. That distinction should be checked before copying configuration.

## Filter combinations for ads, malware and social media

Mullvad documents several service profiles rather than one filtering level. Vanilla provides encrypted DNS without blocking. Ad-block adds advertising and tracker blocking. Base adds malware blocking to those categories. Extended adds social-media blocking. Family adds adult-content and gambling blocking to the Base categories. The README also names an All option; consult `COMBINATIONS.md` for the complete contents of that profile.

The distinction between TLS and HTTPS is operational rather than cosmetic. The same filtering name is associated with a TLS hostname and an HTTPS DNS-query endpoint. For example, the Ad-block profile lists `adblock.dns.mullvad.net` for TLS and `https://adblock.dns.mullvad.net/dns-query` for HTTPS. A deployment based on this repository needs to decide whether it is reproducing Mullvad's public encrypted-DNS behavior, configuring a Mullvad VPN relay, or maintaining an independent resolver that imports the same lists.

The repository is therefore most useful as a policy reference for server operators. It does not describe local operating-system settings, browser extensions, or commands for importing a list into a third-party resolver. If that is the intended use, another tool with a documented resolver integration would be a better fit.

## Validation rules and exclusions for upstream feeds

Mullvad does not treat every submitted feed as acceptable. The README says that proposed blocklists should be fully validated and verified first, and contributors are asked to point maintainers toward a reputable list before opening an issue. The stated reasons for rejecting a list include its being an amalgamation of other blocklists, no longer being maintained, or blocking domains that Mullvad believes should not be blocked, including its own domains.

There is also an operational exception mechanism. The README says upstream lists can contain malformed URLs that cause generation to fail, or can block Mullvad domains. Those exceptions are maintained under `dns_blocklists_exclude` in `inventory/group_vars/all.yml`, split per blocklist. This is a meaningful maintenance cost for anyone adopting the data. Simply copying every upstream URL into an independent resolver would discard the validation and exception decisions encoded in Mullvad's configuration.

The repository lists upstream URLs for feeds from OISD, Frellwits, Firebog, Hagezi, Adguard and URLhaus, as well as custom Mullvad files. Their availability and content are external to this repository. The README does not provide a pinned snapshot format, an offline cache procedure, or a documented rollback mechanism for a bad upstream change. A fork operator should account for that boundary before treating the feed definitions as a self-contained package.

## Deployment timing and the shutdown boundary

The README states an operational expectation after updates: it takes about an hour for all servers to pick up updated lists. A list updated at 07:00 is expected to be available by 09:00 on the same day. It also warns that server caching means the new data might not be used immediately. This is useful when diagnosing why a recently changed domain still resolves, because repository content and deployed resolver behavior are not necessarily synchronized at the moment of a commit.

The project also has a scheduled intent rather than a release contract. Mullvad aims to update the lists every Monday through Thursday, and the README directs readers to repository commits to view the latest update. There are no GitHub releases listed. The repository was not archived, and its last push was on 2026-10-15. That supports a recent change history, but the README still requires readers to inspect commits rather than expect versioned artifacts or release notes.

A separate boundary is especially important for encrypted DNS users. The README warns that Mullvad's public encrypted DNS servers will be shut down on November 2, 2026. It says the `.mobileconfig` files will stop working and that the `encrypted-dns-profiles` repository will soon be archived. Users who plan to use Apple configuration profiles should not treat this repository as a durable client distribution channel. The list definitions may still inform server-side work, but the documented public service has a stated end date.

## License and alternatives to Mullvad's list definitions

The repository is licensed under GPL-3.0. That matters when an organization copies or modifies its Ansible configuration, generated files or scripts, because the license imposes obligations on distribution and derivative work. This is a licensing note rather than legal advice, and an adopter should review the repository's `LICENSE.md` for the applicable terms.

A real alternative is to use a separately maintained DNS filtering solution with its own documented resolver configuration, rather than trying to turn this repository into a standalone service. The difference is in scope. Mullvad's project starts from Ansible inventory variables and upstream feed selection, then generates files for Mullvad's encrypted DNS or VPN relay infrastructure. A standalone resolver would generally need its own installation, update mechanism, cache policy and failure handling, none of which this README specifies.

Another alternative is to consume the same public feeds directly and implement equivalent filtering locally. That avoids copying Mullvad's exact policy, but it also discards Mullvad's per-list exclusions, validation decisions and service combinations. The choice depends on whether the goal is Mullvad parity or independent control. For Mullvad parity, start with `COMBINATIONS.md` and `inventory/group_vars`. For independent filtering, treat the upstream URLs as reference data rather than as a complete deployment plan.

## Conclusion

Adopt this repository when you need to inspect or modify Mullvad's DNS blocking definitions for an equivalent server-side setup. Do not expect a local DNS server, an Apple profile installer, or a general-purpose blocklist manager from it. Verify first whether your target is encrypted DNS or VPN relay DNS, then inspect `COMBINATIONS.md`, `inventory/group_vars`, and `playbook.yml` for the intended combination and generation path. The last push was on 2026-10-15.

## FAQ

### What is mullvad/dns-blocklists used for?

It contains the DNS blocklists and Ansible configuration used by Mullvad's encrypted DNS and VPN relay DNS services. It is a source for server-side filtering definitions, not a standalone DNS resolver.

### Where can I see the blocklists used by encrypted DNS and VPN relays?

The README says the lists are defined in `inventory/group_vars`, with `doh` representing encrypted DNS servers and `relay` representing VPN servers. `COMBINATIONS.md` lists the available combinations of DNS content blockers.

### Can I use Mullvad DNS blocklists with an Apple device?

The README links to a separate `encrypted-dns-profiles` repository containing Apple `.mobileconfig` files, but warns that Mullvad's public encrypted DNS servers will shut down on November 2, 2026. Those profiles will stop working after that shutdown, according to the README.

## Sources

- [Issues](https://github.com/mullvad/dns-blocklists/issues)
- [License: GPL-3.0](https://github.com/mullvad/dns-blocklists/blob/main/LICENSE)
- [mullvad/dns-blocklists on GitHub](https://github.com/mullvad/dns-blocklists)
- [README](https://github.com/mullvad/dns-blocklists/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mullvad-dns-blocklists