[ Continuation of #issue8904
However, this is even more important in chain of resolvers: if, for example, you want to find org\0telegram\0 entry, and root resolver tells that org\0 is delegated to your resolver, client will say "okay, now lets ask your resolver" and attempt to resolve this entry using dnsresolve(name, cat) with your resolver. This way, I see three problems here (mentioned in #issue8899
): your resolver cannot perform forwarding to another chain (because there is no special -1 next entry), category #1 is clobbered by owner address (i believe that category 1 may be "primary" in future, like A or AAAA in normal DNS), and most importantly, not having standartized dnsresolve will trash the resolution when client attempts to find and call dnsresolve at your contract. This way, it should be implemented inside your contract because it is not possible to "proxy" dnsresolve through another contract (remember, no ways to call another SC get-methods).