DNS resolver registry · DNS.WATCH

DNS.WATCH DNS servers

DNS.WATCH offers one service, reachable over DNS (53), DoH. Every address and endpoint below is taken from the operator's documentation; the behaviour is what we measured on 2026-09-24.
84.200.69.80
primary address
4
addresses in 1 variant
Validates
DNSSEC in our test
None sent
client subnet (ECS)

Addresses

DNS.WATCH DNS addresses by variant

Set the IPv4 or IPv6 addresses as your DNS servers, or use an encrypted endpoint where one is listed.

DNS.WATCH

Not specified by the operator

IPv4
84.200.69.80
84.200.70.40
IPv6
2001:1608:10:25::1c04:b12f
2001:1608:10:25::9249:d69b
DoH
https://resolver2.dns.watch/dns-query

Measured

What we observed

Measured 2026-09-24 from one vantage point, three rounds per address, majority result. Anycast resolvers can behave differently from other networks. How we test

DNSSEC validation Validates

Returned SERVFAIL for dnssec-failed.org, rhybar.cz and badsig.go.dnscheck.tools on every address that answered, while resolving example.com.

Client subnet (ECS)

No client subnet reached the authoritative server from any address we probed.

Plain DNS and NXDOMAIN

2/2 documented IPv4 addresses answered on port 53. Random non-existent names came back as NXDOMAIN, so errors are not rewritten into ads or search pages.

Encrypted endpoints

  • DoH https://resolver2.dns.watch/dns-queryNo answer

Networks

Which networks carry it

The announcing network comes from RIPEstat routing data for each documented address. The query network is where the resolver sent its own lookups during our probe, which a DNS leak test reports.

Announcing the service addresses

  • AS44066 DE-FIRSTCOLO firstcolo GmbH

Queried from, in our probe

  • AS44066 DE-FIRSTCOLO firstcolo GmbH

In the operator's words

Operator statements

Quoted from the operator's pages and checked word for word. We have not audited these practices.
“No Logging, DNSSEC enabled”
dns.watch

Check it

Confirm your device is using DNS.WATCH

Changing a DNS setting does not guarantee your lookups reach that resolver: a VPN, a browser's own secure DNS or a proxy can send them elsewhere. Our DNS leak test shows which resolvers actually received your queries.

From a terminal

# Which address did the resolver query from?
dig +short whoami.akamai.net @84.200.69.80

# Does it pass your subnet on (ECS)?
dig +short TXT o-o.myaddr.l.google.com @84.200.69.80

# Does it validate DNSSEC? SERVFAIL means yes
dig dnssec-failed.org @84.200.69.80

Behind a proxy

With an HTTP proxy, or a client set to socks5h://, the proxy side resolves hostnames, so your own resolver setting does not apply to that traffic. With socks5:// in curl or Python requests, your device resolves names first. The SOCKS5 vs SOCKS5h guide shows how to check which one you have.

Questions

DNS.WATCH questions

What are DNS.WATCH's DNS server addresses?

DNS.WATCH: 84.200.69.80, 84.200.70.40, 2001:1608:10:25::1c04:b12f, 2001:1608:10:25::9249:d69b.

Does DNS.WATCH validate DNSSEC?

Yes. On 2026-09-24 every DNS.WATCH address that answered returned SERVFAIL for three deliberately mis-signed domains while resolving ordinary names.

Does DNS.WATCH support DNS over HTTPS or DNS over TLS?

DoH: https://resolver2.dns.watch/dns-query. 0 of 1 answered our test query on 2026-09-24.

Does DNS.WATCH send my IP subnet to other servers (ECS)?

We observed no client subnet on any address we probed.

How can I check that I am using DNS.WATCH?

Run a DNS leak test and compare the network it reports with the one DNS.WATCH queried from in our probe (AS44066). On the command line, dig +short whoami.akamai.net @84.200.69.80 returns the address the resolver used to query Akamai.

Sources

Sources and dates

Documentation checked 2026-09-24. Measured 2026-09-24. Registry reviewed 2026-09-24.