Ajouter pi-hole/unbound/readme.md
This commit is contained in:
270
pi-hole/unbound/readme.md
Normal file
270
pi-hole/unbound/readme.md
Normal file
@@ -0,0 +1,270 @@
|
||||
<h1>unbound</h1>
|
||||
|
||||
<h2 id="pi-hole-as-all-around-dns-solution">Pi-hole as All-Around <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> Solution<a class="headerlink" href="#pi-hole-as-all-around-dns-solution" title="Permanent link">¶</a></h2>
|
||||
<h3 id="the-problem-whom-can-you-trust">The problem: Whom can you trust?<a class="headerlink" href="#the-problem-whom-can-you-trust" title="Permanent link">¶</a></h3>
|
||||
<p>Pi-hole includes a caching and <em>forwarding</em> <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server, now known as <em><abbr title="Pi-hole's Faster Than Light daemon">FTL</abbr></em><abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr>. After applying the blocking lists, it forwards requests made by the clients to configured upstream <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server(s). However, as has been mentioned by several users in the past, this leads to some privacy concerns as it ultimately raises the question: <em>Whom can you trust?</em> Recently, more and more small (and not so small) <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> upstream providers have appeared on the market, advertising free and private <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> service, but how can you know that they keep their promises? Right, you can't.</p>
|
||||
<p>Furthermore, from the point of an attacker, the <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> servers of larger providers are very worthwhile targets, as they only need to poison one <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server, but millions of users might be affected. Instead of your bank's actual <abbr title="Internet protocol address">IP</abbr> address, you could be sent to a phishing site hosted on some island. This scenario has <a href="https://www.zdnet.com/article/dns-cache-poisoning-attacks-exploited-in-the-wild/">already happened</a> and it is likely to happen again...</p>
|
||||
<p>When you operate your own (tiny) recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server, then the likeliness of getting affected by such an attack is greatly reduced.</p>
|
||||
<h3 id="what-is-a-recursive-dns-server">What <em>is</em> a recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server?<a class="headerlink" href="#what-is-a-recursive-dns-server" title="Permanent link">¶</a></h3>
|
||||
<p>The first distinction we have to be aware of is whether a <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server is <em>authoritative</em> or not. If I'm the authoritative server for, e.g., <code>pi-hole.net</code>, then I know which <abbr title="Internet protocol address">IP</abbr> is the correct answer for a query. Recursive name servers, in contrast, resolve any query they receive by consulting the servers authoritative for this query by traversing the domain.
|
||||
Example: We want to resolve <code>pi-hole.net</code>. On behalf of the client, the recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server will traverse the path of the domain across the Internet to deliver the answer to the question.</p>
|
||||
<h3 id="what-does-this-guide-provide">What does this guide provide?<a class="headerlink" href="#what-does-this-guide-provide" title="Permanent link">¶</a></h3>
|
||||
<p>In only a few simple steps, we will describe how to set up your own recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server. It will run on the same device you're already using for your Pi-hole. There are no additional hardware requirements.</p>
|
||||
<p>This guide assumes a fairly recent Debian/Ubuntu-based system and will use the maintainer provided packages for installation to make it an incredibly simple process. It assumes only a very basic knowledge of how <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> works.</p>
|
||||
<p>A <em>standard</em> Pi-hole installation will do it as follows:</p>
|
||||
<ol>
|
||||
<li>Your client asks the Pi-hole <code>Who is pi-hole.net</code>?</li>
|
||||
<li>Your Pi-hole will check its cache and reply if the answer is already known.</li>
|
||||
<li>Your Pi-hole will check the blocking lists and reply if the domain is blocked.</li>
|
||||
<li>Since neither 2. nor 3. is true in our example, the Pi-hole forwards the request to the configured <em>external</em> upstream <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server(s).</li>
|
||||
<li>Upon receiving the answer, your Pi-hole will reply to your client and tell it the answer to its request.</li>
|
||||
<li>Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if <em>any</em> of your clients queries the same domain again.</li>
|
||||
</ol>
|
||||
<p>After you set up your Pi-hole as described in this guide, this procedure changes notably:</p>
|
||||
<ol>
|
||||
<li>Your client asks the Pi-hole <code>Who is pi-hole.net</code>?</li>
|
||||
<li>Your Pi-hole will check its cache and reply if the answer is already known.</li>
|
||||
<li>Your Pi-hole will check the blocking lists and reply if the domain is blocked.</li>
|
||||
<li>Since neither 2. nor 3. is true in our example, the Pi-hole delegates the request to the (local) recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> resolver.</li>
|
||||
<li>Your recursive server will send a query to the <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> root servers: "Who is handling <code>.net</code>?"</li>
|
||||
<li>The root server answers with a referral to the <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr> servers for <code>.net</code>.</li>
|
||||
<li>Your recursive server will send a query to one of the <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr> <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> servers for <code>.net</code>: "Who is handling <code>pi-hole.net</code>?"</li>
|
||||
<li>The <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr> server answers with a referral to the authoritative name servers for <code>pi-hole.net</code>.</li>
|
||||
<li>Your recursive server will send a query to the authoritative name servers: "What is the <abbr title="Internet protocol address">IP</abbr> of <code>pi-hole.net</code>?"</li>
|
||||
<li>The authoritative server will answer with the <abbr title="Internet protocol address">IP</abbr> address of the domain <code>pi-hole.net</code>.</li>
|
||||
<li>Your recursive server will send the reply to your Pi-hole which will, in turn, reply to your client and tell it the answer to its request.</li>
|
||||
<li>Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if <em>any</em> of your clients queries the same domain again.</li>
|
||||
</ol>
|
||||
<p>You can easily imagine even longer chains for subdomains as the query process continues until your recursive resolver reaches the authoritative server for the zone that contains the queried domain name. It is obvious that the methods are very different and the own recursion is more involved than "just" asking some upstream server. This has benefits and drawbacks:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Benefit: Privacy - as you're directly contacting the responsive servers, no server can fully log the exact paths you're going, as e.g. the Google <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> servers will only be asked if you want to visit a Google website, but not if you visit the website of your favorite newspaper, etc.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Drawback: Traversing the path may be slow, especially for the first time you visit a website - while the bigger <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> providers always have answers for commonly used domains in their cache, you will have to traverse the path if you visit a page for the first time. The first request to a formerly unknown <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr> may take up to a second (or even more if you're also using DNSSEC). Subsequent requests to domains under the same <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr> usually complete in <code>< 0.1s</code>.
|
||||
Fortunately, both your Pi-hole as well as your recursive server will be configured for efficient caching to minimize the number of queries that will actually have to be performed.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="setting-up-pi-hole-as-a-recursive-dns-server-solution">Setting up Pi-hole as a recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server solution<a class="headerlink" href="#setting-up-pi-hole-as-a-recursive-dns-server-solution" title="Permanent link">¶</a></h2>
|
||||
<p>We will use <a href="https://github.com/NLnetLabs/unbound"><code>unbound</code></a>, a secure open-source recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server primarily developed by NLnet Labs, VeriSign Inc., Nominet, and Kirei.
|
||||
The first thing you need to do is to install the recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> resolver:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>apt<span class="w"> </span>install<span class="w"> </span>unbound
|
||||
</code></pre></div>
|
||||
<p>If you are installing unbound from a package manager, it should install the <code>root.hints</code> file automatically with the dependency <code>dns-root-data</code>. The root hints will then be automatically updated by your package manager.</p>
|
||||
<p><strong>Optional</strong>: Download the current root hints file (the list of primary root servers which are serving the domain "." - the root domain). Update it roughly every six months. Note that this file changes infrequently. This is only necessary if you are not installing unbound from a package manager. If you do this optional step, you will need to uncomment the <code>root-hints:</code> configuration line in the suggested config file.</p>
|
||||
<div class="highlight"><pre><span></span><code>wget<span class="w"> </span>https://www.internic.net/domain/named.root<span class="w"> </span>-qO-<span class="w"> </span><span class="p">|</span><span class="w"> </span>sudo<span class="w"> </span>tee<span class="w"> </span>/var/lib/unbound/root.hints
|
||||
</code></pre></div>
|
||||
<h3 id="configure-unbound">Configure <code>unbound</code><a class="headerlink" href="#configure-unbound" title="Permanent link">¶</a></h3>
|
||||
<p>Highlights:</p>
|
||||
<ul>
|
||||
<li>Listen only for queries from the local Pi-hole installation (on port 5335)</li>
|
||||
<li>Listen for both <abbr title="User Datagram Protocol (a network communications method for sending messages as datagrams)">UDP</abbr> and <abbr title="Transmission Control Protocol (protocol providing reliable, ordered, and error-checked delivery of data between applications running on hosts communicating via an IP network)">TCP</abbr> requests</li>
|
||||
<li>Verify DNSSEC signatures, discarding BOGUS domains</li>
|
||||
<li>Apply a few security and privacy tricks</li>
|
||||
</ul>
|
||||
<p>(Note that for some Red Hat based distros including CentOS up to v10, the path for the <code>pi-hole.conf</code> file may be <code>/etc/unbound/conf.d/pi-hole.conf</code>)</p>
|
||||
<div class="highlight"><span class="filename">/etc/unbound/unbound.conf.d/pi-hole.conf</span><pre><span></span><code><span class="nt">server</span><span class="p">:</span>
|
||||
<span class="w"> </span><span class="c1"># If no logfile is specified, syslog is used</span>
|
||||
<span class="w"> </span><span class="c1"># logfile: "/var/log/unbound/unbound.log"</span>
|
||||
<span class="w"> </span><span class="nt">verbosity</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">0</span>
|
||||
|
||||
<span class="w"> </span><span class="nt">interface</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">127.0.0.1</span>
|
||||
<span class="w"> </span><span class="nt">port</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">5335</span>
|
||||
<span class="w"> </span><span class="nt">do-ip4</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
<span class="w"> </span><span class="nt">do-udp</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
<span class="w"> </span><span class="nt">do-tcp</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># May be set to no if you don't have IPv6 connectivity</span>
|
||||
<span class="w"> </span><span class="nt">do-ip6</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># You want to leave this to no unless you have *native* IPv6. With 6to4 and</span>
|
||||
<span class="w"> </span><span class="c1"># Terredo tunnels your web browser should favor IPv4 for the same reasons</span>
|
||||
<span class="w"> </span><span class="nt">prefer-ip6</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">no</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Use this only when you downloaded the list of primary root servers!</span>
|
||||
<span class="w"> </span><span class="c1"># If you use the default dns-root-data package, unbound will find it automatically</span>
|
||||
<span class="w"> </span><span class="c1">#root-hints: "/var/lib/unbound/root.hints"</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Trust glue only if it is within the server's authority</span>
|
||||
<span class="w"> </span><span class="nt">harden-glue</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS</span>
|
||||
<span class="w"> </span><span class="nt">harden-dnssec-stripped</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes</span>
|
||||
<span class="w"> </span><span class="c1"># see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details</span>
|
||||
<span class="w"> </span><span class="nt">use-caps-for-id</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">no</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Reduce EDNS reassembly buffer size.</span>
|
||||
<span class="w"> </span><span class="c1"># IP fragmentation is unreliable on the Internet today, and can cause</span>
|
||||
<span class="w"> </span><span class="c1"># transmission failures when large DNS messages are sent via UDP. Even</span>
|
||||
<span class="w"> </span><span class="c1"># when fragmentation does work, it may not be secure; it is theoretically</span>
|
||||
<span class="w"> </span><span class="c1"># possible to spoof parts of a fragmented DNS message, without easy</span>
|
||||
<span class="w"> </span><span class="c1"># detection at the receiving end. Recently, there was an excellent study</span>
|
||||
<span class="w"> </span><span class="c1"># >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<</span>
|
||||
<span class="w"> </span><span class="c1"># by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)</span>
|
||||
<span class="w"> </span><span class="c1"># in collaboration with NLnet Labs explored DNS using real world data from the</span>
|
||||
<span class="w"> </span><span class="c1"># the RIPE Atlas probes and the researchers suggested different values for</span>
|
||||
<span class="w"> </span><span class="c1"># IPv4 and IPv6 and in different scenarios. They advise that servers should</span>
|
||||
<span class="w"> </span><span class="c1"># be configured to limit DNS messages sent over UDP to a size that will not</span>
|
||||
<span class="w"> </span><span class="c1"># trigger fragmentation on typical network links. DNS servers can switch</span>
|
||||
<span class="w"> </span><span class="c1"># from UDP to TCP when a DNS response is too big to fit in this limited</span>
|
||||
<span class="w"> </span><span class="c1"># buffer size. This value has also been suggested in DNS Flag Day 2020.</span>
|
||||
<span class="w"> </span><span class="nt">edns-buffer-size</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1232</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Perform prefetching of close to expired message cache entries</span>
|
||||
<span class="w"> </span><span class="c1"># This only applies to domains that have been frequently queried</span>
|
||||
<span class="w"> </span><span class="nt">prefetch</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.</span>
|
||||
<span class="w"> </span><span class="nt">num-threads</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Ensure kernel buffer is large enough to not lose messages in traffic spikes</span>
|
||||
<span class="w"> </span><span class="nt">so-rcvbuf</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1m</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Ensure privacy of local IP ranges</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">192.168.0.0/16</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">169.254.0.0/16</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">172.16.0.0/12</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">10.0.0.0/8</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">fd00::/8</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">fe80::/10</span>
|
||||
|
||||
<span class="w"> </span><span class="c1"># Ensure no reverse queries to non-public IP ranges (RFC6303 4.2)</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">192.0.2.0/24</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">198.51.100.0/24</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">203.0.113.0/24</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">255.255.255.255/32</span>
|
||||
<span class="w"> </span><span class="nt">private-address</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">2001:db8::/32</span>
|
||||
</code></pre></div>
|
||||
<p>Start your local recursive server and test that it's operational:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>service<span class="w"> </span>unbound<span class="w"> </span>restart
|
||||
dig<span class="w"> </span>pi-hole.net<span class="w"> </span>@127.0.0.1<span class="w"> </span>-p<span class="w"> </span><span class="m">5335</span>
|
||||
</code></pre></div>
|
||||
<p>The first query may be quite slow, but subsequent queries, also to other domains under the same <abbr title="Top-level domain (domains at the highest level in the hierarchical Domain Name System of the Internet., e.g. ".com", ".org", etc.)">TLD</abbr>, should be fairly quick.</p>
|
||||
<h3 id="test-validation">Test validation<a class="headerlink" href="#test-validation" title="Permanent link">¶</a></h3>
|
||||
<p>You can test DNSSEC validation using</p>
|
||||
<div class="highlight"><pre><span></span><code>dig<span class="w"> </span>fail01.dnssec.works<span class="w"> </span>@127.0.0.1<span class="w"> </span>-p<span class="w"> </span><span class="m">5335</span>
|
||||
dig<span class="w"> </span>+ad<span class="w"> </span>dnssec.works<span class="w"> </span>@127.0.0.1<span class="w"> </span>-p<span class="w"> </span><span class="m">5335</span>
|
||||
</code></pre></div>
|
||||
<p>The first command should give a status report of <code>SERVFAIL</code> and no <abbr title="Internet protocol address">IP</abbr> address. The second should give <code>NOERROR</code> plus an <abbr title="Internet protocol address">IP</abbr> address in addition to a <code>ad</code> in the <code>flags:</code> section. The <code>ad</code> signifies (Authentic Data), indicating the <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> response has been authenticated and validated using DNSSEC.</p>
|
||||
<h3 id="configure-pi-hole">Configure Pi-hole<a class="headerlink" href="#configure-pi-hole" title="Permanent link">¶</a></h3>
|
||||
<p>Finally, configure Pi-hole to use your recursive <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server by specifying <code>127.0.0.1#5335</code> in the <strong><em>Settings > <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> > Custom <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> servers</em></strong> section and ensuring that all the other upstream servers are unticked, as shown below:</p>
|
||||
<p><img alt="Upstream DNS Servers Configuration" src="../../../images/RecursiveResolver.png" /></p>
|
||||
<p>Don't forget to click on the <strong><em>Save & Apply</em></strong> button.</p>
|
||||
<h3 id="disable-resolvconfconf-entry-for-unbound-required-for-debian-bullseye-releases">Disable <code>resolvconf.conf</code> entry for <code>unbound</code> (Required for Debian Bullseye+ releases)<a class="headerlink" href="#disable-resolvconfconf-entry-for-unbound-required-for-debian-bullseye-releases" title="Permanent link">¶</a></h3>
|
||||
<p>Debian Bullseye+ releases auto-install a package called <a href="https://wiki.archlinux.org/title/Openresolv"><code>openresolv</code></a> with a certain configuration that will cause unexpected behaviour for pihole and unbound. The effect is that the <code>unbound-resolvconf.service</code> instructs <code>resolvconf</code> to write <code>unbound</code>'s own <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> service at <code>nameserver 127.0.0.1</code> , but without the 5335 port, into the file <code>/etc/resolv.conf</code>. That <code>/etc/resolv.conf</code> file is used by local services/processes to determine <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> servers configured. You need to edit the configuration file and disable the service to work-around the misconfiguration.</p>
|
||||
<h4 id="step-1-disable-the-service">Step 1 - Disable the Service<a class="headerlink" href="#step-1-disable-the-service" title="Permanent link">¶</a></h4>
|
||||
<p>To check if this service is enabled for your distribution, run below one. It will show either <code>active</code> or <code>inactive</code> or it might not even be installed resulting in a <code>could not be found</code> message:</p>
|
||||
<div class="highlight"><pre><span></span><code>systemctl<span class="w"> </span>is-active<span class="w"> </span>unbound-resolvconf.service
|
||||
</code></pre></div>
|
||||
<p>To disable the service, run the statement below:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>systemctl<span class="w"> </span>disable<span class="w"> </span>--now<span class="w"> </span>unbound-resolvconf.service
|
||||
</code></pre></div>
|
||||
<h4 id="step-2-disable-the-file-resolvconf_resolversconf">Step 2 - Disable the file resolvconf_resolvers.conf<a class="headerlink" href="#step-2-disable-the-file-resolvconf_resolversconf" title="Permanent link">¶</a></h4>
|
||||
<p>Disable the file resolvconf_resolvers.conf from being generated when resolvconf is invoked elsewhere.</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>sed<span class="w"> </span>-Ei<span class="w"> </span><span class="s1">'s/^unbound_conf=/#unbound_conf=/'</span><span class="w"> </span>/etc/resolvconf.conf
|
||||
sudo<span class="w"> </span>rm<span class="w"> </span>/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
|
||||
</code></pre></div>
|
||||
<p>Restart <code>unbound</code>.</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>service<span class="w"> </span>unbound<span class="w"> </span>restart
|
||||
</code></pre></div>
|
||||
<h3 id="add-logging-to-unbound">Add logging to unbound<a class="headerlink" href="#add-logging-to-unbound" title="Permanent link">¶</a></h3>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p>It's not recommended to increase verbosity for daily use, as unbound logs a lot. But it might be helpful for debugging purposes.</p>
|
||||
</div>
|
||||
<p>There are five levels of verbosity:</p>
|
||||
<ul>
|
||||
<li>Level 0 means no verbosity, only errors</li>
|
||||
<li>Level 1 gives operational information</li>
|
||||
<li>Level 2 gives detailed operational information</li>
|
||||
<li>Level 3 gives query level information</li>
|
||||
<li>Level 4 gives algorithm level information</li>
|
||||
<li>Level 5 logs client identification for cache misses</li>
|
||||
</ul>
|
||||
<p>First, specify the log file, human-readable timestamps and the verbosity level in the <code>server</code> part of
|
||||
<code>/etc/unbound/unbound.conf.d/pi-hole.conf</code>:</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="nt">server</span><span class="p">:</span>
|
||||
<span class="w"> </span><span class="c1"># If no logfile is specified, syslog is used</span>
|
||||
<span class="w"> </span><span class="nt">logfile</span><span class="p">:</span><span class="w"> </span><span class="s">"/var/log/unbound/unbound.log"</span>
|
||||
<span class="w"> </span><span class="nt">log-time-ascii</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">yes</span>
|
||||
<span class="w"> </span><span class="nt">verbosity</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1</span>
|
||||
</code></pre></div>
|
||||
<p>Second, create log dir and file, set permissions:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>mkdir<span class="w"> </span>-p<span class="w"> </span>/var/log/unbound
|
||||
sudo<span class="w"> </span>touch<span class="w"> </span>/var/log/unbound/unbound.log
|
||||
sudo<span class="w"> </span>chown<span class="w"> </span>unbound<span class="w"> </span>/var/log/unbound/unbound.log
|
||||
</code></pre></div>
|
||||
<p>On modern Debian/Ubuntu-based Linux systems, you'll also have to add an AppArmor exception for this new file so <code>unbound</code> can write into it.</p>
|
||||
<p>Create (or edit if existing) the file <code>/etc/apparmor.d/local/usr.sbin.unbound</code> and append</p>
|
||||
<div class="highlight"><pre><span></span><code>/var/log/unbound/unbound.log rw,
|
||||
</code></pre></div>
|
||||
<p>to the end (make sure this value is the same as above). Then reload AppArmor using</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>apparmor_parser<span class="w"> </span>-r<span class="w"> </span>/etc/apparmor.d/usr.sbin.unbound
|
||||
sudo<span class="w"> </span>service<span class="w"> </span>apparmor<span class="w"> </span>restart
|
||||
</code></pre></div>
|
||||
<p>Lastly, restart unbound:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>service<span class="w"> </span>unbound<span class="w"> </span>restart
|
||||
</code></pre></div>
|
||||
<h3 id="verifying-that-pi-hole-is-querying-unbound-as-its-upstream">Verifying that Pi-hole is querying unbound as its upstream<a class="headerlink" href="#verifying-that-pi-hole-is-querying-unbound-as-its-upstream" title="Permanent link">¶</a></h3>
|
||||
<p>Query a dns using <code>dig</code>:</p>
|
||||
<div class="highlight"><pre><span></span><code>dig<span class="w"> </span>en.wikipedia.org<span class="w"> </span>@127.0.0.1
|
||||
</code></pre></div>
|
||||
<p>Then view Pi-hole's log file, follow a query seeing it sent to and receiving a reply from 127.0.0.1#5335 such as below:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>tail<span class="w"> </span>/var/log/pihole/pihole.log
|
||||
|
||||
Nov<span class="w"> </span><span class="m">24</span><span class="w"> </span><span class="m">11</span>:57:47<span class="w"> </span>dnsmasq<span class="o">[</span><span class="m">973</span><span class="o">]</span>:<span class="w"> </span>query<span class="o">[</span>A<span class="o">]</span><span class="w"> </span>en.wikipedia.org<span class="w"> </span>from<span class="w"> </span><span class="m">127</span>.0.0.1
|
||||
Nov<span class="w"> </span><span class="m">24</span><span class="w"> </span><span class="m">11</span>:57:47<span class="w"> </span>dnsmasq<span class="o">[</span><span class="m">973</span><span class="o">]</span>:<span class="w"> </span>forwarded<span class="w"> </span>en.wikipedia.org<span class="w"> </span>to<span class="w"> </span><span class="m">127</span>.0.0.1#5335
|
||||
Nov<span class="w"> </span><span class="m">24</span><span class="w"> </span><span class="m">11</span>:57:47<span class="w"> </span>dnsmasq<span class="o">[</span><span class="m">973</span><span class="o">]</span>:<span class="w"> </span>reply<span class="w"> </span>en.wikipedia.org<span class="w"> </span>is<span class="w"> </span><CNAME>
|
||||
Nov<span class="w"> </span><span class="m">24</span><span class="w"> </span><span class="m">11</span>:57:47<span class="w"> </span>dnsmasq<span class="o">[</span><span class="m">973</span><span class="o">]</span>:<span class="w"> </span>reply<span class="w"> </span>dyna.wikimedia.org<span class="w"> </span>is<span class="w"> </span><span class="m">103</span>.102.166.224
|
||||
</code></pre></div>
|
||||
<p>If you see the reply to queries from 127.0.0.1#5335, then Pi-hole is using unbound as its upstream.</p>
|
||||
<h3 id="common-issues-troubleshooting">Common Issues & Troubleshooting<a class="headerlink" href="#common-issues-troubleshooting" title="Permanent link">¶</a></h3>
|
||||
<h4 id="fix-so-rcvbuf-warning-in-unbound">Fix <code>so-rcvbuf</code> warning in unbound<a class="headerlink" href="#fix-so-rcvbuf-warning-in-unbound" title="Permanent link">¶</a></h4>
|
||||
<p>The configuration in <code>/etc/unbound/unbound.conf.d/pi-hole.conf</code> sets the <strong>socket receive buffer size</strong> for incoming <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> queries to a higher-than-default value in order to handle high query rates:</p>
|
||||
<div class="highlight"><pre><span></span><code>so-rcvbuf:<span class="w"> </span>1m
|
||||
</code></pre></div>
|
||||
<p>As a result, you may see this warning in unbound logs:</p>
|
||||
<div class="highlight"><pre><span></span><code>so-rcvbuf<span class="w"> </span><span class="m">1048576</span><span class="w"> </span>was<span class="w"> </span>not<span class="w"> </span>granted.<span class="w"> </span>Got<span class="w"> </span><span class="m">425984</span>.<span class="w"> </span>To<span class="w"> </span>fix:<span class="w"> </span>start<span class="w"> </span>with<span class="w"> </span>root<span class="w"> </span>permissions<span class="o">(</span>linux<span class="o">)</span><span class="w"> </span>or<span class="w"> </span>sysctl<span class="w"> </span>bigger<span class="w"> </span>net.core.rmem_max<span class="o">(</span>linux<span class="o">)</span><span class="w"> </span>or<span class="w"> </span>kern.ipc.maxsockbuf<span class="o">(</span>bsd<span class="o">)</span><span class="w"> </span>values.
|
||||
</code></pre></div>
|
||||
<p>To fix it:</p>
|
||||
<ol>
|
||||
<li>
|
||||
<p>Check the current limit. This will show something like <code>net.core.rmem_max = 425984</code>:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>sysctl<span class="w"> </span>net.core.rmem_max
|
||||
</code></pre></div>
|
||||
</li>
|
||||
<li>
|
||||
<p>Temporarily increase the limit to match unbound's request:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>sysctl<span class="w"> </span>-w<span class="w"> </span>net.core.rmem_max<span class="o">=</span><span class="m">1048576</span>
|
||||
</code></pre></div>
|
||||
</li>
|
||||
<li>
|
||||
<p>Make it permanent. Edit <code>/etc/sysctl.d/99-unbound.conf</code> (or on old systems eg Debian ≤ 12 edit <code>/etc/sysctl.conf</code>) and add or edit the line:</p>
|
||||
<div class="highlight"><pre><span></span><code>net.core.rmem_max<span class="o">=</span><span class="m">1048576</span>
|
||||
</code></pre></div>
|
||||
</li>
|
||||
<li>
|
||||
<p>Save and apply:</p>
|
||||
<p>On up to date systems (eg Debian 13)</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>systemctl<span class="w"> </span>restart<span class="w"> </span>systemd-sysctl
|
||||
</code></pre></div>
|
||||
<p>Older systems (eg Debian ≤ 12)</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>sysctl<span class="w"> </span>-p
|
||||
</code></pre></div>
|
||||
</li>
|
||||
<li>
|
||||
<p>Restart unbound:</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>service<span class="w"> </span>unbound<span class="w"> </span>restart
|
||||
</code></pre></div>
|
||||
</li>
|
||||
</ol>
|
||||
<h3 id="uninstall-unbound">Uninstall <code>unbound</code><a class="headerlink" href="#uninstall-unbound" title="Permanent link">¶</a></h3>
|
||||
<p>To remove <code>unbound</code> from your system run</p>
|
||||
<div class="highlight"><pre><span></span><code>sudo<span class="w"> </span>apt<span class="w"> </span>remove<span class="w"> </span>unbound
|
||||
</code></pre></div>
|
||||
<p>Make sure to switch to another upstream <abbr title="Domain Name Service (decentralized naming system for computers, services, or other resources connected to the Internet)">DNS</abbr> server for Pi-hole.</p>
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user