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 <[email protected]
>:

> 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
>
> --
>
>
--

Reply via email to