DNS leaks and WebRTC leaks often appear on the same test page, but they are different.

Both tests can show “another IP.” That address is not automatically the user's original public IP, and it does not automatically mean a VPN failed.

The short answer

Check your IP, WebRTC, and protocol observations

About the Caylet model (1.6.0): Caylet separates confirmed findings, absence from an available source, and no data. Only valid Scamalytics and AbuseIPDB numbers enter the composite. Caylet does not perform a DNS leak test and must not infer one from missing data.

What is DNS?

The Domain Name System translates names such as example.com into addresses that a network can route to. A typical sequence is:

  1. The browser or operating system asks a configured recursive resolver.
  2. The resolver checks its cache.
  3. If necessary, it asks root, top-level-domain, and authoritative servers.
  4. It returns the answer to the client.

The recursive resolver can be run by an ISP, a VPN, a company, a public DNS service, or the browser's encrypted-DNS provider.

What is a DNS leak?

In a VPN context, a DNS leak usually means queries that were expected to follow the VPN's protected DNS path instead reached another resolver—for example, the local ISP's resolver.

That can reveal to the resolver which domain names are requested and can show a destination service that DNS and HTTP traffic appear to follow different networks. It does not necessarily reveal the user's original public IP to the website. The test page may see a resolver IP, not the subscriber.

How does a DNS leak test work?

A test creates unique domain names under a zone it controls. When the browser resolves them, the test's authoritative DNS observes which recursive resolvers ask for those names. It correlates those queries with the current page session.

Multiple resolvers can appear because a provider uses a pool, Anycast sites differ, the browser and operating system use separate resolution paths, corporate filtering adds layers, IPv4 and IPv6 differ, or a cache miss reaches different infrastructure.

What is a recursive resolver?

It resolves names on behalf of clients, follows referrals, caches results, and returns answers. Its IP and location describe DNS infrastructure—not necessarily the end user's address or exact location.

Why can resolver and public-IP countries differ?

1. Public DNS and Anycast

One resolver address can be announced worldwide. GeoIP may label the operator's registration or one node rather than the site that handled the query.

2. Browser DoH

A browser may send encrypted DNS to its selected provider independently of the operating system's resolver.

3. Corporate or school resolution

Organizations can centralize DNS for filtering, malware protection, and internal names.

4. Mobile or roaming networks

DNS and internet egress can use different regional cores.

5. GeoIP error

Resolver infrastructure can also be geolocated inaccurately.

What are DoH and DoT?

DNS over HTTPS sends DNS in HTTPS, commonly over port 443. DNS over TLS sends it in a dedicated TLS channel. Both encrypt DNS between the client and selected resolver, reducing observation or tampering on that segment.

Encrypted DNS is not complete anonymity. The resolver still handles the query, the destination's IP remains needed for connection, and the resolver's later queries can be observed by authoritative infrastructure. Crucially, encrypted DNS does not prove that its traffic follows the VPN tunnel.

Why can DNS leak while a VPN is active?

The correct fix depends on the cause; a foreign resolver label alone is not enough.

Does EDNS Client Subnet expose the user's IP?

EDNS Client Subnet (ECS) lets a resolver include part of a client network prefix when asking authoritative DNS, helping CDNs return geographically suitable answers. It normally sends a truncated prefix rather than a full address, but it can reduce location privacy.

Not every resolver uses ECS, policies vary, and a test should not assume it without evidence. ECS is also different from a browser sending its public IP directly to the website.

What is WebRTC?

Web Real-Time Communication supports audio, video, data channels, and peer connectivity in browsers. Interactive Connectivity Establishment (ICE) gathers possible paths and uses STUN or TURN when direct connectivity is difficult.

ICE candidate types

Host candidate

An address from a local interface. It may be private IPv4, local IPv6, or a browser-protected mDNS hostname. It describes local connectivity, not necessarily a public egress.

Server-reflexive candidate

STUN reports the public address and port seen after NAT. This is the candidate most likely to reveal an additional public path.

Relay candidate

Traffic goes through a TURN relay. The peer sees the relay candidate rather than a direct host path.

What is a WebRTC leak?

The term usually means that a site obtains an additional address through ICE that the user expected a VPN or privacy tool to conceal. A strong case is an internet-routable IPv4 or IPv6 on a different ISP or country from the HTTP egress.

A local private address is a smaller privacy signal, not proof that the original public IP was revealed. Modern browser protections may replace local addresses with mDNS or restrict candidate exposure.

Distinguishing address types

Common private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Carrier shared space is 100.64.0.0/10. Loopback includes 127.0.0.0/8. IPv6 has link-local, unique-local, loopback, documentation, and globally routable ranges that must also be classified correctly.

Learn about public, private, IPv4, and IPv6 addresses.

Why can WebRTC show another public IP?

  1. The VPN tunnels IPv4 but not IPv6.
  2. A second network interface remains active.
  3. Split tunneling selects another route.
  4. Browser and VPN integration differs.
  5. Enterprise, virtual desktop, or remote-access architecture adds a path.
  6. The test misclassifies private, shared, documentation, or stale candidates.

Does WebRTC need camera permission?

Not every ICE gathering operation requires camera or microphone access. Real-time media permissions and network candidate discovery are related but distinct browser behaviors. Exact exposure depends on browser version, policy, and how the test is implemented.

How modern browsers reduce exposure

Browsers can use mDNS hostnames, restrict candidate address surfaces, obey proxy policy, limit local-network details, and apply permission or enterprise controls. Consequently, old demonstrations do not always describe current behavior, and an empty result may reflect privacy protection or test limitations.

Core difference between DNS and WebRTC leaks

Question DNS test WebRTC test
Observes Resolver path ICE connectivity candidates
Another IP often belongs to Recursive DNS infrastructure Local interface, NAT egress, or TURN relay
Main concern Queries bypass expected route Another network address/path is exposed
Stronger evidence Unexpected ISP resolver outside VPN policy Additional globally routable address on another path

Four common result states

  1. No additional information observed: the test completed and found no extra resolver/path.
  2. A difference with a reasonable explanation: Anycast DNS, corporate resolution, private candidate, or expected split tunnel.
  3. A high-value inconsistency: another public IP, direct IPv6, or ISP resolver contrary to the expected VPN policy.
  4. Test failed or data is insufficient: never convert this into “no leak.”

Reading a DNS test

Confirm that the displayed IP belongs to a resolver. Review ASN and service name, compare it with the expected VPN or corporate policy, account for Anycast and GeoIP error, and repeat with fresh unique queries to reduce cache effects.

Reading a WebRTC test

Start with candidate type, classify the address, compare public candidates with the HTTP egress, confirm the test completed, and never label a private local IP as “real public IP exposed.”

If a VPN shows another IP, check first

Should WebRTC be disabled?

Not automatically. It powers legitimate calling and real-time applications, and modern browsers already limit some exposure. Confirm a real additional public address first. A correctly configured VPN should address routing across IPv4 and IPv6 rather than relying only on removing a browser feature.

Should DoH be disabled so DNS follows the VPN?

It depends. Keeping DoH can protect DNS on ordinary networks and follow an organization's approved secure resolver. Adjustment may be appropriate when the VPN requires its resolver for internal names, filtering, or policy and browser DoH bypasses that design. Choose one coherent security model rather than assuming DoH is always good or always a leak.

Potential effects

DNS or WebRTC inconsistencies can affect privacy, region inference, corporate policy compliance, confidence that a VPN covers all paths, and false-positive risk. Their severity depends on whether meaningful public information was exposed and to whom.

Does DNS leakage let a website read DNS contents?

The destination website already knows the hostname used to reach it. A test operator controlling authoritative DNS can observe test-domain lookups. An unrelated website cannot simply read every domain requested from a separate resolver. Who operates the resolver and test, and what each party observes, must be distinguished.

How should tools display results?

A DNS section should name resolver IPs, ASN or service, country, expected-path comparison, encrypted-DNS limitations, and test status. A WebRTC section should show candidate type, address classification, ASN/country for public candidates, relation to HTTP egress, and completion status.

Both need explicit detected, not observed, and unavailable states. Caylet currently performs bounded WebRTC observations but does not run a DNS leak test; it must not display or infer a DNS leak conclusion.

Use Caylet to review current IP and WebRTC observations

Common misconceptions

Frequently asked questions

Does a DNS leak mean the site saw my real IP?

Not necessarily. It usually means an unexpected resolver path; the observed IP often belongs to the resolver.

Is 192.168.x.x a real-IP leak?

Usually not. It is private and not globally routable.

Does another public WebRTC IP always mean a VPN leak?

No, but it deserves investigation as direct IPv6, another interface, split tunneling, or alternate-path exposure.

Does a resolver in another country prove leakage?

No. Anycast, DoH, corporate DNS, roaming, and GeoIP error can explain it.

Do DoH and DoT eliminate leaks?

No. They encrypt DNS to a resolver, but routing and resolver choice still determine whether the path matches the VPN policy.

Is disabling WebRTC the only fix?

No. Confirm the exposure and fix protocol routing, split tunneling, or interface configuration as appropriate.

Summary

A DNS leak concerns the resolver path; a WebRTC leak concerns extra ICE addresses and routes. Another IP can be a resolver, private address, carrier-shared address, STUN-observed public egress, or TURN relay. It must be classified before drawing a conclusion.

Compare address type, candidate type, ASN, country, IPv4 and IPv6, browser and VPN behavior, and test completion. “No data” is not “no leak,” and a city mismatch is not proof that a real public IP was exposed.

Primary sources

  1. RFC Editor, RFC 1034, RFC 1035, RFC 7858, RFC 8484, and RFC 7871
  2. RFC Editor, RFC 8445, RFC 8489, RFC 8828, and RFC 8826
  3. MDN Web Docs, RTCIceCandidate documentation
  4. Mozilla Support, Configure DNS over HTTPS protection levels in Firefox

This article provides general networking and privacy education. DNS and WebRTC behavior varies by browser, operating system, VPN, and network. Results do not represent an official third-party platform decision or guarantee anonymity.