Resolver online

DoT & DoH DNS Resolver

stun00-ru.zxcv.best operates a recursive DNS resolver that accepts queries over DNS-over-TLS (RFC 7858) and DNS-over-HTTPS (RFC 8484). Plain UDP/53 is not exposed — transport-layer encryption is required by the service configuration. DNSSEC validation is enabled for all signed zones.

TLS transport

Query transport satisfies TLS 1.3 requirements as specified by RFC 7858 and RFC 8484. Both GET and POST wire-format requests are accepted.

In-memory resolution

Query processing is handled in-memory. Records are cached per their TTL as defined by RFC 1035 §7.1 and evicted on expiry.

DNSSEC validation

Responses for signed zones are validated against the root trust anchor. Bogus answers are returned as SERVFAIL rather than forwarded to the client.

Low latency

The resolver is co-located with the upstream root and TLD cache, with a warm-cache median response under 15 ms for common destinations.

IPv4 & IPv6

Dual-stack endpoints are advertised. AAAA records are returned untouched — no Happy-Eyeballs interference, no synthetic A records.

Standards only

Strict conformance to RFC 7858 (DoT), RFC 8484 (DoH), and RFC 8310 (authentication profiles). No proprietary protocols, no client agent required.

Resolver endpoints

DoH (RFC 8484)
https://stun00-ru.zxcv.best/dns-query
DoT (RFC 7858)
tls://stun00-ru.zxcv.best:853
Methods
HTTPS GET and POST · application/dns-message
TLS
TLS 1.3 only · ECDSA P-256 · HSTS enabled
Plaintext
UDP/53 and TCP/53 are not exposed. TLS transport is required.

Frequently asked

What is DNS-over-TLS / DNS-over-HTTPS?

DoT (RFC 7858) and DoH (RFC 8484) are IETF standards that carry DNS queries inside a TLS session. The wire format is identical to classic DNS; only the transport layer differs. This allows standard DNS tooling to interoperate with compliant resolvers over an authenticated, encrypted channel.

What record types are supported?

All standard types are supported: A, AAAA, MX, CNAME, TXT, SRV, NS, PTR, SOA, CAA, and NAPTR. DNSSEC-related types — DNSKEY, DS, RRSIG, NSEC, and NSEC3 — are passed through and validated where applicable.

How does DNSSEC validation work?

The resolver performs full chain-of-trust validation from the root zone downwards. If a signed zone returns a response that fails signature verification, the resolver returns SERVFAIL to the client instead of the unverified answer.

Which clients are supported?

Any client that implements RFC 7858 or RFC 8484. This includes Android 9+ (Secure DNS setting), iOS 14+ (DNS configuration profile), macOS 11+, recent Windows 11 builds, Firefox, Chrome, systemd-resolved, and stubby/knot-resolver.

Is there an SLA?

No. This is a personal/community resolver provided on a best-effort basis. There are no uptime guarantees and no commercial support. If you need a contractual SLA, use a commercial provider.