KNOT — OPT=15: P3CD: root delegation . failure

Network
1

I am seeing a reproducible DNS failure on a clean IPFire Core Update 203 installation using Knot Resolver.

IPv4 resolution works, but AAAA lookups through IPFire intermittently fail with SERVFAIL. Example from a Mac client on GREEN:

dig @192.168.10.1 schwab.com AAAA

status: SERVFAIL
OPT=15: P3CD: delegation .

The same client can query an external resolver directly:

dig @1.1.1.1 schwab.com AAAA

and receives a normal NOERROR response.

Has anyone else seen this behavior with CU203/Knot Resolver, or is there a recommended diagnostic or fix for the root-delegation/DNSSEC state?

2

My Knot Resolver gives no errors for schwab.com.
Which DNS servers have you configured?

3

I have four IPFIRE instalations and all are responding with:

; <<>> DiG 9.20.24 <<>> schwab.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56171
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;schwab.com. IN A

;; ANSWER SECTION:
schwab.com. 30 IN A 162.93.229.103
schwab.com. 30 IN A 162.93.215.103

;; Query time: 730 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Aug 15 12:44:17 CEST 2026
;; MSG SIZE rcvd: 71

It shuld be something with your specified DNS servers.

4
  1. The domain schwab.com does not have an AAAA record.
    Capture d'écran 2026-08-15 160716
    Capture d'écran 2026-08-15 1607161567×1085 83.6 KB

However, the SERVFAIL status indicates a problem during DNS resolution.

Does this error occur only with this domain, or with all domains?
Try dig @192.168.10.1 google.com AAAA

Edit: Why do you need IPv6 resolution behind IPFire ?
On my CU203 test platform, the command works fine.

dig @192.168.10.1 schwab.com AAAA

; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> @192.168.10.1 schwab.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60298
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;schwab.com.			IN	AAAA

;; AUTHORITY SECTION:
schwab.com.		600	IN	SOA	d33pf2cdc.schwab.com. dnsadmin.schwab.com. 2023023302 3600 900 604800 600

;; Query time: 162 msec
;; SERVER: 192.168.10.1#53(192.168.10.1) (UDP)
;; WHEN: Sat Aug 15 16:16:49 CEST 2026
;; MSG SIZE  rcvd: 94
5

RESOLVED. IPF TLS was behind a Router encrypt mechanism - which when removed allowed NO ERROR: The working configuration is:

  • IPFire CU203 with Knot Resolver
  • IPFire DNS queries set to TLS
  • Router DNS “Override DNS Settings OFF
  • Router VPN ON

The conflict was Router’s forced DNS override intercepting traffic that IPFire/Knot needed to handle according to its own DNS configuration. With IPFire forwarding upstream DNS over TLS, that override was unnecessary and disruptive.