Manual DNS TON smart contract. Implemented with prefix trees. Author: Adoriasoft.com

Manual DNS:
- There is no way to completely delete expired domains.
- It is much safer to call accept_message() just after the signature is checked.
- Category is 8-bit instead of 16-bit.
- Category 0 should return dict instead of Cell.
- When domain is found, but category is not found the returned length must be non-zero.

dns-manual-contract.fc:51 category=-2 (owner) or other negative categories are valid, no need to throw

dns-manual-contract.fc:126 category=0 should just return dnsrecord_dict; this code tries to pack everything as bits in one slice, which will overflow with just 4 entries. also same issue with categories <= -2

dns entries and subdomains can't be deleted, which is an issue because if you have "a.b" registered, and want to instead have "a.b.c" and "a.b.d", you are out of luck ("a.b" is a prefix of a new key)

Looking at both fc and fif code there is no ∅ character handling and suffixing at all: this way if you register dom you would not be able to register domain, because dom is prefix of domain. Neither fif script or func does add the ∅ (or any other) suffix to the subdomain name to prevent this collision. This also at the same time violates the 8m+1 rule in the response.

Rejecting negative categories also does not correspond to specification, any signed 16-bit number shall be accepted.

Message acception is executed very far in message handling logic, in case of large prefix tree and/or large category dictionary and/or gas credit decrease contract may cease to process controlling messages.

Okay, I have tried to re-test stuff at testnet. How nice that the contract with matching key is already deployed and is clean.
While testing found out another bug: dnsresolve(www.test.com, 1) returns (96, Cell), okay. But using category 2 returns 0 length (should return 96).

Also, the thing that you tried does not work with your contract.
Seqno is increased, but the new entry is not in the tree.
You are ignoring the fact that pfxdict_set may silently fail actually.
From the screenshots we can see that after registering www.test.com, www.test.com.abc silently fails registration.
Moreover, we can see from the tree that there is really no such entry.

You can inspect the transaction here: https://test.ton.org/testnet/transaction?account=0f9Tm2SKKVs0X1W_4F1B7oyNinPacm5PePpF-K2IP9W_ttko&lt=1179565000001&hash=F2233B6C15253B36CE450B969A380354DF2B49C623193C9CE8753801BB35E97E

It is strange that for you vm behaviour differs so much. In my contract i did negative testing on that situation and it expectedly failed. Maybe you forgot to persist data between vm calls or somehow throwed in data with no shared prefix.

#issue9039
> One could set the DNS record to some predefined value eg zero byte and consider it as deleted. Yet this issue is out of the task range.
This is not "completely delete". The domain will be stored forever and the contract will forever pay for it, eventually going out of money. This is a critical issue. "The compactness" and "the efficiency" are very significant properties. More over prefix trees can't store two strings one of which is a prefix of another, so the contract has described by Huge Giraffe problem, affecting correctness.

#issue9039
> If we stay within gas credit it does not mater.
Of course, but you can't predict how much gas will be needed for pfxdict_get/pfxdict_set, because it depends on the size of the dictionary. There is a high chance that someday the contract will stop working for some long domains.
> Accepting message later is safer since there is a risk of an invalid message.
No, there is no risk of invalid message, because seqno and owner's signature are checked already.

#issue9054
If client will add zero byte at the end and keep dots inside domain, then none of the string will be ever prefix of another, so -1 category handling in dnsresolve is useless. All dots must be replaced with zeros to make your contract to work as expected, making "com\0google\0" a prefix of "com\0google\0www\0".