knot-dns-users June 2026

knot-dns-users@lists.nic.cz

4 participants
3 discussions

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.5. This is a bug fix version with some improvements. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.5/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

23 hours, 26 minutes

[BUG] AXFR responses missing AA bit (RFC 5936 violation) in Knot 3.5.x

by Mateusz Masłowski

Hello, I would like to report a bug in Knot DNS 3.5.x where AXFR responses do not have the Authoritative Answer (AA) bit set, which appears to violate RFC 5936 §2.2. Affected versions tested: - 3.5.3 - 3.5.4 Packages tested: - cznic.1~bookworm Summary RFC 5936 §2.2 states: "Each DNS message returned by the AXFR server MUST have the AA bit set to 1." However, Knot DNS sends AXFR responses with flags set to qr only. The AA bit is not set in any of the messages in the transfer stream. As a result, strict secondary DNS servers, notably Windows Server DNS, reject such responses as invalid and abort the zone transfer. Expected behavior AXFR response messages should have the AA bit set. Expected flags: qr aa Actual behavior AXFR response messages have only the QR bit set. Actual flags: qr Possible root cause The function axfr_process_query() in src/knot/nameserver/axfr.c does not appear to call knot_wire_set_aa(). By contrast, the normal query path, via solve_answer() in internet.c, does set the AA bit, so SOA, A, and other authoritative responses are returned correctly. The AXFR code path appears to bypass this logic. Minimal reproducer dig @<knot-master> +tcp AXFR <zone> | head -2 Observed output: ;; flags: qr; The AA bit is missing. This can also be verified with tcpdump: byte 3 of each DNS message in the AXFR stream has value 0x80 / QR only, instead of 0x84 / QR + AA. -- Best regards, Mateusz Masłowski

1 day, 14 hours

Glue Record Problem

by Stefan Estada

Hi all I am having trouble forwarding a subdomain since I upgraded to the latest knot. For a couple of years I have been running a custom DNS server under dynamic.estada.ch that the clients find via my regular infrastructure. On my primary zone I have these records, but knot appears to answer weirdly: *estada.ch.zone* dynamic.estada.ch. 3600 A 185.194.239.135 dynamic.estada.ch. 3600 AAAA 2a0a:51c0::12b dynamic.estada.ch. 3600 NS dynamic.estada.ch. kdig AAAA dynamic.estada.ch @ns1.estada.ch ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 29173 ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 3 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN AAAA ;; AUTHORITY SECTION: dynamic.estada.ch. 3600 IN NS dynamic.estada.ch. ;; ADDITIONAL SECTION: dynamic.estada.ch. 3600 IN A 185.194.239.135 dynamic.estada.ch. 3600 IN AAAA 2a0a:51c0::12b But public servers don't get the glue records: kdig AAAA dynamic.estada.ch @9.9.9.9 ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 63899 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN AAAA The trouble is that most resolvers are now unable to resolve the domain as the AAAA and A queries still get answered with NS + additional A+AAAA. Is there a configuration option to tell knot to actually respond with the A or AAAA record when asked? Also ANY, TXT, or CAA queries behave the same as NS queries: kdig ANY dynamic.estada.ch @ns1.estada.ch ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14419 ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 3 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN ANY ;; AUTHORITY SECTION: dynamic.estada.ch. 3600 IN NS dynamic.estada.ch. ;; ADDITIONAL SECTION: dynamic.estada.ch. 3600 IN A 185.194.239.135 dynamic.estada.ch. 3600 IN AAAA 2a0a:51c0::12b I am happy for any pointers you may have. Cheers, Stefan

3 days, 17 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users June 2026