Wiki

User Tools

Site Tools

Trace:
pfsense:install_pfsense:dns_configuration

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pfsense:install_pfsense:dns_configuration [2021/02/01 11:34] – [Advanced Privacy Options] peterpfsense:install_pfsense:dns_configuration [2022/10/20 09:05] (current) – [Advanced Privacy Options] peter
Line 20: Line 20:
   * Outgoing Network Interfaces:  **WAN**.   * Outgoing Network Interfaces:  **WAN**.
  
-<WRAP center round todo 60%> +<WRAP info>Default is actually **ALL**.
-Default is actually ALL.  Check if changing to WAN stops anything.  What is the diff etc. +
-</WRAP>+
  
 +  * By default the DNS Resolver utilizes all interfaces for outbound queries so it will source the query from whichever interface and IP address is closest to the target server from a routing perspective.
 +    * Selecting specific interfaces will limit the choices to only specific interfaces that may be used as a source of queries.
 +
 +  * Controls which interfaces the firewall will utilize when sending its own queries to other DNS servers.
 +    * Can be set for instance to a VPN interface to to prevent DNS leaks.
 +    * Or by deselecting the WAN interface to force pfSense to use a local DNS server, like pihole.
 +    * Or only select localhost if pfSense is running a BIND DNS server.
 +
 +</WRAP>
  
   * System Domain Local Zone Type:  **Transparent**.  Static is an alternative option to be look at here.   * System Domain Local Zone Type:  **Transparent**.  Static is an alternative option to be look at here.
  
-<WRAP center round todo 60%> +<WRAP info> 
-Default is actually Transparent.  Check what diff using Static makes.+**NOTE:**  The local-zone **type** can be: 
 + 
 +  * **deny** serves local data (if any), else, drops queries. 
 +  * **refuse** serves local data (if any), else, replies with error. 
 +  * **static** serves local data, else, nxdomain or nodata answer. 
 +  * **transparent** gives local data, but resolves normally for other names. 
 +  * **redirect** serves the zone data for any subdomain in the zone. 
 +  * **nodefault** can be used to normally resolve AS112 zones. 
 +  * **typetransparent** resolves normally for other types and other names. 
 +  * **inform** acts like transparent, but logs client IP address. 
 +  * **inform_deny** drops queries and logs client IP address. 
 +  * **inform_redirect** redirects queries and logs client IP address 
 +  * **always_transparent** resolve in that way but ignore local data for that name. 
 +  * **always_refuse** resolve in that way but ignore local data for that name. 
 +  * **always_nxdomain** resolve in that way but ignore local data for that name. 
 +  * **noview** breaks out of that view towards global local-zones. 
 </WRAP> </WRAP>
 +
 +
  
  
Line 37: Line 62:
     * Enable Forwarding Mode:  **Not Checked**.  If Checked, then Unbound will forward all DNS traffic to the upstream DNS-Servers configured in **System -> General Setup** and will not handle these queries itself. This is not wanted.      * Enable Forwarding Mode:  **Not Checked**.  If Checked, then Unbound will forward all DNS traffic to the upstream DNS-Servers configured in **System -> General Setup** and will not handle these queries itself. This is not wanted. 
     * Use SSL/TLS for outgoing DNS Queries to Forwarding Servers: **Not Checked**.     * Use SSL/TLS for outgoing DNS Queries to Forwarding Servers: **Not Checked**.
-  * DHCP Registration:  **Checked**.  Makes sure that you can lookup your local hosts. +  * DHCP Registration:  **Not Checked**.  If checked, makes sure that you can lookup your local hosts.  <WRAP info> 
-  * Static DHCP:  **Checked**.  Makes sure that you can lookup your local hosts; which have static bindings.+**NOTE:**  With this checked results in Unbound restarting every time a DHCP lease is issued, or refreshed. 
 + 
 +This results in DNS caching being cleared.  Not what we want. 
 + 
 +</WRAP> 
 +  * Static DHCP:  **Not Checked**.  If checked, makes sure that you can lookup your local hosts; which have static bindings.  See note above in **DHCP Registration** why this is kept unchecked.
   * OpenVPN Clients:  **Not Checked**.   * OpenVPN Clients:  **Not Checked**.
   * Custom options: <code>   * Custom options: <code>
Line 53: Line 83:
 view: view:
     name: "CLEAR"     name: "CLEAR"
-    view-first: yes+    view-first: no 
 +    include: /var/unbound/host_entries.conf #Host overrides AND DHCP reservations 
 +    include: /var/unbound/dhcpleases_entries.conf #DHCP leases    
 view: view:
     name: "IOT"     name: "IOT"
-    view-first: no +    view-first: yes 
-    local-data: "localdomain. 10800 IN SOA pfsense.localdomain. root.localdomain. 1 3600 1200 604800 10800" +    include: /var/unbound/pfb_dnsbl.*conf
-    include: /var/unbound/pfb_dnsbl.*conf    +
 view: view:
     name: "GUEST"     name: "GUEST"
Line 72: Line 103:
   * The **LAN** view, is the default one handling the LAN, and does include the pfBlockerNG DNSBL checks.   * The **LAN** view, is the default one handling the LAN, and does include the pfBlockerNG DNSBL checks.
   * The **CLEAR** view, does NOT include pfBlockerNG DNSBL checks, i.e. it bypasses these additional checks.   * The **CLEAR** view, does NOT include pfBlockerNG DNSBL checks, i.e. it bypasses these additional checks.
-  * The **IOT** view uses the local-data for DNS queries.  It includes pfBlockerNG DNSBL checks.  It also does not use the Global zone for data queries. <WRAP important> +    *  The **view-first: no** means it also does not use the Global zone for data queries. <WRAP important> 
-**WARNING:**  With the **view-first: no**, it might result in some devices, such as mobile phones, taking a long time (~30s) to connect to the this network at first.+**WARNING:**  With the **view-first: no**, it might result in some devices, such as mobile phones, taking a long time (~30s) to connect to the network at first.
  
 You should consider whether to allow this to be changed to **view-first: yes**. You should consider whether to allow this to be changed to **view-first: yes**.
 </WRAP> </WRAP>
 +  * The **IOT** view does include the pfBlockerNG DNSBL checks.
   * The **GUEST** view includes pfBlockerNG DNSBL checks.   * The **GUEST** view includes pfBlockerNG DNSBL checks.
  
Line 93: Line 124:
  
 ---- ----
 +
 +==== Using local-data ====
 +
 +An option that could be configured is to use local-data for DNS queries. For example: <code>
 +view:
 +    name: "IOT"
 +    view-first: no
 +    local-data: "localdomain. 10800 IN SOA pfsense.localdomain. root.localdomain. 1 3600 1200 604800 10800"
 +    include: /var/unbound/pfb_dnsbl.*conf    
 +</code>
  
 The **local-data** parameters declares the DNS Resolver as authoritative for .localdomain.   The **local-data** parameters declares the DNS Resolver as authoritative for .localdomain.  
Line 204: Line 245:
  
   * **Message Cache Size**:  As a rough guide, set this to Memory in GB * 8.  So on a device with 32G memory, this would be set to at least 32*8=256M, but can be set higher on higher memory devices.   * **Message Cache Size**:  As a rough guide, set this to Memory in GB * 8.  So on a device with 32G memory, this would be set to at least 32*8=256M, but can be set higher on higher memory devices.
 +    * Note that the cache memory values are all per thread.  This means that much more memory is used, as every core uses its own cache. Because every core has its own cache, if one gets cache poisoned, the others are not affected.
     * Even though this is increased, not all the space will necessarily be used for caching:     * Even though this is increased, not all the space will necessarily be used for caching:
     * The malloc code in FreeBSD is very good and the actual cache size that is used might be lower most of the time than set here.     * The malloc code in FreeBSD is very good and the actual cache size that is used might be lower most of the time than set here.
-    * Memory fragmentation (the space between allocated memory blocks) will increases slowly, so not all of the cache will actually be used for "proper" caching.+    * Memory fragmentation (the space between allocated memory blocks) will increase slowly, so not all of the cache will actually be used for "proper" caching.
     * Unbound has an internal alloc-check mode that tests memory as well (The Unbound extra memory checks are slow) which will set actual caching usage.     * Unbound has an internal alloc-check mode that tests memory as well (The Unbound extra memory checks are slow) which will set actual caching usage.
  
Line 219: Line 261:
 ---- ----
  
-===== References ===== 
- 
-https://nlnetlabs.nl/documentation/unbound/howto-optimise/ 
 ===== Verify DNS Functionality ===== ===== Verify DNS Functionality =====
  
Line 243: Line 282:
  
 ---- ----
 +
 +===== References =====
 +
 +https://nlnetlabs.nl/documentation/unbound/howto-optimise/
 +
pfsense/install_pfsense/dns_configuration.1612179284.txt.gz · Last modified: 2021/02/01 11:34 by peter
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki