Unbound Unbound Tuning for gaming

[Jack-Sparr0w]

An Update to setup so far:

neg-cache-size: 16m
val-bogus-ttl: 60
wait-limit-cookie: 10000
wait-limit: 1000
infra-cache-min-rtt: 1000
tcp-idle-timeout: 60000
infra-cache-max-rtt: 120000
max-reuse-tcp-queries: 200 use 300 with VPN
tcp-auth-query-timeout: 3000
pad-responses: yes
pad-responses-block-size: 468 can use 512 with 1500 mtu but (resource intensive)
pad-queries: yes
pad-queries-block-size: 128 can use 512 with 1500 mtu but (very resource intensive)
tls-use-sni: yes Use with VPN or DoT is best
http-max-streams: 100 use 300 with VPN
ip-ratelimit-slabs: 4
ip-ratelimit-size: 16m
ratelimit-slabs: 4
ratelimit-size: 16m
http-query-buffer-size: 16m
http-response-buffer-size: 16m
stream-wait-size: 16m
quic-size: 16m
max-global-quota: 200 is the default, use 300 when a VPN or upstream is used
delay-close: 10000
udp-connect: yes Don't use this if you are using Skynet (It breaks Functionality)

unknown-server-time-limit: 0 use: unbound-control dump_infra in putty without logging into amtm to get value (Example use 1000)
Very useful with any vpn such as NordVPN. helps to get all requests to unbound.

msg-buffer-size: 65552
so-sndbuf: 2
tcp-reuse-timeout: 60000
so-reuseport: yes (amazing feature)
num-queries-per-thread: 100
outgoing-range: 200
ip ratelimit 1000
so rcvbuf 2m
incoming num tcp 950 best for overhead 200 for lower end system
outgoing num tcp 200 best for overhead 75 for lower end system
cache max ttl 14400
# tiny memory cache
key-cache-size: 16m
msg-cache-size: 16m
rrset-cache-size: 32m
infra-cache-numhosts: 40000 AX-88u (aligns with this setup) AC86U- 20000 infra-cache-numhosts
val-sig-skew-min: 3600
val-sig-skew-max: 86400
cache-min-negative-ttl: 0
cache-max-negative-ttl: 3600
serve-expired-client-timeout: 1800 is the default, use 2900 if discard-timeout: 3000 is used to get more hits in the unbound cache
unbound iter-scrub-ns: 20
iter-scrub-cname: 11
max-sent-count: 32

target-fetch-policy: "3 2 1 0 0" is the default, "3 2 1 0 0 0" extends this policy to a maximum depth of five levels. could improve performance for complex DNS chains but also increases the number of queries sent. can also use "-1 -1 -1 -1 -1" or "-1 -1 -1 -1 -1 -1" (Bind 8) Should be combined with/ harden-referral-path: yes This can produce a better hit rate at the cost of performance. Open-Wrt and other routers by default use "2 1 0 0 0 0" helps with DNSSEC validation, query minimization, and performance. "2 1 0 0 0 0" is probably best one to use in a basic setup. Use "0 0 0 0 0 0" With VPN "0 0 0 0 0 0" is close to (Bind 9) as it aligns to best privacy and security. Most VPN providers DNS use (Bind 9). This disables opportunistic prefetching of name server further minimizing metadata leakage.
This setting means Unbound will only fetch the addresses of name servers (targets) on demand, rather than proactively querying them in advance. By minimizing these additional queries, the system reduces the volume of outbound DNS traffic, making it harder for external observers. While the default policy of "3 2 1 0 0 0" involves prefetching to improve latency, it can increase the number of queries, potentially creating more data points that could be correlated with user behavior. Therefore, setting all values to zero limits this potential information leakage, contributing to a more private DNS resolution process.

answer-cookie: yes - (cookie secret must be used)
cookie-secret: a5f6ef87030bd9a99edf17e835086ef9 as (Example) use hex key generator, use with (answer-cookie: yes)
Hex Key Generator- https://www.browserling.com/tools/random-hex
ip-ratelimit-cookie: 10000
val-max-restart: 5

val-nsec3-keysize-iterations: "1024 150 2048 150 4096 150"
jostle-timeout: 200 is the default , Best to use- ( unbound-control dump_infra ) and change it to same number as rtt, most are set to jostle-timeout: 1000 is probably the best setting all around

serve-expired-reply-ttl: 30

root-key-sentinel: yes
trust-anchor-signaling: yes
http-max-streams: 100 use 300 with VPN

discard-timeout: 1900 default setting, use 3000 if jostle timeout is set to 1000 (Example: jostle-timeout: 1000, discard-timeout: 3000)

# no threads and no memory slabs for threads
num-threads: 4 # L&LDv1.03 (Orig 1) RT-AX88U For RT-AC86U use (2)
msg-cache-slabs: 4 # L&LDv1.03 (Orig 2) RT-AX88U For RT-AC86U use (2)
rrset-cache-slabs: 4 # L&LDv1.03 (Orig 2) RT-AX88U For RT-AC86U use (2)
infra-cache-slabs: 4 # L&LDv1.03 (Orig 2) RT-AX88U For RT-AC86U use (2)
key-cache-slabs: 4 # L&LDv1.03 (Orig 2) RT-AX88U For RT-AC86U use (2)

infra-keep-probing: yes
This is a default setting for pfSense, and many other vendors
infra-keep-probing: no with vpn is best privacy
"Look into it and see if it's good for your setup"

infra-host-ttl: 900 works well with infra-keep-probing: yes
infra-keep-probing: no with vpn is best privacy

infra-cache-numhosts: 20000 or 40000 ax 88u

discard-timeout: 1900 is default use 3000 if VPN or DoT is high latency with long timeout.
unwanted-reply-threshold: 5000000 leave to default on lower end system

use (vx) to edit unbound config file (stock settings are slow)

4 core cpu and 1 gig ram

If setting is not needed use:

Example:
hide-trustanchor: no
udp-connect: no


might have to whitelist ASN for Nord Server with this type of setup, to find ASN for given server, go to NordVPN website, copy ip at the top and paste it into search and look for AS number relater to that search. (Ex: AS141039) then use whitelist in Skynet


The setting infra-keep-probing: no is considered best for privacy when using a VPN. This is because infra-keep-probing: yes can potentially leak information about the network infrastructure, and disabling it enhances privacy, especially in conjunction with a VPN.

serve-original-ttl: yes use with vpn

ip-freebind: yes use with VPN or dynamic ISP example (Nord VPN, Spectrum cable internet) Both are dynamic services, with dynamic ip.

Best for VPN and TLS Renegotiation Time (reneg-sec 3600) better unbound hit rate for cache
cache-min-ttl: 3600

 

[Jack-Sparr0w]

zonemd-permissive-mode: yes Best use Nord VPN


Set port=0 in /etc/dnsmasq.conf to avoid conflicts best Used with NordVPN

 

[Jack-Sparr0w]

My config just copy and paste from point to point:


# no threads and no memory slabs for threads
num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
ip-ratelimit-slabs: 4
ratelimit-slabs: 4

# tiny memory cache
extended-statistics: yes # v1.06 Martineau for @juched GUI TAB
key-cache-size: 16m
msg-cache-size: 16m
rrset-cache-size: 32m
ip-ratelimit-size: 16m
ratelimit-size: 16m
http-query-buffer-size: 16m
http-response-buffer-size: 16m
stream-wait-size: 16m
quic-size: 16m
cache-max-ttl: 14400 # v1.08 Martineau
cache-min-ttl: 3600 # v1.08 Martineau
# prefetch
prefetch: yes
prefetch-key: yes
minimal-responses: yes
serve-expired: yes
serve-expired-ttl: 86400 # v1.12 as per @juched
serve-expired-ttl-reset: yes # v1.13 as per @jumpsmm7 Set the TTL of expired records to the serve-expired-ttl value after a failed attempt to retrieve the record from u>
incoming-num-tcp: 950
outgoing-num-tcp: 200
num-queries-per-thread: 100
outgoing-range: 200
ip-ratelimit: 1000 # v1.04 as per @L&LD as it impacts ipleak.net?
edns-buffer-size: 1472 # v1.01 as per @dave14305 minimal config
max-udp-size: 3072 # v1.13 as per @jumpsmm7 mitigate DDOS threats when using dnssec, reduce potential for fragmentation.
#outgoing-port-avoid: 0-32767 # v1.13 as per @jumpsmm7 avoid grabbing udp ports commonly used / only for users with UDP port availability problems
#outgoing-port-permit: 32768-65535 # v1.13 as per @jumpsmm7 ports to permit / Not necessary if port-avoid is not used. limits port randomization.
jostle-timeout: 1000
sock-queue-timeout: 3
infra-cache-numhosts: 40000
discard-timeout: 3000
unwanted-reply-threshold: 5000000
infra-keep-probing: no
infra-host-ttl: 900
so-reuseport: yes
tcp-reuse-timeout: 60000
msg-buffer-size: 65552
max-global-quota: 300
delay-close: 10000
http-max-streams: 300
tls-use-sni: yes
pad-responses: yes
pad-responses-block-size: 512
pad-queries: yes
pad-queries-block-size: 512
val-bogus-ttl: 60
wait-limit-cookie: 10000
wait-limit: 1000
infra-cache-min-rtt: 1000
infra-cache-max-rtt: 120000
tcp-idle-timeout: 60000
max-reuse-tcp-queries: 300
tcp-auth-query-timeout: 3000
unknown-server-time-limit: 1000
neg-cache-size: 16m
val-sig-skew-min: 3600
val-sig-skew-max: 86400
cache-min-negative-ttl: 0
cache-max-negative-ttl: 3600
serve-expired-client-timeout: 2900
iter-scrub-ns: 20
iter-scrub-cname: 11
max-sent-count: 32
answer-cookie: yes
target-fetch-policy: "0 0 0 0 0 0"
cookie-secret: 1b72a4d5dd36d85726316b3e88ac40a7
ip-ratelimit-cookie: 10000
val-max-restart: 5
val-nsec3-keysize-iterations: "1024 150 2048 150 4096 150"
serve-expired-reply-ttl: 30
outbound-msg-retry: 5
serve-original-ttl: yes
max-sent-count: 32
max-query-restarts: 11
ip-freebind: yes
zonemd-permissive-mode: yes

# Ensure kernel buffer is large enough to not lose messages in traffic spikes
#so-rcvbuf: 2m # v1.05 Martineau see DEFAULT /proc/sys/net/core/rmem_default

#so-sndbuf: 2m

#########################################
# Options for integration with TCP/TLS Stubby
# udp-upstream-without-downstream: yes
#########################################

# gentle on recursion
hide-identity: yes
hide-version: yes
do-not-query-localhost: no
qname-minimisation: yes
harden-glue: yes
harden-below-nxdomain: yes
rrset-roundrobin: yes
aggressive-nsec: yes
deny-any: yes
use-caps-for-id: yes
harden-referral-path: yes
harden-algo-downgrade: yes
harden-large-queries: yes
harden-short-bufsize: yes
val-clean-additional: yes
harden-dnssec-stripped: yes
qname-minimisation-strict: yes
harden-unverified-glue: yes
hide-http-user-agent: yes

# Self jail Unbound with user "nobody" to /var/lib/unbound
username: "nobody"
directory: "/opt/var/lib/unbound"
chroot: "/opt/var/lib/unbound"

# The pid file
pidfile: "/opt/var/run/unbound.pid"

# ROOT Server's
root-hints: "/opt/var/lib/unbound/root.hints"

# DNSSEC
auto-trust-anchor-file: "/opt/var/lib/unbound/root.key"
trust-anchor-signaling: yes
root-key-sentinel: yes

 

[dave14305]

edns-buffer-size: 1472 # v1.01 as per @dave14305 minimal config

Since I was tagged from this damn comment in Unbound Manager, you should actually remove this parameter since it's no longer appropriate in 2025. It should run as the newer default value of 1232 after DNS Flag Day 2020.

 

[Jack-Sparr0w]

# do-ip6: yes change to no is probably best if your router has ipv6 disabled

Set:

# do-ip6: no

Best for most VPNs, binded to unbound. If you use unbound and OpenVPN this is the best course

NordVPN does not yet provide full native IPv6 support across its server network. While there are a few IPv6-enabled servers—mostly a small number in the US and UK used for testing—NordVPN generally disables IPv6 traffic to prevent leaks when connected to servers without IPv6 support. The option to enable IPv6 in NordVPN only works if connecting to one of these rare IPv6-capable servers, which are currently very limited.

NordVPN focuses on preventing IPv6 leaks by blocking IPv6 traffic unless the VPN server explicitly supports IPv6. Some users report limited IPv6 functionality via specific servers with the OpenVPN protocol, but comprehensive IPv6 support and native native IPv6 addresses on most servers are not yet available.

Overall, NordVPN prioritizes IPv4 use and robust IPv6 leak protection, but its full-scale IPv6 implementation is still in progress as of 2025.

 

[Jack-Sparr0w]

Since I was tagged from this damn comment in Unbound Manager, you should actually remove this parameter since it's no longer appropriate in 2025. It should run as the newer default value of 1232 after DNS Flag Day 2020.

The difference between Unbound's edns-buffer-size values 1472 and 1232 mainly relates to avoiding IP packet fragmentation and compatibility with network MTU (Maximum Transmission Unit) sizes.

• A buffer size of 1232 bytes is based on IPv6's minimum MTU (1280 bytes) minus header overhead (48 bytes), making it a conservative choice to avoid fragmentation across most networks. This value is recommended by DNS Flag Day 2020 to minimize fragmentation risks, since fragmentation can lead to DNS response issues and security vulnerabilities. While 1232 reduces fragmentation, it may cause more TCP fallback requests if responses exceed this size.
• A buffer size of 1472 bytes is derived from a more common Ethernet MTU of 1500 bytes minus IPv4 and UDP headers, allowing a larger UDP DNS payload. This size optimizes for networks with typical MTUs around 1500, reducing unnecessary TCP fallback yet still mitigating fragmentation. Some configurations use 1472 as the default buffer size for IPv4 to better match typical network environments.

Unbound by default requests a buffer size of 1232 for queries to minimize fragmentation but can retry with a larger size like 1472 for IPv4 after timeouts. Setting the buffer size influences whether DNS responses fit within a single UDP packet without fragmentation, affecting performance and reliability.

In summary, 1232 is a safer, more conservative size maximizing compatibility and fragmentation avoidance, particularly on IPv6 networks or constrained paths, while 1472 is tuned more for typical IPv4 Ethernet networks allowing larger payloads but with a slightly higher fragmentation risk depending on network conditions.

This choice depends on the network environment, with 1232 generally preferred by standards for widest safe compatibility and 1472 used when underlying link MTUs reliably support it.

 

[Jack-Sparr0w]

(# edns-buffer-size: 1232 is already set)


# integration IPV6
#
do-ip6: no
private-address: ::/0 # v1.11 Martineau Enhance 'do-ip6: no' i.e. explicitly drop ALL IPv6 responses
# do-ip6: yes
# edns-buffer-size: 1232 # v1.11 as per @Linux_Chemist https://www.snbforums.com/threads/u...r-unbound-recursive-dns-server.61669/page-151
# interface: ::0
# access-control: ::0/0 refuse
# access-control: ::1 allow
# private-address: fd00::/8
# private-address: fe80::/10

 

[Gary_Dexter]

Please stop with the AI responses.....

 

[Jack-Sparr0w]

Max udp size for vpn and home network

Comparing Unbound's max-udp-size values 1472 vs 3072 involves balancing DNS packet size, network MTU limits, and fragmentation risks:

• 1472 bytes: This value is close to the common IPv4 Ethernet MTU of 1500 bytes minus IP/UDP headers (20 + 8 bytes). It fits into a single UDP packet on most IPv4 networks without fragmentation. This size is safe and recommended to reduce packet fragmentation risks, which can cause packet loss or DNS failures. It aligns with best practice recommendations like RFC 9715 and DNS Flag Day 2020 guidelines. It also avoids excessive fallback to TCP on typical networks.
• 3072 bytes: This is a larger UDP payload size allowing Unbound to handle bigger DNS UDP responses (such as DNSSEC-signed responses) over UDP without truncation. This can improve performance by reducing TCP fallback for large responses. However, packets this large often exceed the typical MTU of most networks, increasing the risk of IP fragmentation and potential packet loss over the internet or VPN tunnels, where MTUs are smaller due to encapsulation.

Choosing between 1472 and 3072 depends on network environment. For typical home or VPN networks, 1472 is safer and widely adopted. For controlled, high-MTU environments or certain enterprise setups where fragmentation is not an issue, 3072 can improve DNS response efficiency for large DNS records.

 

[Gary_Dexter]

Any chance this thread can be locked/closed now?

 

[Jack-Sparr0w]

Any chance this thread can be locked/closed now?

might be better for you to look at another thread if this one dose not suit your taste, I mean this thread so far has 6k views. So I mean it must be helping. my other post has 3k views.

 

[Gary_Dexter]

It's not helping, as it Unbound/DNS has not effect on gaming and tuning it makes no difference to ones gaming experience.

 

[ColinTaylor]

Please stop with the AI responses.....

Any chance this thread can be locked/closed now?

Agreed.

This thread is not helping anyone. It's just page, after page, after page of meaningless walls of text. Parts of which are just copy and paste of other posts from five years ago. Many (most?) of the parameters are just the default values anyway.

There's no explanation of what changes were made from one post to the next, or why they were changed. There's no context given as to which parameters are appropriate in which circumstances. And then there's added AI slop, again without context.

I mean this thread so far has 6k views. So I mean it must be helping. my other post has 3k views.

Page views mean nothing. How many likes have your parameter posts in this thread got. I count zero.

Again, none of this has any benefit to "gaming".

 

[Jack-Sparr0w]

Looking into VPN setup and unbound, would this be better with a VPN bind?

For IPv4 UDP max packet size related to VPN and Unbound DNS, key points are:

• The standard Ethernet MTU is 1500 bytes. Subtracting the IPv4 header (20 bytes) and UDP header (8 bytes) leaves 1472 bytes as the max UDP payload size without fragmentation over typical networks.
• VPN adds extra encapsulation overhead (tunneling headers), reducing the effective MTU underneath the VPN. This means that the maximum safe UDP payload size to avoid fragmentation may be lower than 1472, often around 1400 bytes.
• Unbound DNS settings often use a max UDP size around 1400-1472 bytes when running over VPN, balancing between sending larger DNS packets and minimizing fragmentation risks that can cause packet loss or timeouts.
• Keeping UDP packet sizes below or near 1400 bytes on VPN connections improves reliability by preventing IP fragmentation within the VPN tunnel, which some networks or devices may mishandle.
• If UDP size exceeds the VPN's effective MTU, packets may fragment, leading to DNS failures or retries due to lost fragments.

Overall, the best practice for Unbound operating over IPv4 VPN is to set max UDP packet size around 1400-1472 bytes, respecting VPN overhead to ensure stable, efficient DNS resolution.
This allows Unbound to send DNS responses effectively without excessive fragmentation or performance degradation over VPN connections.

Just wondering?

 

[Jack-Sparr0w]

I mean 1400 is what I'm leaning on

 

[dave14305]

It’s best to ignore the AI slop and the one posting it:

https://www.snbforums.com/members/jack-sparr0w.90235/ignore

 

[jacklul]

I mean 1400 is what I'm leaning on

1232 is the recommended value.
The optimizations you aim for are only worth it if you expect to serve thousands+ of clients per minute.

The AI replies you keep posting are worthless, next time you prompt the AI you should ask for exact sources of each information, including links.
If the AI is not able to give you that then the information it outputted is not to be trusted.

 

[Jack-Sparr0w]

Most requests sent over ipv4 are 1400 mtu, It's also the perfect setting for open vpn with encapsulation

(My own words)

 

[Jack-Sparr0w]

1472 to 1400 is best option for ipv4

 

[Jack-Sparr0w]

line 83: IPV6 section is # edns-buffer-size: 1232

line 119: which is part of ipv4 is edns-buffer-size: 1472

Router mtu is 1500