Privacy for DNSvizor
2025-07-03TL;DR: DNSvizor now has improved privacy. We are continuing our work on DNSvizor (repository).
Privacy in DNS
DNS was initially designed as a clear-text protocol, so a passive observer on the wire can read all domains you're resolving. The connection between client and (recursive) resolver can be protected with DNS-over-TLS or DNS-over-HTTPS (as we implemented earlier. But the connection between recursive resolver and authoritative nameserver hasn't been protected. Luckily, there's RFC 9539 suggesting to use opportunistic encryption. Also, there is an RFC for minimizing the query name (RFC 9156).
Several years ago, RFC 9076 about "DNS privacy considerations" was written up. A nice read for everyone interested.
Opportunistic encryption recursive-to-authoritative
We implemented in this PR to attempt opportunisticly to connect to the authoritative nameserver on port 853, which is used for DNS-over-TLS. If that connection fails, we use plain text UDP or TCP transport. If we succeeded earlier to establish a TLS session to that nameserver IP address, we try harder to establish a TLS session again.
Since Let's Encrypt does not yet provide certificates with IP addresses, we chose to not validate the certificate that a server may provide to us. But we try to validate it using the NSS CA certificates as trust anchor; and if that fails we preserve the public key fingerprint for the next connection setup (so we do trust on first use).
Query name minimisation
The RFC 9156 recommends to query, if you want to resolve www.example.com, for the nameservers of .com (instead of the full www.example.com) to the root nameservers (given you have a cold cache). Then, you query for the nameservers of example.com to the nameservers responsible for .com, and so on.
This is great, since it reduces traffic (you send less data in each DNS query); and at the same time improves your privacy.
While working on that, we as well implemented the RFC 8020: if there's a NXDomain for a domain name, all subdomains thereof will be NXDomain as well. This potentially reduces traffic, esp. in combination with query name minimsation.
The implementation was done in two PRs: Qname minimisation and NXDomain.
DNS extended errors
As discussed in our blocklist article, we also implemented RFC 8914, which puts extended errors in the reply, using the EDNS mechanism. We implemented that to tell users of DNSvizor the reason for the resolution failure. Our implementation was done in this PR.
DHCP anonymity profiles
For DHCP, the RFC 7844 specifies anonymity profiles. We tested that DNSvizor is compatible with these.
Conclusion
DNSvizor provides DNS resolution and DHCP service for your network - and now comes with more privacy. It already exists :). Please report issues you encounter and questions you may have. Also, if you use dnsmasq, please show us your configuration.
If you're interested in MirageOS and using it in your domain, don't hesitate to reach out to us (via eMail: team@robur.coop) - we're keen to deploy MirageOS and find more domains where it is useful.
Our work is only partially funded, we cross-fund our work by commercial contracts and public (EU) funding. We are part of a non-profit company, you can make a (in the EU tax-deductible) donation (select "DONATION robur" in the dropdown menu), or sponsor us via the GitHub sponsor button.