Warda-DNSDocs
EN
Menu

Settings and system

Everything a household needs is in the web interface, for the administrators:

  • Time zone (Settings): the hours of Internet, the reports and the nightly tasks follow the time of the box; in a container it is often UTC. The zone chosen in the interface (PUT /api/v1/time-zone {"zone": "Europe/Paris"}, "" for the system one) applies from the restart that follows, and the dashboard warns when the box and the browser are not on the same time.

  • Settings: learning (level, suggestions per week, your own domains), resolvers (Quad9 then Cloudflare, one of them, or your own), local network (zones sent to the box, address of http://warda) and journal (days kept, largest size). They are kept in the database and applied when Warda restarts; a setting given in /etc/default/warda (or a flag) keeps priority and is shown as fixed. The administration log records only the names of the settings changed (changed: custom_upstreams, journal_days), never their values: a value may carry an account or a token (the path of a DNS over HTTPS upstream).

  • System: updates (with Docker, the daily check of new versions), backups, the terms of use and the anonymous statistics (see Terms of use and anonymous statistics), the maintenance actions below, restart of Warda, restart or power off of the box (Debian package: warda-system.path and warda-system.service, root, carry out the request of the service; the password of the account is asked again, the API token and the warda commands do not need it), and a diagnostic to download and send when something goes wrong: state, versions, settings, last warnings and errors, without any name asked by the devices, any name of the household (own domains and local zones are only counted) nor any secret: every address, in the settings as in the messages of the warnings and errors, keeps its scheme and host only (https://lists.example/…).

Maintenance (System, POST /api/v1/maintenance/{action}, administrators; each action is confirmed, written to the administration log with what it removed, and one runs at a time):

  • resolver — Restart the DNS resolver, without restarting Warda: empties the cache of the answers and starts the upstream servers again as new (their failures and waits forgotten, the connections kept open over DNS over TLS and HTTPS closed); what they did since the start and whether they validate DNSSEC are kept.
  • network — Empty the network table: forgets the machines found by the network scan and their announcements (names, models, the equipment heard with LLDP and CDP) and the local names made for them; the devices of the household, their person or group and the names the family gave them stay. The next scan fills the table again.
  • logs — Empty the logs: deletes the query journal and the live view (5 minutes); the statistics, the reports, the settings and the administration log stay.

Emptying asks the password of the account again (confirm_password), restarting the resolver does not; the API token does not need it. There is no warda command for them.

Terms of use and anonymous statistics#

The installation begins with the terms of use (version 2026-09-27, TermsVersion in internal/admin/terms.go; full text at https://warda-dns.com/<language>/terms/): a summary (free software under the AGPLv3, provided without warranty, what the box sends to the Internet, French law) and a box to tick. What the box sends to the Internet, all of it:

  • the names asked by the devices, to the upstream DNS servers (Quad9 and Cloudflare by default), encrypted when they allow it, and the DNSSEC checks of these servers;
  • the download of the lists (warda-lists, see Lists);
  • the check of the new versions and the download of the signed updates (see Updates);
  • the time, set by the system of the box;
  • the monthly country database (DB-IP);
  • the school holidays of the region chosen (OpenHolidays);
  • the check of a new password against known leaks (Have I Been Pwned, k-anonymity: only the first 5 characters of the SHA-1 hash; off with WARDA_PASSWORD_BREACH_CHECK=false);
  • when chosen, the online service warda-cloud (registration of the name of the encrypted DNS, the challenges of its certificate), the certificate authority (Let's Encrypt by default) and the API of a DNS provider when one is set (Cloudflare, OVHcloud);
  • the anonymous daily statistics below. POST /api/v1/setup refuses an installation without "accept_terms": true and "terms_version": "2026-09-27"; it takes "telemetry": false to turn the statistics off at once. The choice of the statistics is recorded first, then the acceptance; an acceptance that cannot be recorded answers 500 (the accounts are made: sign in and accept on the System page). The version accepted, its time and its account are kept (terms_version, terms_accepted_at, terms_accepted_by of the database, shown on the System page, GET /api/v1/terms) and go with the backups; a backup made before the terms keeps the acceptance of the box, and one without a choice of the statistics (telemetry, on or off) keeps the choice of the box. A box installed before the terms, or new terms, show a banner to the administrators until one of them accepts them on the System page (POST /api/v1/terms {"accept": true, "version": "2026-09-27"}).

Once the terms are accepted, Warda sends once a day, unless turned off (System, PUT /api/v1/telemetry {"enabled": false}, and at the installation), exactly this to WARDA_CLOUD_URL + /v1/telemetry (POST, User-Agent: Warda/<version>):

json
{"id": "5f0c…(32 hexadecimal digits, random, drawn anew for each daily signal)", "version": "1.2.0", "install": "deb", "country": "FR", "arch": "arm64"}

id is random, drawn anew for each daily signal and never kept: the service counts an installation once within a UTC day with it, and nothing links two days, the accounts, the subscription nor the identifier of the installation; install is docker in a container (/.dockerenv, /run/.containerenv), pi on the Raspberry Pi image (/etc/systemd/system/warda-os-updates.service), deb with the Debian package, else archive; country is the country chosen in Warda (the identifier of the installation), empty when unknown; arch is amd64, arm64, arm or other. It counts the installations, their versions and countries. The first send comes 1 to 60 minutes after the start, or after an administrator accepts the terms (at the installation or from the banner) while the statistics are on, the next ones every 24 hours give or take an hour; 15 seconds at most, never retried (a failure waits for the next day, logged at the debug level only). GET /api/v1/telemetry shows what is sent. The history, the names asked, the devices and anything of the network are never sent.

The units watch /var/lib/warda: with another data directory, restarting or powering off the box from the interface and the "Check now" of updates wait for the timer or do not work. A restored backup brings its settings back, including the local zones and the address of http://warda: check them after moving to another network.