How to check for DNS leaks and WebRTC leaks: 6-step diagnosis and solution by cause

What does a DNS query reveal?

DNS queries contain domain names. Page content or entered values ​​are not included. DNS is the Internet's address book system that converts domain names read by humans into IP addresses used by computers. Every time you type an address into your browser or an app contacts a server, your device first asks the DNS server 'what is the address of this name?' So, just by looking at the query history, you can tell a lot about when and which service you tried to access.

Traditional DNS queries go to UDP port 53 unencrypted. To compensate for this, DoH (RFC 8484), which wraps queries in HTTPS, and DoT (RFC 7858), which wraps queries in TLS, were created. However, even if you use encrypted DNS, the server name (SNI) sent when connecting to a site via HTTPS may be visible on the network if the site and browser do not support ECH (Encrypted Client Hello).

Secure DNS (DoH) and VPN have different purposes. DoH only encrypts DNS queries; the site access itself and the IPs the site sees remain the same. A VPN encrypts the entire communication between your device or browser and the VPN server and changes the IP that sites see. Incognito mode doesn't stop leaks either. Incognito mode is a function that does not leave history or cookies on the device, and does not change DNS queries or WebRTC routes.

How does WebRTC determine an IP address?

WebRTC finds its own address in several ways to connect two devices through the shortest path and passes the results to the script on the web page. WebRTC is a web standard technology that allows you to make video calls, voice calls, and file transfers without plugins in your browser. The process of gathering addresses is called ICE (RFC 8445). Even pages that don't make video calls can start this process with a script.

The problem is the STUN query in step 3. Browser proxies forward web requests, but WebRTC's UDP communications do not go through the proxy in browser default settings. So the address provided by the STUN server is not the proxy server, but my original public IP. Things are different with device-wide VPNs. Since all UDP communication, including STUN requests, goes to the tunnel, the address seen by the STUN server is also the VPN server's IP.

Chrome has a 'WebRTC IP handling policy' that determines which address WebRTC will use, and extensions can change this value. Each value corresponds to four methods outlined in the IETF's WebRTC IP Address Handling Recommendation (RFC 8828).

Solution: How to check and fix by cause

Most leaks have one of eight causes: This is usually caused by overlapping settings. Start by checking the cause number pointed out in the diagnosis table, and each time you fix one, repeat step 6 in the picture above to see if the result has changed. If you change several settings at once, you won't know what worked.

How do StageVPN apps and StageVPN for Chrome stop leaks?

The StageVPN app reduces leakage by tunneling all communication, while StageVPN for Chrome proxies name lookups and adjusts WebRTC policies. Since the scope of protection is different, the way it is handled is also different.

StageVPN does not guide you through a separate DNS leak protection settings menu as a feature of its offerings. The above behavior is dependent on the app's default VPN configuration and the extension's connection method. The scope of provision is Features and Scope of OfferingYou can check it here.

No leaks mean that queries and communications go through the VPN path instead of the carrier. This does not mean that no records will be kept. StageVPN retains access records for 93 days in accordance with the Communications Secrets Protection Act and does not record communication content. The item is Access record storage noticeWell, the reason I'm revealing it is Why are we disclosing our access record retention policy?explained.

Re-check checklist: What do you re-check after making changes?

Each time you fix one cause, check the items below again from the beginning. If all passes, there is no leak. If any item fails, it returns to the corresponding cause card.

• After disconnecting and reconnecting the VPN, I checked whether the app showed connection completion or the expansion icon showed ON.
• On the IP verification page, you'll either see the VPN server address for both IPv4 and IPv6, or you won't see IPv6.
• The DNS test does not show the DNS server of the telecommunication company or router.
• The srflx candidate in chrome://webrtc-internals does not have the original public IP.
• Network features of other VPN apps, proxies/VPN extensions, and security programs are turned off.
• If you have set Manual DNS or Secure DNS for your device and browser, you have verified that this is the intended setting.
• Your operating system, browser, and StageVPN apps and extensions are up to date.
• Same result even after switching between Wi-Fi and mobile data and restarting the browser.
• If you need to protect programs outside of Chrome, you can use a device-wide VPN rather than an extension.

It is also a good idea to determine when re-inspection is necessary. That's after a major update to your operating system or browser, after installing a new extension or security app, or before doing any sensitive work on a network you're connecting to for the first time. If the settings are the same but the results have changed, one of these three things is usually the cause. Once you get the hang of it, the 6 stages of diagnosis can be completed in just a few minutes.

If the problem persists, organize the device model, operating system and app version, time of occurrence, and test results. customer supportPlease contact us. Please do not send your password or verification code. The device settings to be checked along with checking for leaks are: 10 smartphone privacy settingsWell, there are risks that cannot be solved with just a VPN. What VPNs Prevent and Can't PreventWell, your habits on public networks are Public Wi-Fi Safety RulesI organized it in .