Stefan,
Thanks for clarifying the situation.
As for the SOA question, it depends, but SOA is never included in both sections.
Compare these results:
$ kdig @ns0.estada.ch. +nostats +noopt estada.ch SOA
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 2168
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; QUESTION SECTION:
;; estada.ch. IN SOA
;; ANSWER SECTION:
estada.ch. 86400 IN SOA ns2.estada.ch. dnsadmin.estada.ch.
2026060901 14400 600 2419200 600
$ kdig @ns0.estada.ch. +nostats +noopt estada.ch LOC
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 54424
;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 1
;; QUESTION SECTION:
;; estada.ch. IN LOC
;; AUTHORITY SECTION:
estada.ch. 600 IN SOA ns2.estada.ch. dnsadmin.estada.ch.
2026060901 14400 600 2419200 600
$ kdig @ns0.estada.ch. +nostats +noopt bogus.estada.ch LOC
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 59535
;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 1
;; QUESTION SECTION:
;; bogus.estada.ch. IN LOC
;; AUTHORITY SECTION:
estada.ch. 600 IN SOA ns2.estada.ch. dnsadmin.estada.ch.
2026060901 14400 600 2419200 600
Daniel
On 6/9/26 09:37, Stefan Estada wrote:
Hi Libor & community
Sorry for confusing the source of the problem, knot was correct.
The correlation of me upgrading knot and some resolver becoming stricter was not
causation.
The actual problem in the end was that my custom DNS Server did not reply with the QR bit
set.
Weirdly almost no tool did report that, found it with bind's `dig +trace
dynamic.estada.ch <http://dynamic.estada.ch>` command, but even there it was just a
warning.
The only thing I am not quite sure currently, when answering a SOA query. Should I put
the answer in the answer or the authority section? I am currently putting it in both.
Also, the website resolves now again:
https://dynamic.estada.ch/
<https://dynamic.estada.ch/>
Thanks again and have a nice day
Stefan
Am So., 7. Juni 2026 um 10:05 Uhr schrieb Libor Peltan <libor.peltan(a)nic.cz
<mailto:libor.peltan@nic.cz>>:
__
Hi Stefan,
thank you for reaching us :)
I don't really understand what exactly you are trying to achieve. You must have
misunderstood some basic concepts of DNS.
By introducing the NS record at the name dynamic.estada.ch
<http://dynamic.estada.ch>., you are declaring that the whole subtree, including the
name itself, is delegated to different authority. Because it is an in-domain delegation,
you correctly provide glue records, so that the resolver has a way to go further. But
those glue records are not authoritative in the estada.ch <http://estada.ch> zone
and resolver should not return them in the final answer to the client. Instead, the
resolver shall chase the delegation, go to the nameserver at 185.194.239.135 and query the
delegated zone. However, in your case, the delegation is lame, because the target
nameserver doesn't have the zone dynamic.estada.ch <http://dynamic.estada.ch>
configured (it has the parent zone estada.ch <http://estada.ch> instead!) and
returns the delegation again. Some resolvers (including 9.9.9.9) are confused to the
degree that they indeed return the glue records; some (like 8.8.8.8) correctly point
out the lame delegation.
I'm surprised that you introduce this issue as "since upgrading Knot".
This doesn't look like any bug in Knot, rather a misconfiguration of your
authoritative servers. And the way Knot answers a delegation has not changed, since that
is one of DNS fundamentals. What you are asking for -- that Knot would answer the glue
records from the parent zone as if they were authoritative -- would actually be a
violation of basic DNS RFCs.
What you probably need is to either remove the delegation (NS), and let the zone
estada.ch <http://estada.ch>. authoritatively answer the A/AAAA/other records, or
configure the child zone at the delegated nameservers.
Libor
On 05. 06. 26 17:53, Stefan Estada wrote:
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
<http://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 <http://dynamic.estada.ch>. 3600 A 185.194.239.135
dynamic.estada.ch <http://dynamic.estada.ch>. 3600 AAAA 2a0a:51c0::12b
dynamic.estada.ch <http://dynamic.estada.ch>. 3600 NS dynamic.estada.ch
<http://dynamic.estada.ch>.
kdig AAAA dynamic.estada.ch <http://dynamic.estada.ch> @ns1.estada.ch
<http://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 <http://dynamic.estada.ch>. INAAAA
;; AUTHORITY SECTION:
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INNSdynamic.estada.ch
<http://dynamic.estada.ch>.
;; ADDITIONAL SECTION:
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INA185.194.239.135
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INAAAA2a0a:51c0::12b
But public servers don't get the glue records:
kdig AAAA dynamic.estada.ch <http://dynamic.estada.ch> @9.9.9.9
<http://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 <http://dynamic.estada.ch>. INAAAA
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 <http://dynamic.estada.ch> @ns1.estada.ch
<http://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 <http://dynamic.estada.ch>. INANY
;; AUTHORITY SECTION:
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INNSdynamic.estada.ch
<http://dynamic.estada.ch>.
;; ADDITIONAL SECTION:
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INA185.194.239.135
dynamic.estada.ch <http://dynamic.estada.ch>. 3600INAAAA2a0a:51c0::12b
I am happy for any pointers you may have.
Cheers,
Stefan
--
--