9 Čen
2026
9 Čen
'26
9:37
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` 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/
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
:
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., 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
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 configured (it has the parent zone 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. 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 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
--