DNSSEC validation fails for belastingdienst.nl with EDE 22/23 and ConnectionReset, while direct TCP queries succeed

[Tankdoz]

When DNSSEC validation is enabled, Technitium DNS Server fails to resolve the domain “belastingdienst.nl” (dutch tax service). The server repeatedly returns SERVFAIL together with EDE 22 (No Reachable Authority) and EDE 23 (Network Error: ConnectionReset).
When DNSSEC validation is disabled, the domain resolves immediately without any issues.
The failure only occurs during recursive DNSSEC validation performed by Technitium.
Direct TCP queries from the host system and from inside the Docker/LXC container to the authoritative nameservers of belastingdienst.nl succeed without any problems.
This strongly suggests that the issue is inside Technitium’s DNSSEC validation path (EDNS negotiation, fallback logic, or handling of large DNSSEC responses), not in the network.

Environment

• Technitium DNS Server version: 14.3
• Deployment:
• Node 10: Docker (raspberry-pi)
• Node 14: Docker (VM proxmox)
• Node 15: LXC (LXC proxmox, primary node)
• Cluster mode enabled
• DNSSEC validation enabled → failure
• DNSSEC validation disabled → works
• All nodes show identical behavior

Observed behavior
With DNSSEC enabled, queries for belastingdienst.nl return:

• SERVFAIL
• EDE 22 (No Reachable Authority)
• EDE 23 (Network Error: ConnectionReset)
• EDE 13 (Cached Error)
• EDE 3 (Stale Answer)
  This happens for both A and AAAA queries.

Expected behavior
Technitium should be able to perform full DNSSEC validation for belastingdienst.nl, including:

• DS lookup at the root zone
• DS lookup at the .nl zone
• DNSKEY lookup at belastingdienst.nl
• EDNS negotiation
• TCP fallback for large DNSSEC responses

What works

• Direct TCP queries from the host (outside Technitium)
  Running a TCP query directly to the authoritative nameserver (for example 85.159.100.53) returns a correct NOERROR response with the A record for belastingdienst.nl.
• Direct TCP queries from inside the Docker container
  Running the same query inside the Technitium container also returns a correct NOERROR response.
• With DNSSEC disabled in Technitium
  Queries to belastingdienst.nl resolve instantly and correctly.
  This confirms that:
• TCP/53 works
• UDP works
• The authoritative nameservers respond correctly
• The network path is fine
• Only Technitium’s DNSSEC validation path fails

Reproduction steps

• Enable DNSSEC validation in Technitium
• Ensure no forwarders are configured (recursive mode)
• Query “belastingdienst.nl” through Technitium
• Observe SERVFAIL with EDE 22 and EDE 23
• Disable DNSSEC validation
• Query again → domain resolves normally

Analysis
Because:
• direct TCP queries work from host and container
• UDP works
• TCP/53 is not blocked
• MTU issues are unlikely (large DNSSEC responses succeed directly)
• only Technitium’s recursive DNSSEC validation fails

…it appears to be an issue in Technitium’s DNSSEC validation logic, possibly involving:
• EDNS buffer size negotiation
• fallback to TCP
• handling of large DNSSEC responses
• retry logic between root → .nl → belastingdienst.nl
• or interaction with the recursive resolver’s selection logic

Request
Could you investigate whether Technitium’s DNSSEC validation path has an issue when resolving belastingdienst.nl, especially around EDNS handling or TCP fallback during DNSSEC validation?
I can provide logs or packet captures if needed.

[ShreyasZare]

Thanks for the post. The domain name is resolving without any issues from multiple locations I tested from. You can test it with DNS Client website too.

It looks more like your ISP interfering with the DNSSEC requests since the DNS server is able to resolve it without issues. I would suggest that you run the same test with another ISP and see if you can reproduce it.

[Tankdoz]

Thanks for the suggestion to test using the DNS Client tool. I ran the DNS Client with “Enable DNSSEC Validation” enabled, and direct queries to the authoritative nameserver for belastingdienst.nl return fully valid DNSSEC responses. This confirms that the authoritative servers, DNSSEC signatures, EDNS negotiation, UDP, and the network path are all functioning correctly.
However, when querying the same domain through Technitium DNS Server (recursive mode, DNSSEC enabled), the server fails during DNSSEC validation. Below is the output from querying DNSKEY via my Technitium node (127.0.0.1). This clearly shows that Technitium marks the DNSKEY set as “Bogus” and reports “RRSIGsMissing /DNSKEY”, even though the authoritative server does provide valid RRSIGs:

{
  "Metadata": {
    "NameServer": "node15.dns.cluster (127.0.0.1)",
    "Protocol": "Udp",
    "DatagramSize": "853 bytes",
    "RoundTripTime": "0.7 ms"
  },
  "EDNS": {
    "UdpPayloadSize": 1232,
    "ExtendedRCODE": "NoError",
    "Version": 0,
    "Flags": "DNSSEC_OK",
    "Options": []
  },
  "DnsClientExtendedErrors": [
    {
      "InfoCode": "RRSIGsMissing",
      "ExtraText": "Attack detected! /DNSKEY"
    }
  ],
  "Identifier": 29736,
  "IsResponse": true,
  "OPCODE": "StandardQuery",
  "AuthoritativeAnswer": false,
  "Truncation": false,
  "RecursionDesired": true,
  "RecursionAvailable": true,
  "Z": 0,
  "AuthenticData": false,
  "CheckingDisabled": true,
  "RCODE": "NoError",
  "QDCOUNT": 1,
  "ANCOUNT": 3,
  "NSCOUNT": 0,
  "ARCOUNT": 1,
  "Question": [
    {
      "Name": "",
      "Type": "DNSKEY",
      "Class": "IN"
    }
  ],
  "Answer": [
    {
      "Name": "",
      "Type": "DNSKEY",
      "Class": "IN",
      "TTL": "3600 (1h)",
      "RDLENGTH": "264 bytes",
      "RDATA": {
        "Flags": "SecureEntryPoint, ZoneKey",
        "Protocol": 3,
        "Algorithm": "RSASHA256 (8)",
        "PublicKey": "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=",
        "ComputedKeyTag": 20326
      },
      "DnssecStatus": "Bogus"
    },
    {
      "Name": "",
      "Type": "DNSKEY",
      "Class": "IN",
      "TTL": "3600 (1h)",
      "RDLENGTH": "264 bytes",
      "RDATA": {
        "Flags": "ZoneKey",
        "Protocol": 3,
        "Algorithm": "RSASHA256 (8)",
        "PublicKey": "AwEAAbNTVC2+pry4pc37pZI9Oj6b8FHxT3VGrvSPKLE1Tjyfe2kUZUtVX5xrv6AV4BVO+ygrYjGZMNgEnbLU4zknnlnhI2e0g6iTza1aZh0dRZXGH16C1NUNq1CxBkUhIYQhQDeIOtLacx+RmFTc+hSHJJ2MJ79IS00kA7eKi6mofQ7SPJmdJVjI+JAx791y0f5QaB+iHGANU53FwiYXNUQjfAzCrtOaSevGsx8SO8BTaXLAjFq5eewOtwScVwfVDhEXlvpE6e+mIncwhNKaMRD9IPuHENqCNPI5MjxfAMVS6cEY8eEozIkv/vHc+0Auu3n+Fcx6F2Js4KPXaHEShAXugfU=",
        "ComputedKeyTag": 21831
      },
      "DnssecStatus": "Bogus"
    },
    {
      "Name": "",
      "Type": "DNSKEY",
      "Class": "IN",
      "TTL": "3600 (1h)",
      "RDLENGTH": "264 bytes",
      "RDATA": {
        "Flags": "SecureEntryPoint, ZoneKey",
        "Protocol": 3,
        "Algorithm": "RSASHA256 (8)",
        "PublicKey": "AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=",
        "ComputedKeyTag": 38696
      },
      "DnssecStatus": "Bogus"
    }
  ],
  "Authority": [],
  "Additional": [
    {
      "Name": "",
      "Type": "OPT",
      "Class": "1232",
      "TTL": "32768 (9h6m8s)",
      "RDLENGTH": "0 bytes",
      "RDATA": {
        "Options": []
      },
      "DnssecStatus": "Unknown"
    }
  ]
}

This is the key point:
Direct queries (host and container) return valid DNSKEY + RRSIG.
Technitium’s recursive resolver receives the DNSKEY set, but the RRSIG is missing or not processed during recursion, causing the validator to mark the response as Bogus and trigger “Attack detected!”.
Since:
• direct UDP and TCP queries work
• DNSSEC validation succeeds outside Technitium
• the DNS Client tool shows valid DNSSEC responses
• three different hosts (Docker on Raspberry Pi, Docker on Proxmox VM, LXC on Proxmox) show identical behavior
• only Technitium’s recursive DNSSEC validation path fails
…it appears the issue is specifically inside Technitium’s DNSSEC validation logic, likely related to EDNS handling, TCP fallback, or RRSIG processing during the DNSKEY step of the chain walk.
I’m happy to provide additional logs or run further tests if needed.

[ShreyasZare]

I did test the same domain name on multiple Technitium DNS Server instances with DNSSEC Validation enabled and in recursive resolver mode (no forwarders). Its working well without issues here so there does not seem to be any bug in the implementation.

Note that the DNS Client's "Enable DNSSEC Validation" option is independent of the "Enable DNSSEC Validation" option in Setting > General section. The DNS Client works like a independent tool and does DNSSEC validation at its own level. The DNS Server does DNSSEC validation when it does the actual recursive resolution. For this test with the built-in DNS Client tool, make sure that DNSSEC validation option in Settings > General section is enabled otherwise the DNS Server wont return RRSIG records in response like in the output you shared. Repeat the same test again with ensuring DNSSEC validation is enabled in settings and let me know the output.

I would also suggest that you use the built-in DNS Client tool on the admin panel with Recursive Query {recursive-resolver} as the Server and "Enable DNSSEC Validation" option enabled. With this test, the DNS Client tool will perform recursive resolution on its own without any help from the DNS Server. Let me know the output of that test.

[Hemsby]

I am also able to confirm I have no issues resolving belastingdienst.nl with DNSSEC Validation enabled. Tested This Server, Cloudflare, Google, AdGuardand and Recursive.

[Tankdoz]

Regarding the test with the built‑in DNS Client tool: the result is no longer the same as before. Previously, the DNS Client returned a full DNSKEY response (including all DNSKEY records and EDNS information), but marked the result as Bogus with the extended error RRSIGsMissing. In other words, the resolver did receive the DNSSEC data, but failed to validate it.
However, when I repeat the same test now, the DNS Client no longer receives any DNSKEY response at all. Instead, it shows a red error window with “no response from name servers” and “request timed out” for all authoritative servers of belastingdienst.nl. This is despite the fact that a packet capture confirms those servers do respond normally and provide complete DNSKEY and RRSIG records. This suggests that the recursive resolver has entered an internal failure state after the earlier DNSSEC validation errors, and is now treating the entire delegation as unreachable.
I’m glad to hear it resolves correctly on your end, but I would like to understand what could be wrong with my server(s). I haven’t encountered any other domains that fail in this way.

Edit: I can recreate the error above by turning DNSSEC validation off in settings and using 'This Server' and 'enable DNSSEC validation = on' in the DNS client while querying the domain belastingdienst.nl

[Potterli20]

It's somewhat similar to my problem.

[ShreyasZare]

Regarding the test with the built‑in DNS Client tool: the result is no longer the same as before. Previously, the DNS Client returned a full DNSKEY response (including all DNSKEY records and EDNS information), but marked the result as Bogus with the extended error RRSIGsMissing. In other words, the resolver did receive the DNSSEC data, but failed to validate it. However, when I repeat the same test now, the DNS Client no longer receives any DNSKEY response at all. Instead, it shows a red error window with “no response from name servers” and “request timed out” for all authoritative servers of belastingdienst.nl. This is despite the fact that a packet capture confirms those servers do respond normally and provide complete DNSKEY and RRSIG records. This suggests that the recursive resolver has entered an internal failure state after the earlier DNSSEC validation errors, and is now treating the entire delegation as unreachable. I’m glad to hear it resolves correctly on your end, but I would like to understand what could be wrong with my server(s). I haven’t encountered any other domains that fail in this way.

I had requested you to do two separate tests in my previous response. So not really sure which response you are describing plus there is no output provided so cannot understand anything here.

Anyways, lets skip the earlier tests and do a single test with tcpdump (packet capture) running. For this test, first setup the packet capture to run on the server and store output to a local pcap file. Once done, switch to the DNS Client tab on the admin panel, select Recursive Query {recursive-resolver} as the Server, enter belastingdienst.nl as the domain name, check the Enable DNSSEC Validation checkbox, and click on Resolve button. Once you see some output/error on the DNS Client, stop the packet capture and share the pcap file either here or send it to support@technitium.com. This pcap file will help me understand what is going on at the network level. Also share the output/error of the DNS Client along with the pcap file.

Edit: I can recreate the error above by turning DNSSEC validation off in settings and using 'This Server' and 'enable DNSSEC validation = on' in the DNS client while querying the domain belastingdienst.nl

This is exactly how its supposed to work and is not an error. If you disable DNSSEC validation in Settings then the DNS Server will not respond with any RRSIG records. Thus the DNS Client will give you RRSIGsMissing in response since the DNS Client does DNSSEC validation on its own and will have an issue when the response is missing RRSIG records. You must have DNSSEC validation enabled in Settings before you do any DNSSEC related test.

I would like to clarify once again that the Enable DNSSEC Validation option in Settings is entirely unrelated from the Enable DNSSEC Validation option in the DNS Client. The Enable DNSSEC Validation in Settings will enable DNSSEC Validation inside the DNS Server whereas the Enable DNSSEC Validation option in DNS Client will tell the DNS Client to do validation at its own level independent of the DNS Server.

[Tankdoz]

I'm sorry if I caused any confusion earlier. Regarding your previous question:

Question:

I would also suggest that you use the built-in DNS Client tool on the admin panel with Recursive Query {recursive-resolver} as the Server and "Enable DNSSEC Validation" option enabled. With this test, the DNS Client tool will perform recursive resolution on its own without any help from the DNS Server. Let me know the output of that test.

When I run this test using Recursive Query {recursive-resolver} in the DNS Client tool on the admin dashboard, I get the following results:

Sometimes I get the first result, sometimes the second.

Regarding your question about the packet capture: I performed this test yesterday as well, but here is a fresh packet capture from this morning, taken during the DNS Client test using “Recursive Query {recursive-resolver}” with DNSSEC validation enabled. The behaviour in all pcaps is identical.

133	
13.105862	192.168.1.15	147.181.112.4	DNS	89	Standard query 0xa26c DNSKEY belastingdienst.nl OPT
134	13.106205	194.0.28.53	192.168.1.15	DNS	331	Standard query response 0x2284 DNSKEY nl DNSKEY DNSKEY RRSIG OPT
135	13.115339	185.159.199.200	192.168.1.15	DNS	331	Standard query response 0x4f4d DNSKEY nl DNSKEY DNSKEY RRSIG OPT
136	13.116841	185.159.199.200	192.168.1.15	DNS	331	Standard query response 0x6ad6 DNSKEY nl DNSKEY DNSKEY RRSIG OPT
137	13.126147	85.159.100.53	192.168.1.15	DNS	89	Standard query response 0x2868 DNSKEY belastingdienst.nl OPT
138	13.126281	192.168.1.15	85.159.100.53	TCP	74	59142 → 53 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=313186479 TSecr=0 WS=128
139	13.128899	147.181.112.4	192.168.1.15	DNS	89	Standard query response 0xa26c DNSKEY belastingdienst.nl OPT
140	13.129019	192.168.1.15	147.181.112.4	TCP	74	38142 → 53 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=191964339 TSecr=0 WS=128
141	13.143151	85.159.100.53	192.168.1.15	TCP	74	53 → 59142 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2772018158 TSecr=313186479 WS=2048
142	13.143178	192.168.1.15	85.159.100.53	TCP	66	59142 → 53 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=313186496 TSecr=2772018158
143	13.143310	192.168.1.15	85.159.100.53	DNS	115	Standard query 0x2868 DNSKEY belastingdienst.nl OPT
144	13.148755	147.181.112.4	192.168.1.15	TCP	74	53 → 38142 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2802203663 TSecr=191964339 WS=2048
145	13.148765	192.168.1.15	147.181.112.4	TCP	66	38142 → 53 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=191964358 TSecr=2802203663
146	13.148906	192.168.1.15	147.181.112.4	DNS	115	Standard query 0xa26c DNSKEY belastingdienst.nl OPT
147	13.168451	147.181.112.4	192.168.1.15	TCP	66	53 → 38142 [ACK] Seq=1 Ack=50 Win=65536 Len=0 TSval=2802203681 TSecr=191964358
148	13.168760	147.181.112.4	192.168.1.15	TCP	66	[TCP Previous segment not captured] 53 → 38142 [FIN, ACK] Seq=2278 Ack=50 Win=65536 Len=0 TSval=2802203682 TSecr=191964358
149	13.168768	192.168.1.15	147.181.112.4	TCP	78	[TCP Dup ACK 145#1] 38142 → 53 [ACK] Seq=50 Ack=1 Win=64256 Len=0 TSval=191964378 TSecr=2802203681 SLE=2278 SRE=2279
150	13.169106	85.159.100.53	192.168.1.15	TCP	66	53 → 59142 [ACK] Seq=1 Ack=50 Win=65536 Len=0 TSval=2772018183 TSecr=313186496
151	13.170421	85.159.100.53	192.168.1.15	TCP	66	[TCP Previous segment not captured] 53 → 59142 [FIN, ACK] Seq=2278 Ack=50 Win=65536 Len=0 TSval=2772018183 TSecr=313186496
152	13.170429	192.168.1.15	85.159.100.53	TCP	78	[TCP Dup ACK 142#1] 59142 → 53 [ACK] Seq=50 Ack=1 Win=64256 Len=0 TSval=313186523 TSecr=2772018183 SLE=2278 SRE=2279
153	23.144026	192.168.1.15	85.159.96.53	DNS	89	Standard query 0xbd6b DNSKEY belastingdienst.nl OPT
154	23.163993	85.159.96.53	192.168.1.15	DNS	89	Standard query response 0xbd6b DNSKEY belastingdienst.nl OPT
155	23.164140	192.168.1.15	85.159.96.53	TCP	74	38000 → 53 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=2263710843 TSecr=0 WS=128
156	23.180725	85.159.96.53	192.168.1.15	TCP	74	53 → 38000 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=3418252834 TSecr=2263710843 WS=2048
157	23.180750	192.168.1.15	85.159.96.53	TCP	66	38000 → 53 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2263710859 TSecr=3418252834
158	23.180887	192.168.1.15	85.159.96.53	DNS	115	Standard query 0xbd6b DNSKEY belastingdienst.nl OPT
159	23.203277	85.159.96.53	192.168.1.15	TCP	66	53 → 38000 [ACK] Seq=1 Ack=50 Win=65536 Len=0 TSval=3418252857 TSecr=2263710859
160	23.203931	85.159.96.53	192.168.1.15	TCP	66	[TCP Previous segment not captured] 53 → 38000 [FIN, ACK] Seq=2278 Ack=50 Win=65536 Len=0 TSval=3418252857 TSecr=2263710859
161	23.203939	192.168.1.15	85.159.96.53	TCP	78	[TCP Dup ACK 157#1] 38000 → 53 [ACK] Seq=50 Ack=1 Win=64256 Len=0 TSval=2263710882 TSecr=3418252857 SLE=2278 SRE=2279
162	23.313449	192.168.1.14	192.168.1.15	TCP	74	23676 → 53 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=3817919471 TSecr=0 WS=128
163	23.313462	192.168.1.15	192.168.1.14	TCP	74	53 → 23676 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=4069761835 TSecr=3817919471 WS=128
164	23.313582	192.168.1.14	192.168.1.15	TCP	66	23676 → 53 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3817919471 TSecr=4069761835
165	23.313717	192.168.1.14	192.168.1.15	DNS	208	Standard query 0xf193 SOA alphonso.tv OPT TSIG
166	23.313726	192.168.1.15	192.168.1.14	TCP	66	53 → 23676 [ACK] Seq=1 Ack=143 Win=65024 Len=0 TSval=4069761835 TSecr=3817919471
167	23.313848	192.168.1.15	192.168.1.14	DNS	261	Standard query response 0xf193 SOA alphonso.tv SOA node15.dns.cluster OPT TSIG
168	23.313969	192.168.1.14	192.168.1.15	TCP	66	23676 → 53 [ACK] Seq=143 Ack=196 Win=64128 Len=0 TSval=3817919472 TSecr=4069761835
169	23.625142	192.168.1.15	147.181.112.4	TCP	78	[TCP Keep-Alive] 38142 → 53 [ACK] Seq=49 Ack=1 Win=64256 Len=0 TSval=191974835 TSecr=2802203681 SLE=2278 SRE=2279
170	23.625147	192.168.1.15	85.159.100.53	TCP	78	[TCP Keep-Alive] 59142 → 53 [ACK] Seq=49 Ack=1 Win=64256 Len=0 TSval=313196978 TSecr=2772018183 SLE=2278 SRE=2279
171	23.639742	147.181.112.4	192.168.1.15	TCP	66	[TCP Keep-Alive ACK] 53 → 38142 [ACK] Seq=2279 Ack=50 Win=65536 Len=0 TSval=2802214154 TSecr=191964378
172	23.646021	85.159.100.53	192.168.1.15	TCP	66	[TCP Keep-Alive ACK] 53 → 59142 [ACK] Seq=2279 Ack=50 Win=65536 Len=0 TSval=2772028661 TSecr=313186523
173	24.110842	192.168.1.217	192.168.1.15	DNS	80	Standard query 0xf061 HTTPS beacons.gcp.gvt2.com

The pcap shows the following:

1. All authoritative servers for belastingdienst.nl return 89‑byte UDP DNSKEY responses. These responses are clearly truncated and cannot contain DNSKEY + RRSIG.
2. Technitium correctly performs TCP fallback and opens a TCP connection to each authoritative server.
3. The authoritative servers accept the TCP connection (SYN/ACK).
4. Technitium sends the DNSKEY query over TCP.
5. None of the authoritative servers send a DNSKEY response over TCP. Instead, each server immediately closes the connection with FIN,ACK.
6. As a result, the recursive resolver receives no DNSKEY RRSIGs. This leads to:
   • RRSIGsMissing
   • Bogus
   • ConnectionReset
   • NoReachableAuthority
   • SERVFAIL

When I query the same authoritative servers directly using “dig +tcp” (from both the host and inside the LXC container), they do return the full DNSKEY + RRSIG set over TCP without any issues.

This seems to imply that the authoritative servers reject only the TCP DNSKEY queries sent by the Technitium recursive resolver.

Btw: I get different results when testing with the DNS Client tool depending on whether “Enable DNSSEC validation” is turned on or off in Settings → General. This suggests that the DNS Client tool and the DNS Server are not fully independent.

[ShreyasZare]

Regarding your question about the packet capture: I performed this test yesterday as well, but here is a fresh packet capture from this morning, taken during the DNS Client test using “Recursive Query {recursive-resolver}” with DNSSEC validation enabled. The behaviour in all pcaps is identical.

The tcpdump output does not include all DNS request details so its not useful at all to do analysis. You need to share the pcap file, without which I wont be able to do anything further.

Btw: I get different results when testing with the DNS Client tool depending on whether “Enable DNSSEC validation” is turned on or off in Settings → General. This suggests that the DNS Client tool and the DNS Server are not fully independent.

Nope. I guess you have still not understood what the “Enable DNSSEC Validation” option in Setting does. When you disable it in Settings, the DNS server stops supporting DNSSEC completely i.e., wont understand DO flag in requests. Thus any client, be it DNS Client tool or any other tool that does validation, will give you the same results. This does not mean that the option has something to do with the DNS Client in anyway.

[Tankdoz]

I think there’s a communication issue here that I want to clarify, separate from the technical problem itself. I’m not a DNS expert, and I’m not claiming to be one — I’m simply reporting the symptoms I’m observing. Please consider that analysing this issue also takes time and effort on my side, which I was willing to invest because I like the project. When it’s assumed that nothing could be wrong on your side, or that I’m just not understanding something, it becomes difficult to collaborate constructively. For now, I’ll leave it at this and wait for a release where this issue might be fixed.

[ShreyasZare]

I think there’s a communication issue here that I want to clarify, separate from the technical problem itself. I’m not a DNS expert, and I’m not claiming to be one — I’m simply reporting the symptoms I’m observing. Please consider that analysing this issue also takes time and effort on my side, which I was willing to invest because I like the project. When it’s assumed that nothing could be wrong on your side, or that I’m just not understanding something, it becomes difficult to collaborate constructively. For now, I’ll leave it at this and wait for a release where this issue might be fixed.

Why can't you simply share the pcap file? That would help analyzing the issue at DNS level and I would have told you what the actual issue is base on it. Unless I can see the issue myself, there is nothing that can be done. The domain is resolving well with DNSSEC validation from multiple servers in multiple regions so its something at your network level that is causing the issue which needs to be figured out.

[hagezi]

I can't reproduce this on my Technitium instances either, but there are denial-of-existence issues with the domain.

https://dnsviz.net/d/belastingdienst.nl/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

delv @127.0.0.1 belastingdienst.nl
; fully validated
belastingdienst.nl.     13265   IN      A       85.159.98.33
belastingdienst.nl.     13265   IN      RRSIG   A 8 2 14400 20260201082229 20260                                                           128080658 63534 belastingdienst.nl. Ka5G2vwlqCsFuIecRUNqLxNNmr9YR+V9I5hrq4jg48wm                                                           oYOvQga2cIhW 9ggn4uLjpuv76B+xNqE1xql611J+vePgfs8Dhjh2Vl0Nhv4FtE4dlWSA 1MGT/xHIIP                                                           a8iaIpw3Jz9g84Fr5mpMzRgl2cFQ4zgTZA9zbB6P5oqHs2 vWhwOrzbZHt4OfA0DlfTsUry7AyYNQrrr                                                           Er6poRZVxj1qRiphkjBEgn8 ENocslgxUb+iboeqweebDuus7Iu5GzsEd1yjxr/vffScsdSWKH6KN+H4                                                            s4Vfs9by4nNjleusQqLkDcCRXihwupMiCzxIfGmL9oxylBb7hj7dC9sc CPxj2A==

{
  "Metadata": {
    "NameServer": "ns4.belastingdienst.nl (147.181.112.4)",
    "Protocol": "Udp",
    "DatagramSize": "369 bytes",
    "RoundTripTime": "14,35 ms"
  },
  "EDNS": {
    "UdpPayloadSize": 1220,
    "ExtendedRCODE": "NoError",
    "Version": 0,
    "Flags": "DNSSEC_OK",
    "Options": []
  },
  "Identifier": 0,
  "IsResponse": true,
  "OPCODE": "StandardQuery",
  "AuthoritativeAnswer": true,
  "Truncation": false,
  "RecursionDesired": false,
  "RecursionAvailable": false,
  "Z": 0,
  "AuthenticData": false,
  "CheckingDisabled": false,
  "RCODE": "NoError",
  "QDCOUNT": 1,
  "ANCOUNT": 2,
  "NSCOUNT": 0,
  "ARCOUNT": 1,
  "Question": [
    {
      "Name": "belastingdienst.nl",
      "Type": "A",
      "Class": "IN"
    }
  ],
  "Answer": [
    {
      "Name": "belastingdienst.nl",
      "Type": "A",
      "Class": "IN",
      "TTL": "14400 (4h)",
      "RDLENGTH": "4 bytes",
      "RDATA": {
        "IPAddress": "85.159.98.33"
      },
      "DnssecStatus": "Secure"
    },
    {
      "Name": "belastingdienst.nl",
      "Type": "RRSIG",
      "Class": "IN",
      "TTL": "14400 (4h)",
      "RDLENGTH": "294 bytes",
      "RDATA": {
        "TypeCovered": "A",
        "Algorithm": "RSASHA256 (8)",
        "Labels": 2,
        "OriginalTtl": 14400,
        "SignatureExpiration": "2026-02-01T08:22:29Z",
        "SignatureInception": "2026-01-28T08:06:58Z",
        "KeyTag": 63534,
        "SignersName": "belastingdienst.nl",
        "Signature": "Ka5G2vwlqCsFuIecRUNqLxNNmr9YR+V9I5hrq4jg48wmoYOvQga2cIhW9ggn4uLjpuv76B+xNqE1xql611J+vePgfs8Dhjh2Vl0Nhv4FtE4dlWSA1MGT/xHIIPa8iaIpw3Jz9g84Fr5mpMzRgl2cFQ4zgTZA9zbB6P5oqHs2vWhwOrzbZHt4OfA0DlfTsUry7AyYNQrrrEr6poRZVxj1qRiphkjBEgn8ENocslgxUb+iboeqweebDuus7Iu5GzsEd1yjxr/vffScsdSWKH6KN+H4s4Vfs9by4nNjleusQqLkDcCRXihwupMiCzxIfGmL9oxylBb7hj7dC9scCPxj2A=="
      },
      "DnssecStatus": "Secure"
    }
  ],
  "Authority": [],
  "Additional": [
    {
      "Name": "",
      "Type": "OPT",
      "Class": "1220",
      "TTL": "32768 (9h6m8s)",
      "RDLENGTH": "0 bytes",
      "RDATA": {
        "Options": []
      },
      "DnssecStatus": "Indeterminate"
    }
  ]
}