You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Portmaster takes care of protecting your DNS queries by becoming the gateway for all DNS queries on your system and then sending them through an encrypted connection to the configured DNS server.
If you are using a DNS server for your network that has a dashboard, or if the DNS service you are using discerns between encrypted and non-encrypted queries, you might notice that sometimes Portmaster sends unencrypted queries.
In order to understand why that is necessary, let's take a look at a common network structure: A free WiFi access point in a café or airport. Usually these can only be used when you accept their Terms of Service. In order for you to get you to read them, the network needs to somehow redirect to that.
This needs to work even if the secure DNS server are unreachable - as you've not yet "logged into" the free network.
This is why Portmaster always sends a handful of special domains - used by operating systems and browsers - as plain DNS queries to the DNS server provided by the network. You can find the current list of these domains in the docs or in the source code as "Connectivity Domains").
If you don't want these queries to go out, you can block them by enabling the setting Ignore System/Network Servers or Use Secure Protocols Only. Please consider the side effects of enabling these settings when you do so.
The Portmaster will also attempt to detect these "Captive Portals" and will notify you if it finds one.
For the time being there is also another possibility why this can happen. To make sure everything works as expected, we enabled Portmaster to fall back to the system assigned DNS servers in case all the configured DNS server failed. This is to ensure that we don't break the workflow when installing Portmaster.
We are working on a solution how to best handle this in a way that does not break setups and provides the best privacy. This is internally tracked at CC#2405.
Keywords: unencrypted query, DNS leaks, not sent, DHCP, system assigned.
Categories: Leaks
The text was updated successfully, but these errors were encountered:
Portmaster takes care of protecting your DNS queries by becoming the gateway for all DNS queries on your system and then sending them through an encrypted connection to the configured DNS server.
If you are using a DNS server for your network that has a dashboard, or if the DNS service you are using discerns between encrypted and non-encrypted queries, you might notice that sometimes Portmaster sends unencrypted queries.
In order to understand why that is necessary, let's take a look at a common network structure: A free WiFi access point in a café or airport. Usually these can only be used when you accept their Terms of Service. In order for you to get you to read them, the network needs to somehow redirect to that.
This needs to work even if the secure DNS server are unreachable - as you've not yet "logged into" the free network.
This is why Portmaster always sends a handful of special domains - used by operating systems and browsers - as plain DNS queries to the DNS server provided by the network. You can find the current list of these domains in the docs or in the source code as "Connectivity Domains").
If you don't want these queries to go out, you can block them by enabling the setting Ignore System/Network Servers or Use Secure Protocols Only. Please consider the side effects of enabling these settings when you do so.
The Portmaster will also attempt to detect these "Captive Portals" and will notify you if it finds one.
For the time being there is also another possibility why this can happen. To make sure everything works as expected, we enabled Portmaster to fall back to the system assigned DNS servers in case all the configured DNS server failed. This is to ensure that we don't break the workflow when installing Portmaster.
We are working on a solution how to best handle this in a way that does not break setups and provides the best privacy. This is internally tracked at CC#2405.
Keywords: unencrypted query, DNS leaks, not sent, DHCP, system assigned.
Categories: Leaks
The text was updated successfully, but these errors were encountered: