DotNS.
Take back your DNS.

01

A small setting. A meaningful choice.

Most people choose their browser carefully and never choose their DNS resolver. Yet that quiet service sits near the beginning of almost every visit: an application has a name, and it needs an address. Leaving this choice invisible makes it easy to forget who receives those questions and which policy shapes the answers.

Today I want to introduce DotNS, an independent French DNS initiative by my friend Ines Wallon. Its playful tagline, the duck hunt of DNS, introduces a practical ambition: resolve useful names while filtering domains associated with advertising, tracking and malicious activity. The humour makes the project approachable. The subject deserves serious attention.

What interests me is the combination: a French approach to digital sovereignty, an identifiable maintainer, encrypted DNS options, open-source filtering foundations and a no-log commitment. Sovereignty here is about making a deliberate choice of operator and technology. It should invite questions about governance and dependencies, rather than substitute a flag for technical understanding.

This guide explains the idea, shows how to configure Android and Firefox, and gives you a way to assess the result. The public addresses and documentation below were reviewed on November 6, 2026. Check the project's current documentation before changing a device.

Sources: DotNS service overview, Why DotNS exists.

02

No-log: my assessment from inside the solution.

I did not want to introduce this project by repeating a slogan. I had the opportunity to look inside its infrastructure and examine the solution in depth. That access is why I can speak personally about the no-log approach.

That is my assessment of the solution I examined. The internal configuration and operational details remain private. This article does not publish an audit report or claim a certification; it gives readers a clear, accountable statement from someone who has actually looked behind the service.

The distinction matters: encrypting a DNS connection protects its journey to the resolver, while a no-log policy concerns what the operator retains. Neither term should be used as a shortcut for the other. A provider can use encrypted transport and still retain query histories. When choosing a service, ask both questions.

03

Follow a DNS question from your device.

A DNS resolver helps translate a name such as example.com into the records an application needs. Filtering adds a decision about the requested name. If it matches a blocking policy, the resolver can prevent normal resolution; otherwise, it can return the usual answer.

SysWarden.

01 / A CONCEPTUAL FILTERED DNS REQUEST

1. 01Your applicationA website or application needs to resolve a domain.
2. 02Encrypted connectionA configured client sends the DNS question to DotNS.
3. 03Filtering decisionThe requested name is checked against the resolver policy.
4. 04DNS responseAllowed names proceed to normal resolution; names blocked by policy receive a blocking response.

Three ideas belong in separate boxes. Resolver choice determines who answers. DoT, DoH or DoQ protects the client-to-resolver transport. DNSSEC concerns the authenticity and integrity of signed DNS data. DNSSEC does not hide your query and does not certify that a website is safe. Nor does naming these protocols establish that every application is using them.

Encrypted DNS is not a VPN. It does not encrypt every packet on your device, conceal your identity from the resolver, or replace HTTPS for the destination website. It solves a specific part of the privacy problem, which is already useful when configured deliberately.

Sources: DNSSEC security goals, DoH privacy considerations.

04

Several recognised blocklists, put to work.

DotNS combines several recognised, operational blocklists. My examination of the solution confirms that filtering is part of the running service. The public configuration also makes its inputs reviewable: it references sources including HaGeZi, StevenBlack, AdAway, Disconnect and CERT Polska, alongside other domain feeds and local lists.

These sources address different parts of the problem, from advertising and tracking to malicious domains and phishing. Combining feeds can broaden coverage, while requiring careful false-positive management. The project also publishes a domain allowlist: exceptions are an important part of operating a filter without breaking legitimate services.

The public bind-adblock repository exposes a tool that collects blocklists and produces a BIND zone. It identifies its upstream origin and includes an MIT licence. This is a concrete open-source component you can inspect, rather than a claim that every part of the hosted infrastructure is published.

SysWarden.

02 / FROM LISTS TO A FILTERING POLICY

1. 01Multiple sourcesCommunity and security feeds contribute domain entries.
2. 02Policy preparationThe public tool combines inputs into a BIND zone.
3. 03Resolver policyBlocking rules and allowed exceptions shape DNS answers.
4. 04Feedback loopFalse positives need review, correction and a new check.

More entries are not automatically better protection. A useful policy balances coverage, freshness and false positives. A business application can depend on a third-party name that looks unimportant until authentication, payment or document loading stops working. That is why testing real workflows matters more than celebrating a large counter.

Sources: Published list configuration, Filtering tool README, MIT licence.

05

Choose the address that matches your client.

The DotNS homepage publishes the following connection details. A hostname for an encrypted resolver and an HTTPS query URL are not interchangeable: put the right value in the right field.

On November 4, DotNS announced DNS over QUIC (DoQ) support. DoQ uses QUIC for encrypted DNS transport; it requires a client that supports the protocol. You do not enable DoQ merely by pasting a hostname into a DoT-only setting. Its performance will also depend on your client and network, so this guide makes no universal latency promise.

Sources: Current connection details, DotNS DoQ announcement, DNS over QUIC standard.

06

Tutorial 1: configure Android Private DNS.

Start with one personal device, on a network you are authorised to configure. Record its previous Private DNS setting so that you can restore it. Android introduced Private DNS in Android 9; menu names vary by version and manufacturer.

1. Open Settings and search for Private DNS. On many devices it appears under Network & internet; other manufacturers place it under Connections and additional connection settings.
2. Select Private DNS provider hostname.
3. Enter the hostname below, without a scheme, path or trailing space.
4. Save the setting, then check that normal browsing and the applications you rely on still work.

dot.dotns.net

A chosen provider hostname requires a working secure connection. If Android cannot connect, inspect the spelling and the network situation before making unrelated changes. Automatic is a different policy and can fall back to ordinary DNS; it does not mean “always use DotNS”.

To undo the change, return to the same menu and restore the exact option you recorded. System DNS settings apply to applications using the system resolver; an application with its own DNS implementation can behave differently.

Sources: DotNS Android guide, Android network and Private DNS settings, Android Private DNS behaviour.

07

Tutorial 2: choose DotNS in Firefox desktop.

Firefox desktop can select its own DNS-over-HTTPS provider. This is a useful way to try DotNS in one browser, but it does not reconfigure the whole computer. Record your current provider and protection level first.

1. Open Firefox Settings, then Privacy & Security.
2. Find DNS over HTTPS. Depending on your version, provider controls appear within the protection settings or behind Advanced settings.
3. Choose the custom-provider option and enter the complete HTTPS URL below.
4. Select the protection and failure behaviour you actually want. Current Mozilla documentation describes a Custom mode; labels can differ in older versions.
5. Save if prompted, revisit the panel and check its connection status. Then test your usual browsing workflow.

https://doh.dotns.net/dns-query

Pay attention to fallback. Firefox's Default and Increased protection, and Custom without its warning option, can fall back to the system resolver under some conditions. Where available, Max protection, or Custom with Always warn me if secure DNS isn’t available, makes a secure-DNS failure visible. An exception that permits system resolution can also bypass your chosen DNS filtering policy.

To revert, restore the provider and protection level you noted earlier. On a managed device, follow your organisation's policy: a local setting may be controlled centrally.

Sources: DotNS Firefox guide, Current Firefox controls and protection levels, Mozilla provider and enterprise policy reference.

08

Tutorial 3: investigate a blocked domain.

A broken page is not enough to diagnose a DNS false positive. It could be a connection problem, a browser extension, an expired session or a service outage. Start with the failing hostname and a small reproduction.

1. Use the domain-checking tool on the DotNS homepage. Enter the hostname you want to examine, rather than an entire URL containing private parameters.
2. Read the result as a blocklist lookup, not proof that your device sent its last request to DotNS. The site explains that this search runs locally in your browser.
3. Check the service status page and the DNS configuration of the affected application. A browser-specific provider can differ from the system setting.
4. If the name appears blocked and the use is legitimate, follow the project's allowlist-request link. Provide the domain, the expected function and a minimal description. Do not send credentials, session links or private browsing history.

For a practical acceptance check, try a few ordinary tasks you care about: sign in to a service, open a document and load a page with its normal resources. Record which device and browser settings you used. If you temporarily restore the previous resolver for comparison, record that too; a successful comparison is useful evidence, not a reason to forget which policy is now active.

A normal page loading successfully only demonstrates that the task worked. It does not prove encryption, the absence of retained logs or complete filtering coverage. Keep those checks separate so that each observation answers a real question.

09

A useful layer, with clear boundaries.

DNS filtering works at the domain-name level. If wanted content and unwanted tracking share the same hostname, it cannot always separate them. Direct connections to an IP address or applications choosing a different resolver can bypass a DNS-based policy. An unlisted malicious name can still resolve. These are reasons to use several complementary protections.

Keep browser and operating-system updates, account protection, endpoint controls and good recovery practices. For an organisation, test internal names, VPN behaviour and critical applications before expanding deployment. A secondary resolver with a different policy may introduce inconsistent results; redundancy deserves the same attention as the first address.

DotNS and SysWarden operate at different places in a security design. A resolver can filter a name before an application connects. Linux host protection addresses its own host and network responsibilities. This article introduces a complementary open-source initiative; it does not announce a product integration or suggest that changing DNS replaces host defence.

Sources: Technical scope and limits of DNS blocking.

10

Make the choice visible. Keep it reversible.

What I appreciate about Ines's work is that it turns a usually invisible dependency into something people can discuss, configure and question. You can identify the project, read its documentation, inspect a filtering component and try a bounded change on a device you control.

My recommendation is simple: begin with one device or one browser, keep the previous configuration, choose the failure behaviour deliberately and test the services that matter to you. If you find a reproducible problem, report it constructively through the project's channels. Maintaining a resolver means dealing with real users, changing lists and real-world exceptions.

French digital sovereignty becomes more tangible when it includes usable alternatives and people willing to build them. DotNS is worth discovering for that reason, and because its privacy commitment is something I have been able to examine first-hand. A playful duck can open the conversation. Understanding the solution is what makes the choice worthwhile.