IPv6, unbound, dns flag day and MSS restrictions

[planetf1]

I have had some trouble with various sites & my ISP
 - many networks discard fragmented IPv6 packets
 - my ISP appears to be blocking ALL icmp responses for things like packet too big. (confirmed with isp router as well as opnsense - nothing coming in on a tcpdump :-( )

The consequence is black holes! I hate this.... !!

As a consequence I've now configured my RA to force a MSS of 1240 (Link MTU 1280), and I also have a normalization rule (for all ipv6 tcp) to set the mss to 1220. This seems to address client issues

However I notice that unbound does have an issue:

root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core # drill . DNSKEY @2001:4860:4860::8888
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10473
;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; .    IN      DNSKEY

;; ANSWER SECTION:

;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:

;; Query time: 3 msec                                                                                                                         ;; SERVER: 2001:4860:4860::8888
;; WHEN: Sun Feb  8 17:52:17 2026
;; MSG SIZE  rcvd: 17

;; WARNING: The answer packet was truncated; you might want to                                                                                ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core #

This would be because opnsense itself will still be using the regular mtu (1500) ...

unbound will work with:

root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core # drill -b 1232 . DNSKEY @2001:4860:4860::8888                      ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 65176
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0                                                                         ;; QUESTION SECTION:
;; .    IN      DNSKEY
;; ANSWER SECTION:                                                                                                                            .       56179   IN      DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
.       56179   IN      DNSKEY  256 3 8 AwEAAbNTVC2+pry4pc37pZI9Oj6b8FHxT3VGrvSPKLE1Tjyfe2kUZUtVX5xrv6AV4BVO+ygrYjGZMNgEnbLU4zknnlnhI2e0g6iTza1aZh0dRZXGH16C1NUNq1CxBkUhIYQhQDeIOtLacx+RmFTc+hSHJJ2MJ79IS00kA7eKi6mofQ7SPJmdJVjI+JAx791y0f5QaB+iHGANU53FwiYXNUQjfAzCrtOaSevGsx8SO8BTaXLAjFq5eewOtwScVwfVDhEXlvpE6e+mIncwhNKaMRD9IPuHENqCNPI5MjxfAMVS6cEY8eEozIkv/vHc+0Auu3n+Fcx6F2Js4KPXaHEShAXugfU= ;{id = 21831 (zsk), size = 2048b}    .       56179   IN      DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ;{id = 38696 (ksk), size = 2048b}

    ;; AUTHORITY SECTION:

                                                                                                                         ;; ADDITIONAL SECTION:

                                                                                                                        ;; Query time: 5 msec
;; EDNS: version 0; flags: ; udp: 512                                                                                                         ;; SERVER: 2001:4860:4860::8888
;; WHEN: Sun Feb  8 17:52:41 2026                                                                                                             ;; MSG SIZE  rcvd: 853
root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core #

So I thought I should set
edns-buffer-size: 1232
msg-buffer-size: 8192

but had trouble figuring out how to inject these values. Eventually for a test I just edited config /var/unbound/unbound.conf directly and sent a SIGHUP.

Still the error. Then checking the unbound docs at https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html it seems as if the default for edns-buffer-size and max-udp-size is already 1232 - as an outcome from DNS flag day. Yet it doesn't seem this way

Has anyone figured out this can of worms?

or is this just a client issue? (drill) and I shouldn't need to worry. I'm concerned it may be comprimising my dns resolution/dnssec in some way? Or indeed are there any other changes recommended on opnsense itself, given that it's unique in the network in not having the info from the RAs.

[planetf1]

ISP is EE(BT) in the UK. 1 Gbps service (this and lower services are provisioned very differently to the 1.6 Gbps service+)

[planetf1]

A possible alternative to reducing bad to 1220 is to enable the newer pmtu discovery

I noticed this is setup via

net.inet.tcp.pmtud_blackhole_detection=1
net.inet.tcp.pmtud_blackhole_mss=1220

Have added this but I'll stick with the max at 1220 too for a day anyway.

But this might resolve the opnsense issue - if the stack remembers long enough since it seems many many network have a lower limit for various reasons, and so it may be a balance....

[nero355]

So I thought I should set
edns-buffer-size: 1232
msg-buffer-size: 8192

but had trouble figuring out how to inject these values. Eventually for a test I just edited config /var/unbound/unbound.conf directly and sent a SIGHUP.

Still the error. Then checking the unbound docs at https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html it seems as if the default for edns-buffer-size and max-udp-size is already 1232 - as an outcome from DNS flag day. Yet it doesn't seem this way

Has anyone figured out this can of worms?

For what it's worth =>

My DNS setup is Pi-Hole + Unbound and this setting is there for many years now :

Code Select Expand

# Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232So you should definitely include it in your configuration file :)

The above is a small part of the configuration shown here : https://docs.pi-hole.net/guides/dns/unbound/