Unbound Resolver low cache hits

[andrema2]

Hi

I have my pfsense in the latest version 2.4.5p1. I used to have a pihole and point it to unbound, but I decided to use pfBlockerNG instead, so I change the configuration of unbound resolver to not forward queries as well.

I have a feeling that something is not working as it should and I'm trying to see if the cache is used.

From time to time I'm running: unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total.num

The total number of queries seems low and so does the cache hits. This is the result of the command above

total.num.queries=1184
total.num.queries_ip_ratelimited=0
total.num.cachehits=269
total.num.cachemiss=915
total.num.prefetch=113
total.num.expired=111
total.num.recursivereplies=952

Is as the system just restarted the service, which is not the case. I looked in the log and I couldn't find a restart.

This is my conf file

##########################
# Unbound Configuration
##########################

##
# Server configuration
##
server:

chroot: /var/unbound
username: "unbound"
directory: "/var/unbound"
pidfile: "/var/run/unbound.pid"
use-syslog: yes
port: 53
verbosity: 2
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "validator iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512
jostle-timeout: 200
infra-host-ttl: 900
infra-cache-numhosts: 20000
outgoing-num-tcp: 10
incoming-num-tcp: 10
edns-buffer-size: 4096
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: no
msg-cache-size: 10m
rrset-cache-size: 20m

num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
outgoing-range: 4096
#so-rcvbuf: 4m
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: yes
use-caps-for-id: no
serve-expired: yes
# Statistics
# Unbound Statistics
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes

# TLS Configuration
tls-cert-bundle: "/etc/ssl/cert.pem"

# Interface IP(s) to bind to
interface-automatic: yes
interface: 0.0.0.0
interface: ::0

# Outgoing interfaces to be used

# DNS Rebinding
# For DNS Rebinding prevention
private-address: 127.0.0.0/8
private-address: 10.0.0.0/8
private-address: ::ffff:a00:0/104
private-address: 172.16.0.0/12
private-address: ::ffff:ac10:0/108
private-address: 169.254.0.0/16
private-address: ::ffff:a9fe:0/112
private-address: 192.168.0.0/16
private-address: ::ffff:c0a8:0/112
private-address: fd00::/8
private-address: fe80::/10


# Access lists
include: /var/unbound/access_lists.conf

# Static host entries
include: /var/unbound/host_entries.conf

# dhcp lease entries
include: /var/unbound/dhcpleases_entries.conf



# Domain overrides
include: /var/unbound/domainoverrides.conf


# Unbound custom options
server:
private-domain: "plex.direct"
server:include: /var/unbound/pfb_dnsbl.*conf


###
# Remote Control Config
###
include: /var/unbound/remotecontrol.conf

How can I make it better ? Is there a configuration that is wrong ?

Is there a way to have a graphic view of the unbound dns performance ? I tried to use zabbix, but it's not getting the data.

Thanks

[andrema2]

I'm seeing some recurrent restarts of the unbound service.

I have DHCP static and dynamic clients to register in the DNS.

I have also the pfBlockerNG working.

Is it a problem ?

[andrema2]

More information.

So I keep doing unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total.num from time to time.

I could see it going from 700 queries to 21 without a restart on the service. Something is forcing a reset.

[andrema2]

I uninstall pfBlockerNG, but I still see the cache being constantly refreshed.

Is it just me ?

[bmeeks]

@andrema2 said in Unbound Resolver low cache hits:

I uninstall pfBlockerNG, but I still see the cache being constantly refreshed.

Is it just me ?

This is most likely why your cache is reloading due to Unbound restarts --

@andrema2 said in Unbound Resolver low cache hits:

I'm seeing some recurrent restarts of the unbound service.

I have DHCP static and dynamic clients to register in the DNS.

Each time a DHCP client renews its lease or grabs a new one, the Unbound service will be restarted. That will flush out the cache.

Unfortunately, with the current combination of dhcpd and unbound on pfSense, you can't enable the options of automatically registering DHCP clients in DNS without suffering this restart penalty.

There is also some difference of opinion here on the forum about the utility of such a setting (automatically registering DHCP cilents in DNS). I happen to be in the camp that believes this is many times a necessary thing (or at least definitely a needed convenience). Others say you should either use static IP addressing or MAC reservations in DHCP along with hard-coded DNS entries for those hosts. For a small home network, I guess the other camp has a point. But for larger enterprise networks or offices it is handy to be able to refer to client devices (PCs mostly) by some intelligent DNS name and not have to consult IP lookup sheets. Consider a Help Desk setup where the support person needs to connect to a Windows machine via RDP to help out an employee. Much easier to use computer names in that scenario as opposed to trying to walk an employee through getting the IP address for you.

[andrema2]

I'm at the same side you are.

Let's hope someone can pick this issue and somehow solve it.

Thanks anyway

[bmeeks]

@andrema2 said in Unbound Resolver low cache hits:

I'm at the same side you are.

Let's hope someone can pick this issue and somehow solve it.

Thanks anyway

Yep! I worked for many years in Information Technology at a large US Fortune 500 company. We were a Windows shop, so we didn't have the unbound issue. We named our employee desktop machines with the login ID of the assigned employee and a number tacked onto the end. That made it easy for the Help Desk to find a machine for RDP connections. You asked the employee their login ID and then you had their machine name. For shared computers, we had a slightly different naming scheme.