ik loop tegen een gek, maar inmiddels goed reproduceerbaar probleem aan op een Ziggo Zakelijk-aansluiting met een routed /29.
Situatie:
- OPNsense als firewall/router
- publiek subnet XX.XX.XX.120/29
- Mailcow-server intern op 192.168.50.101
- Mailcow gebruikt Unbound voor DNS
- internet/HTTPS en overige TCP-verkeer werken normaal
Het probleem zit specifiek bij DNS over
TCP/53.
Kleine DNS-antwoorden over TCP werken gewoon, bijvoorbeeld:
code:
1
| dig +tcp @1.1.1.1 example.com A |
Maar zodra het antwoord uit meerdere TCP-segmenten bestaat, komt de data niet meer aan op de WAN-interface van OPNsense. Bijvoorbeeld:
code:
1
2
| dig +tcp @1.1.1.1 microsoft.com TXT
dig +tcp +dnssec @199.180.182.53 in-addr.arpa DNSKEY |
Beide lopen in een timeout.
Wat opvallend is: exact vergelijkbare grote antwoorden via DNS-over-TLS op
TCP/853 werken probleemloos:
code:
1
2
3
| dig +tls @1.1.1.1 microsoft.com TXT
dig +tls @9.9.9.9 microsoft.com TXT
dig +tls +dnssec @1.1.1.1 . DNSKEY |
Daar komen antwoorden van meerdere kilobytes gewoon volledig binnen.
ik heb inmiddels behoorlijk wat uitgesloten:
- Suricata/IPS volledig gestopt → probleem blijft
- meerdere publieke source-IP’s uit de /29 getest (.122, .123, .124) → identiek gedrag
- PF/firewallregels → geen blocks
- NAT → werkt voor kleine TCP/53-antwoorden
- MTU 1500 / DF 1472 werkt
- checksum offloading, TSO en LRO staan uit
- geen DNS redirect/proxy op OPNsense
- OPNsense Unbound zit niet in het datapad van deze tests
- meerdere externe resolvers getest (1.1.1.1, 8.8.8.8, 9.9.9.9)
- HTTPS en ander TCP-verkeer werken normaal
Packet captures op LAN en WAN laten zien:
- TCP handshake is normaal
- DNS request verlaat de WAN-interface correct
- kleine TCP/53 response komt terug
- bij grote TCP/53 responses komen de datasegmenten niet aan op de WAN-interface
- latere ACK/FIN-pakketten komen soms wel binnen
- via TCP/853 komen meerdere datasegmenten wel volledig binnen
Kort gezegd:
code:
1
2
3
4
| TCP/53 klein antwoord → werkt
TCP/53 multi-segment → timeout
TCP/853 multi-segment → werkt
HTTPS / ander TCP → werkt |
Dat lijkt dus sterk op iets dat specifiek DNS-over-TCP op poort 53 inspecteert/filtert, bijvoorbeeld een DNS-ALG, DNS-proxy of beveiligingsfunctie upstream.
De gateway aan Ziggo-kant lijkt XX.XX.XX.121 te zijn; mijn publieke adressen zitten daarachter in dezelfde /29.
Heeft iemand dit recent gezien op Ziggo Zakelijk? Met name in combinatie met DNSSEC/DNSKEY, TCP/53 of een bepaalde modem/router/firmware? En weet iemand of Ziggo upstream DNS-verkeer inspecteert of een DNS-ALG gebruikt die dit gedrag zou kunnen verklaren?
Ik kan indien nuttig ook packet-capturedetails/testresultaten delen.
Dit is op dit moment vooral vervelend omdat Unbound bij grote DNSSEC/PTR-responses terugvalt op TCP/53, vervolgens SERVFAIL geeft en daardoor onder andere reverse-DNS-checks op de mailserver fout gaan.
Update / aanvullende bevinding
Inmiddels een tijdelijke workaround actief gezet waarbij normale DNS-resolutie via
DNS-over-TLS op TCP/853 loopt.
Testmail kwam direct binnen en belandde weer gewoon in de inbox i.p.v. ongewenste mail wat dus al een paar weken aan de gang was.
Daarnaast nog iets opvallends ontdekt:
DNS-antwoorden die verwijzen naar 127.0.0.0/8 of RFC1918-adressen (10/8, 172.16/12, 192.168/16) lijken upstream te worden gefilterd. NXDOMAIN en publieke adressen komen wel gewoon terug.
Dat lijkt sterk op een vorm van
DNS-rebinding protection / DNS inspection upstream. Dit raakt o.a. DNSBL/RBL-diensten, omdat die juist vaak met 127.x.x.x antwoorden.
Samengevat lijkt er dus sprake van twee aparte effecten:
- grotere DNS-antwoorden over TCP/53 verdwijnen
- DNS-antwoorden met loopback/private adressen worden gefilterd
Via
TCP/853 (DoT) werken grote antwoorden wel probleemloos.
De workaround lijkt de Mailcow/Rspamd-problemen in ieder geval direct sterk te verminderen, maar uiteraard is dit geen structurele oplossing voor het onderliggende Ziggo/upstream-probleem.
[
Voor 16% gewijzigd door
Holmes op 07-10-2026 20:45
]