Hi everyone, I have been recently working on a Knot-Resolver (kr) module for some research work. This led me to push new queries into the resolution plan, wait for the answer and then resume the "standard" kr-spooled queries. Once all queries are resolved, when my finish module callback (cb) is invoked, I write down some statistics that were collected throughout the various queries. Among the thing that I write down, I inspect some data in the cache, including zonecuts. I discovered that some information returned by lib/zonecut.c:kr_zonecut_find_cached were different from what I expected. I am not sure if this is because my call to kr_zonecut_find_cached is incorrect, if I messed up some kr internal logic or if I stumbled on a bug. Here follows a made-up domain name tree similar to what made me stumbled on this issue, what I thought should be returned by kr_zonecut_find_cached, and what is actually returned. The original query qname is example.com.. Example.com. is delegated to a company owning example.net, a DNS reseller providing DNS hosting for its clients. example.com. is gluelessly delegated to ns1.example.net. and ns2.example.net.. example.net. is gluelessly delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net.. some-famous-registrar.net. is also delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net. thus using a glued delegation. When I call kr_zonecut_find_cached in my module finish cb, with a "name" param whose value is srv1.some-famous-registrar.net., I expected the cut out-param to be filled with a kr_zonecut structure with a "name" equal to some-famous-registrar.net. and a nsset equal to srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net. Unfortunately, cut->name values net., which is of course incorrect, since some-famous-registrar is a delegated name. My call to kr_zonecut_find_cached is using a kr_cache_txn structure created by the finish cb, using the cache in ((knot_layer_t*) ctx)->((kr_request*) data)->ctx->cache. It may also be worth noting that I use "false" for the secured param of the kr_zonecut_find_cached call. If this is indeed a bug, my guess would be that example.com. delegation leads kr to ask to net. nameservers for the delegation information for example.net.. net. nameservers answer that the delegation to example.net. is through srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net.. At the same time, net. nameservers also provide the *glues* for srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net., since the net. zone contains non-authoritative IP address records for these names for the glued delegation of some-famous-registrar.net. This could make kr to believe that net. is "authoritative" in some way for srv1.some-famous-registrar.net. and therefore to think that the some-famous-registrar.net is not a delegated zone. It is however possible that I completely crashed kr zonecut logic with the additional queries that I pushed from time to time, though. Does that ring a bell to anyone? What would be, according to you, the next step I should take to better understand what is going on? Thanks for your help! Cheers, Florian