Skip to content
TESTING

[00] Resolver · dns.joindns4.in

Hello, in eleven Indian languages and English.

Encrypted DNS,
resolved in India,
logged nowhere

Your device asks where every site lives. By default your ISP hears all of it. Point one setting at us and those questions travel sealed, resolve inside India, and are never written down.

Set it up on your device →What it blocks
$ dig +dnssec  @dns.joindns4.in

;; SERVER:     dns.joindns4.in#853 (nearest)
;; STATUS:     querying…
Try

Edit the domain to look anything up. Every line is decoded from a real response.

[01] What it blocks, and what it never keeps

Blocks ads, trackers, malware and phishing

680,000+ domains, from HaGeZi Pro and Threat Intelligence Feeds, refreshed every 24 hours. A blocked name returns NXDOMAIN, so your device simply never connects.

Check it yourself

dig ads.doubleclick.net @dns.joindns4.in

Nothing is logged

No query logs, no IP logs, no timestamps, no device fingerprints, no per-user analytics. There is no retention period because there is nothing retained.

Operator attestation — you cannot verify this from outside

Answers are cryptographically checked

DNSSEC is validated on every signed zone, so a forged or poisoned answer is refused rather than passed to you. A domain with broken signatures fails closed.

Check it yourself

dig +dnssec cloudflare.com @dns.joindns4.in

The question travels encrypted

DNS-over-TLS on port 853 and DNS-over-HTTPS on port 443, both TLS 1.3. Your ISP can see that you contacted us; it cannot see what you asked.

Check it yourself

openssl s_client -connect dns.joindns4.in:853

QNAME minimisation

Upstream servers are told only the part of the name they need to answer, not the whole thing. RFC 7816.

Check it yourself

dig +short txt qnamemintest.internet.nl

No EDNS Client Subnet

Your IP subnet is never forwarded to authoritative nameservers, so they cannot infer your location from our queries.

Check it yourself

dig google.com +subnet=1.2.3.4/24 @dns.joindns4.in

RAM only

Resolution happens entirely in memory. Nothing is written to disk, and a restart takes every trace with it.

Operator attestation — you cannot verify this from outside

Serves stale rather than failing

If an upstream authority goes dark, a slightly expired answer is served instead of an error. RFC 8767.

Operator attestation — you cannot verify this from outside

  • RPZ-based filteringStandards-compliant response policy zones, NXDOMAIN action
  • Extended DNS errorsRFC 8914 — you are told why something failed
  • Daily blocklist refreshAutomated, every 24 hours
  • Aggressive NSEC cachingFewer upstream queries, faster negative answers
  • TCP and IPv6 transportBoth supported end to end

[02] Conformance

StandardTitleHow we implement it
RFC 7858DNS over TLSPort 853, TLS 1.3
RFC 8484DNS over HTTPSPort 443, HTTP/2
RFC 4034DNSSEC resource recordsValidated on every signed zone
RFC 4035DNSSEC protocolFails closed on bad signatures
RFC 7816QNAME minimisationStandard mode
RFC 8767Serving stale dataSurvives upstream outages
RFC 8914Extended DNS errorsReasons, not just failures
GDPRPrivacy compliantNot an RFC — a regulation we hold ourselves to

Conformance is self-asserted. Independent check: test.joindns4.in

[03] Why bother

Resolution stays in India

Your queries are answered inside the country, on infrastructure we operate, rather than travelling to a datacentre on another continent and back.

A threat found once is blocked everywhere

Blocklists and threat feeds are applied identically at every point of presence, so something caught in one region does not have to be rediscovered in another.

Privacy by construction, not by policy

There is no logging to switch off and no retention window to trust, because resolution happens in memory and nothing is written down in the first place.

Answered from the nearest point of presence

The hostname routes you to whichever of our 2 locations is closest, so you are not paying latency for the privilege of privacy.

Set it up on your device →One setting. About forty seconds.

[04] Set it up on your device

One setting, on whichever device you are reading this on. Copy a hostname, paste it in, done.

Encrypted endpoints

Use these wherever you can. The hostname routes you to the nearest server automatically, so there is nothing to choose.

DNS-over-TLS · port 853
dns.joindns4.in
DNS-over-HTTPS · port 443
https://dns.joindns4.in/dns-query

Server addresses

Delhi NCR · del

Windows, Linux and routers need an address rather than a hostname. Pair it with the encrypted settings in the tabs below — on its own, port 53 is not encrypted.

Choose which server location to show addresses for
IPv4
139.84.174.9
IPv6
2401:c080:3400:29e1:5400:5ff:fee0:fab4

Android Setup

Private DNS (DNS-over-TLS)

  1. 1. Open Settings
  2. 2. Go to Network & Internet
  3. 3. Tap Private DNS
  4. 4. Select Private DNS provider hostname
  5. 5. Enter: dns.joindns4.in
  6. 6. Tap Save

Available on Android 9 (Pie) and later. No address needed — the hostname handles routing.

Did it work?

Once you have saved the setting, check it here. We look up a one-off name and see which resolver asks for it.

Looking0/10

[05] Where we run

POPCityLive sinceIPv4 · 24 hIPv6 · 24 h
blrBangalore2025-10-2099.7%99.5%
delDelhi NCR2026-01-1699.6%99.4%
ccuKolkataplanned——

Uptime over the last 24 hours, read from our status page · as of

  1. Done

    Alpha launch

    Diwali. Core resolution, DNSSEC validation and both encrypted transports, from Bangalore.

  2. Done

    Delhi NCR

    A second point of presence for the capital region, with geoproximity routing across both.

  3. Planned

    Kolkata

    A third location, extending coverage east and adding redundancy if either existing site is lost.