Unbound - DNS Cache Poisoning

General
1

Currently using the RPI with Pi-hole as an All-Around DNS Solution.
For setting up a recursive server i'm using the folling link:

Do have some questions about how unbound is configured.
When reading the config on the following web-site i've noticed the following setting:

https://freedif.org/unbound-your-own-dns-server

# Add an unwanted reply threshold to clean the cache and avoid when possible a DNS Poisoning

unwanted-reply-threshold: 10000

For those who want more info about DNS Poisoning (copy paste from Calomel.org):

Poisoning a DNS resolver refers to the act of inserting fake, often malicious data into the resolvers cache. This can cause website visitors to be redirected from the site (e.g. their banking site) they thought to visit to a different web site, for example a phishing site.

Is DnsSpoof also considered cache poisoning? In fact, it is. The difference is that poisoning is the act of inserting bad data maliciously and dnsspoof'ing is inserting averting data we know about. It is a fine line differentiation depending on who is querying the data.

Unbound implements a number of methods to add random bits to secure queries against malicious deflection. The most important means to add randomness is to vary the port numbers from which the question is asked, another means is to use a hack that randomizes unused bits in the query name. Unbound uses 16 bits for the port randomization. To be precise, about 60000 random ports, avoiding ports below 1024 and avoiding IANA allocated UDP ports to avoid system instability of the server. The port randomization uses the same random number generator as the ID. Unbound takes care that a randomly drawn port is used for one query. Thus every query gets a freshly random port number.

Real protection, where you are not subject to the whims of chance, is achieved by using DNSSEC. DNSSEC uses digital signatures to protect the data. With DNSSEC there is no chance of poisoning, independent of the number of random bits used. Unbound implements the DNSSEC standard as specified in the RFCs ( RFC4034, RFC4035 ). Unbound can act as a validator and can thus check the digital signatures attached in replies. Of course, the domain name owner must have inserted these digital signatures in the first place. In the absence of DNSSEC, unbound attempts to provide very good security. Without digital signatures, randomization and filtering are currently the only options.

So would it be recommended to add the following line to unbound config (/etc/unbound/unbound.conf.d/pi-hole.conf):

unwanted-reply-threshold: 10000

3

As noted by @anon55913113, this setting is not consistent with the recommendations of the unbound configuration documentation.

My recommendation - use the settings recommended by the Pi-Hole setup guide.

4

Did google for some (recommended) unbound configurations and found the following site:

Did find the following tekst:

unwanted-reply-threshold: 

          If set, a total number of unwanted replies is kept track  of  in
          every thread.  When it reaches the threshold, a defensive action
          is taken and a warning is printed to  the  log.   The  defensive
          action  is  to  clear  the  rrset  and message caches, hopefully
          flushing away any poison.  A value of 10 million  is  suggested.
          Default is 0 (turned off).

So the default suggested value is 10 million.
But the default value is 0 (turned off).

So i'm not convinced to use the default value in the Pi-Hole setup guide.
Gonna search out more info about the unwanted-reply-threshold value (meanwhile setting this value to 10 million).

5

There is likely a reason that the unbound developers have this turned off by default. Are you expecting that somebody is going to poison the cache on your unbound instance that is invisible to the internet?

Edit:

The default installation of unbound enables DNSSEC, so the answers you get from the authoritative servers are authenticated to be the same as what they sent.

6

So that you have an imagination:

My public is running approx. 4 days since last restart/reload and currently has 1219 unwanted replies.

Ed: Please do not post public DNS addresses.