Differences

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

--- networking:dns:unbound:configure_access [2020/12/08 09:41] – [Example to Block YouTube in pfSense] peter
+++ networking:dns:unbound:configure_access [2022/10/08 09:09] (current) – peter
@@ Line 31: / Line 31: @@
   * **refuse** - Polite error reply.
   * **allow** - Recursive ok.
-  * **allow_setrd** - Rrecursive ok, rd bit is forced on.
+  * **allow_setrd** - Recursive ok, rd bit is forced on.
   * **allow_snoop** - Recursive and non-recursive ok.
   * **deny_non_local** - Drop queries unless can be answered from local-data.
@@ Line 44: / Line 44: @@
 The first one is that a DNS server may be used as part of a denial of service attack.
-A common technique is to send queries with spoofed IP addresses to exposed recursive DNS servers, which will send their responses to what they think is the computer that made the query in the first place.  In practice, it means that an attacker can ask the recursive server for a DNS record using a fake IP, and the owner of the IP address that was faked will get the response. This means that an evil entity can force a recursive server to flood a victim with DNS responses and therefore use the server as a proxy for a denial of service attack.
+  * A common technique is to send queries with spoofed IP addresses to exposed recursive DNS servers, which will send their responses to what they think is the computer that made the query in the first place.
+  * In practice, it means that an attacker can ask the recursive server for a DNS record using a fake IP, and the owner of the IP address that was faked will get the response.
+  * This means that an evil entity can force a recursive server to flood a victim with DNS responses and therefore use the server as a proxy for a denial of service attack.
-Another reason is that a local DNS server might contain sensitive DNS entries that are not intended to be known by outsiders.  If you are using a local zone for naming local resources, such as printers, cameras, and NAS servers, it is better to have that information protected from outsiders.
+Another reason is that a local DNS server might contain sensitive DNS entries that are not intended to be known by outsiders.
-In addition to the Unbound configuration presented here, it is a good idea to block access to your DNS server by using appropriate firewall rules. DNS servers listen for queries at port 53 and may support both UDP and TCP.
+  * If you are using a local zone for naming local resources, such as printers, cameras, and NAS servers, it is better to have that information protected from outsiders.
+In addition to the Unbound configuration presented here, it is a good idea to block access to your DNS server by using appropriate firewall rules.
+  * DNS servers listen for queries at port 53 and may support both UDP and TCP.
 The **access-control** directives are self-explanatory.
@@ Line 58: / Line 64: @@
 ===== Tag access-control =====
-Tag **access-control** with a list of tags. (in "" with spaces between).
+Tag **access-control** with a list of tags (in "" with spaces between).
 Clients using this access control element use localzones that are tagged with one of these tags.
@@ Line 98: / Line 104: @@
 ----
-===== Example to Block YouTube in pfSense =====
+===== References =====
-<code>
+https://blog.nlnetlabs.nl/client-based-filtering-in-unbound/
-# Give pfSense a server: tag so it puts directives in correct place.
-server:
-    # Define a new tag.
-    define-tag: "notube"
-    # Create ann access-control entry.
-    access-control: 10.1.1.6/32 allow
-    # Tag the access.
-    # Allocate some IP ranges to the tag, repeat for more.
-    access-control-tag: 10.1.1.6/32 "notube"
-    # www.youtube.com is the only way to access youtube site.
-    # All other language domains redirect to www.youtube.com.
-    # You can verify this by the allowed domains in SSL wildcard cert - Certificate Subject Alt Name.
-    # The variants like -nocookie edu and yt.be don't serve content.
-    # The CNAME records for local caches and redirects don't serve content.
-    # The cert is set HSTS (strict) so won't serve on incorrect redirects.
-    # The plain http redirects everything to the https SSL.
-    # Going to myriad IP addresses redirects to google search page.
-    # So with local DNS control, you have tight control of access to youtube.
-    # This of course doesn't exclude proxies & tunnels, but these require more effort & privileges on clients.
-    # Create the local-zone, and allow normal service which allows non-blocked users access and allow all types like A and AAAA and CNAME.
-    local-zone: www.youtube.com typetransparent
-    # Tag the domain.
-    local-zone-tag: www.youtube.com notube
-    # Ensure local data served first.
-    access-control-tag-action: 10.1.1.6/32 "notube" redirect
-    # Send users to your polite internal block page.
-    access-control-tag-data: 10.1.1.6/32 "notube" "A 10.4.1.34"
-</code>