Differences

This shows you the differences between two versions of the page.

--- pfsense:stopping_dns_leaks [2020/04/14 15:09] – peter
+++ pfsense:stopping_dns_leaks [2020/11/30 12:07] (current) – removed peter
@@ Line 1: / Line 1: @@
-====== PFSense - Stopping DNS Leaks ======
-Navigate to **Services -> DNS Resolver**
-  * DNS Query Forwarding:  **Not Checked**.
-  * Custom Options:  <code>
-server:
-  # Next line is needed only if pfBlockerNG is being used.
-  include: /var/unbound/pfb_dnsbl.*conf
-  ssl-upstream: yes
-  do-tcp: yes
-  forward-zone:
-    name: "."
-    # Below 4 addresses are Cloudflare DNS.
-    forward-addr: 1.1.1.1@853
-    forward-addr: 1.0.0.1@853
-    forward-addr: 2606:4700:4700::1111@853
-    forward-addr: 2606:4700:4700::1001@853
-</code>
-It’s OK to set the resolver to listen on all interfaces, since the firewall rules on the WAN will prevent Internet hosts from using your resolver anyway.
-<WRAP important>
-**WARNING:**  This will increase latency for DNS lookups due to SSL handshakes.
-However this is only for the first query.  After that the session is reused.
-Reason for this is that CloudFlare's 1.1.1.1 DNS service supports TLS on port 853.  TLS takes longer.
-To prevent this increase in latency, switch to standard port 53, or to an alternative DNS provider that does not use TLS.
-Try other settings as needed, for instance:
-<code>
-server:
-  do-tcp: yes
-  # Speed and privacy
-  minimal-responses: yes
-  prefetch: yes
-  qname-minimisation: yes
-  rrset-roundrobin: yes
-  forward-zone:
-    name: "."
-    # To keep local overrides and avoid slow downs
-    forward-ssl-upstream: yes
-    # Below addresses are Cloudflare DNS
-    forward-addr: 1.1.1.1@853
-    forward-addr: 1.0.0.1@853
-    # forward-addr: 2606:4700:4700::1111@853
-    # forward-addr: 2606:4700:4700::1001@853
-</code>
-Google Chrome was a bit upset at first, but a **<nowiki>chrome://net-internals/#dns</nowiki>** and **clear** fixed it.
-Measured a few lookups with Chrome and the network inspector, and it looks like uncached lookups are taking about 50ms.  Without TLS the lookups run about 10ms.
-</WRAP>
-----
-===== Test =====
-==== Test using an internal DNS: ====
-<code bash>
-dig www.google.com @yourrouter.local
-</code>
-You should see a resolve against your router’s local DNS resolver that works.
-<WRAP info>
-**NOTE:**  You can use use **Diagnostics -> Packet Capture**, and capture port 853 to verify that requests are being triggered.
-</WRAP>
-----
-==== Test using an external DNS ====
-Try and dig something against an IP that you know is not internal and is not a DNS server.  It should work, since the request will be NATted.  Something like;
-<code bash>
-dig www.google.com @8.8.8.8
-</code>
-Assuming that’s all fine, you should now be able to configure a broad block rule to bar all outbound port 53.
-----
-===== Block all outbound non-encrypted DNS =====
-Navigate to **Firewall -> Rules**
-On the **WAN** interface, define a new rule at the top of the list.  This rule should use these settings;
-  * Action: **Block**.
-  * Interface: **WAN**.
-  * Address Family: **IPv4+IPv6**.
-  * Protocol: **TCP/UDP**.
-  * Source: **any**.
-  * Destination: **any**.
-  * Destination Port: **DNS (53)**.
-  * Description: **Block outbound insecure DNS**.
-Verify that you can still resolve against the local resolver (your router’s IP), and that you can still resolve against what seems to be external resolver (e.g, 8.8.8.8).
-You should also check that when you do so that nothing passes on the WAN interface on port 53.
-----
-===== References =====
-https://www.reddit.com/r/PFSENSE/comments/897boi/dns_over_tls_for_1111/