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

--