Public DNS resolver · DNS.WATCH
DNS.WATCH DNS servers
DNS.WATCH answers on 84.200.69.80 and 84.200.70.40, with DNS over HTTPS at https://resolver2.dns.watch/dns-query. In our 2026-09-24 test it validated DNSSEC and sent no client subnet.
- Addresses
- 4
- Variants
- 1
- Measured
- 2026-09-24
- Operator
- DNS.WATCH
- Primary IPv4
- 84.200.69.80
- All IPv4
- 84.200.69.80, 84.200.70.40
- All IPv6
- 2001:1608:10:25::1c04:b12f, 2001:1608:10:25::9249:d69b
- DNS over HTTPS
- https://resolver2.dns.watch/dns-query
- DNS over TLS
- not documented
- Service variants
- 1 (DNS.WATCH)
- DNSSEC in our test
- Validates
- Client subnet (ECS)
- None sent
- Protocols
- DNS (53), DoH
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.
| Variant | Filtering (operator description) | IPv4 | IPv6 | Encrypted |
|---|---|---|---|---|
| DNS.WATCH | Not specified by the operator | 84.200.69.8084.200.70.40 | 2001:1608:10:25::1c04:b12f2001:1608:10:25::9249:d69b | DoH https://resolver2.dns.watch/dns-query |
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.
- 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.
| Protocol | Endpoint | Our test query |
|---|---|---|
| DoH | https://resolver2.dns.watch/dns-query | No answer |
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.
| ASN | Holder | Role |
|---|---|---|
| AS44066 | DE-FIRSTCOLO firstcolo GmbH | Announces the service addresses |
| AS44066 | DE-FIRSTCOLO firstcolo GmbH | Queried from, in our probe |
Operator statements
Quoted from the operator's pages and checked word for word. We have not audited these practices.
“No Logging, DNSSEC enabled”
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.
# 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.80Behind 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.
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
Documentation checked 2026-09-24. Measured 2026-09-24. Registry reviewed 2026-09-24.
Addresses and endpoints come from each operator's documentation; behaviour is what we measured from one location on 2026-09-24. Speed, uptime and how well a filter blocks what it promises were not tested.