Use our public DNS

Point your device at it.

Three resolvers on the same anycast network everywhere. One answers everything; one refuses ads, trackers and known malware; one adds DNS64 for IPv6-only networks. None keeps a log of what you asked.

The addresses

Unfiltered

Resolves everything, filters nothing.

IPv4177.177.83.83
IPv62602:f3ff:83::83
DoHhttps://dns.yunzheng.space/dns-query
DoT / DoQdns.yunzheng.space

Filtered

Refuses ads, trackers and known malware.

IPv4177.177.83.84
IPv62602:f3ff:83::84
DoHhttps://filter.dns.yunzheng.space/dns-query
DoT / DoQfilter.dns.yunzheng.space

DNS64

No filtering; a name with no IPv6 address is answered with one under 64:ff9b::/96. Only for IPv6-only networks that hand that prefix to a NAT64 gateway.

IPv4177.177.83.64
IPv62602:f3ff:83::64
DoHhttps://dns64.dns.yunzheng.space/dns-query
DoT / DoQdns64.dns.yunzheng.space

Set both the IPv4 and the IPv6 address where the device has both. A device left with one of its two resolvers pointing elsewhere is using that other resolver roughly half the time, which makes filtering look broken and makes any privacy claim meaningless.

Whichever address you set, the device talks to the location nearest to it. The answer comes from that node's cache when it is there, and from the authoritative name servers when it is not.

Windows and macOS

Windows 11: Settings → Network & internet → your connection → DNS server assignment → Edit → Manual. Turn on IPv4 and IPv6, fill in the addresses above, and set DNS over HTTPS to On (automatic template).
macOS: System Settings → Network → your connection → Details → DNS, then add the addresses with +. Remove the ones that were there.

In a Chromium browser you can also set it for the browser alone: Settings → Privacy and security → Security → Use secure DNS → Custom, then paste the DoH URL.

iOS and Android

Android 9 and later has this built in: Settings → Network & internet → Private DNS → Private DNS provider hostname → dns.yunzheng.space (or filter.dns.yunzheng.space to get the filtering). That is DNS over TLS and it applies to the whole device, on Wi-Fi and on mobile data.

iOS and iPadOS need a DNS profile to apply system-wide; without one, only per-Wi-Fi manual DNS is available under Settings → Wi-Fi → (i) → Configure DNS → Manual, and it does not cover mobile data.

Linux and routers

systemd-resolved, with DNS over TLS

# /etc/systemd/resolved.conf.d/orbit.conf
[Resolve]
DNS=177.177.83.83#dns.yunzheng.space 2602:f3ff:83::83#dns.yunzheng.space
DNSOverTLS=yes

Then

sudo systemctl restart systemd-resolved

On a router, set it once in the DHCP settings and every device on the network follows. This is the only way to cover devices that have no DNS setting of their own — printers, televisions, anything embedded.

DNS64, for IPv6-only networks

On a network that has no IPv4 at all, a name that only has an IPv4 address cannot be reached unless something translates. The network's NAT64 gateway does the translating; DNS64 (RFC 6147) does the naming: when a name has no IPv6 address, the DNS64 resolver answers with one under 64:ff9b::/96 that carries the name's IPv4 address, and the gateway turns the connection into IPv4.

Use the DNS64 addresses only on a network whose NAT64 gateway uses the well-known prefix 64:ff9b::/96 — most mobile carriers and IPv6-only ISPs do. On any other network the synthesised addresses connect nowhere. A name that already has an IPv6 address is answered as it is, a query with the CD bit set is never synthesised, and a synthesised answer never carries the authenticated-data flag.

Devices discover the prefix themselves by asking for ipv4only.arpa (RFC 7050), so the reverse lookup and the discovery both work:

dig +short @177.177.83.64 AAAA ipv4only.arpa
# 64:ff9b::c000:aa
# 64:ff9b::c000:ab

dig +short @177.177.83.64 -x 64:ff9b::808:808
# dns.google.

Check it worked

First, that the resolver answers you at all:

dig +short @177.177.83.83 example.com

Then, that your device is actually using it. Ask for a name the filtered resolver refuses. On the filtered address the answer is the resolver's own address — that is the notice page, not the ad server:

dig +short @177.177.83.84 googleads.g.doubleclick.net
# 177.177.83.84   ← refused, answered with the notice page

dig +short googleads.g.doubleclick.net
# 177.177.83.84   ← your device is using the filtered resolver

If the second command returns an ordinary address, your device is still resolving through something else — most often an IPv6 resolver that was left unchanged, or a browser doing its own encrypted DNS.

Questions

Is it free?

Yes, for everyone, with no account. It is run by a non-profit laboratory as a public service.

Do you validate DNSSEC?

Yes. A name whose signatures do not check out is refused with SERVFAIL, and a name we proved genuine comes back with the authenticated-data flag. Unsigned names resolve normally — being unsigned is not a failure, and most of the internet still is. Add <code>+cd</code> to a dig if you are validating yourself and want the raw answer.

Do you run a NAT64 gateway too?

No. DNS64 only names the addresses; the translation is done by the gateway of the network you are on. A public NAT64 gateway would be an open IPv4 relay for the whole internet, which this network does not offer.

Is there a rate limit?

500 queries per second per node, counted per /24 or per /64 rather than per address. Going over it does not block anything: address lookups get a page explaining what happened, and other types get an empty answer. A household or office never comes close.