I usually customize the unbound configuration file. But it would be interesting to have it done on the web interface.
auth-zone:
name: "."
url: "https://www.internic.net/domain/root.zone"
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: root.zoneAs you said, you are customising it. By definition that cannot really be easily done on the web UI. Editing configuration files is not an option.
If you think that your change might be helpful to other people, why not try to upstream it?
I understand the difficulties. Yes, I will propose suggestions. I’m not a programmer. But with little knowledge, I will contribute.
Cache lifetime is reduced, ensuring security in queries. Option to speed up the cache response and prefetch.
cache-max-ttl: 21600
cache-min-ttl: 5
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 3600Under no circumstances you want to serve expired responses or cache longer or shorter than the authoritative zone would.
on zones : https://www.internic.net/domain/root.zone
172800 IN A
86400 IN DS
cache-max-ttl: 172800
cache-min-ttl: 0
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 172800
If I understood your knowledge, would that be the option?
Hi,
those parameters already are set in our current configuration:
prefetch: yes
prefetch-key: yes
As Michael pointed out already, it does not make sense to tamper with TTLs as the zone operators set them on purpose. Serving expired data can cause unexpected behaviour which is undebuggable in most cases.
Hyperlocal (fetching root zone and similar ones) makes sense to me, but we have some users sitting behind internet connections with extremley low bandwith and would need to make this configurable.
I agree. Excellent explanation.
I noticed that ipfire’s unbound.conf omits options.
cache-max-ttl and cache-min-ttl and others.
For what reason?
I am trying to block cname ads using stub-zone.
I need the option
do-not-query-localhost: no
I noticed that they don’t use
# RFC1918 private IP address - Protects against DNS Rebinding
private-address:
Sorry for the excess of questions.
Hi,
For what reason?
For the reason I mentioned in my previous post: If the operator of a zone decides to set extremely low or high TTLs, he/she usually has a good reason to do so. A resolver should not interfere at this point.
Please read the current configuration carefully:
# Import any local configurations
include: "/etc/unbound/local.d/*.conf"
You are free to include any Unbound configuration statements in that directory. Thanks for mentioning private-address, I will have a look at this.
I agree.
Well, from what I notice, the unbound project is modular, its configuration will depend on the operating environment. Any custom configuration can be negative. I learned a lot from your explanations.
I am enjoying these settings.
server:
# RFC1918 private IP address - Protects against DNS Rebinding
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 169.254.0.0/16
private-address: 192.168.0.0/16
harden-dnssec-stripped: yes
do-not-query-localhost: no
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
num-threads: 2
outgoing-num-tcp: 10
incoming-num-tcp: 10
so-reuseport: yes
include: “/etc/unbound/adblock/adservers.zone”
Are you creating a custom .conf file in /etc/unbound/local.d/ with these custom options, or are you directly modifying unbound.conf for these customized settings?
creating a custom .conf file in /etc/unbound/local.d/ with these custom options,
Thanks for confirming 
I am using the following with a custom file in /etc/unbound/local.d/
I realize some of these settings may be redundant and/or not recommended by the IPFire developers but, I found the DNS over TLS very slow with the default settings out of the box in IPFire. In my case, IPFire was only using a single thread and the Unbound statistics showed very low cache hit rate. With these adjustments I’m seeing much higher cache hit rates and web surfing feels a lot faster.
Also one more note, I’m using Quad9 for my DNS over TLS provider. They seem very aggressive at closing the connection once the DNS lookup completes. With a single thread for Unbound, this means I was frequently running in to issues with DNS burst lookups, because the connection would be closed before the single thread could open a new connection back to Quad9. Adding 4 threads helps this quite a bit.
Here’s the config I’m using:
server:
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
jostle-timeout: 200
infra-host-ttl: 900
infra-cache-numhosts: 10000
outgoing-num-tcp: 20
incoming-num-tcp: 20
edns-buffer-size: 1432
cache-max-ttl: 86400
cache-min-ttl: 900
harden-dnssec-stripped: no
msg-cache-size: 250m
rrset-cache-size: 500m
qname-minimisation: yes
qname-minimisation-strict: yes
num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
prefetch: yes
prefetch-key: yes
use-caps-for-id: no
serve-expired: yes
so-reuseport: yes
do-not-query-localhost: no
statistics-interval: 21600
statistics-cumulative: yes
# DNS Rebinding
# For DNS Rebinding prevention
private-address: 127.0.0.0/8
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 169.254.0.0/16
private-address: 192.168.0.0/16DoT I prefer it like this:
Working unbound over TLS server; self-hosted. Does NOT answer UDP or unencrypted requests.
Hi,
unfortunately, the DNS rebinding configuration cannot be enabled as a default for all IPFire installations, as it presumes resolved resources not to be located in internal networks. If somebody is using IPFire for segmenting his/her/its internal network, this will cause trouble.
Perhaps we could integrate this as an opt-in feature, but this would mean another switch at the DNS settings page, and we have too many there already (“less knobbiness”).
Thanks, and best regards,
Peter MĂĽller
I agree. It’s a problem.
I am new to the IPFire project. A doubt: there is the main unbound file, but the change is not allowed. With the customized options in the local.d folder changes are possible. An example:
the prefetch: yes option is in the main file. If I add prefetch: no, will this value change?
Yes, it appears that any customization we set will over-ride the “default” options that are already listed in the unbound.conf file.
An example:
SSH as root to your IPFire host and create a file /etc/unbound/local.d/my_custom_settings.conf
Edit the file, and place the following inside:
prefetch: no
Restart unbound to load the new settings:
/etc/init.d/unbound restart
Run the following command to check if prefetch is now set to “no”:
unbound-control get_option prefetch
You should see output like this:
[root@ipfire local.d]# unbound-control get_option prefetch
`no`
This validates that the custom settings are being loaded on the service startup/restart. In this case, we can also verify that our custom setting overrides the “default” settings chosen for IPFire.
A word of caution, I test these on a LAB VM with IPFire first. I would not recommend doing this in production as you will disrupt DNS services briefly when stopping/starting Unbound.
That was the doubt. As for breaking the system, I don’t worry, I’m used to it, I fix it. I appreciate your clarification.