Info

Download ZIP (13.8 KB)

Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

33

Comments

Manual dns resolver.

I didn't know beforehand that whole archive is going to be published. So you can ignore pk and addr files. (It was added as idea how to speed up testing)

Initially I thought there is issue with provided scripts. But the in reality it didn't work because of insufficient balance of Grams. :$ I tested on master chain (-1) so it required relatively large amount to process generated messages.

Just in case someone has trouble how to run scripts for message generating, here are further notes:
https://pastebin.com/FUDmVrCn
Not sure whether my solution is ideal in context of ton blockchain, but one notable advantage: Thanks to tree organized storage it is easy to extend per sub/domain storage to hold additional details. E.g. until when is this sub/domain valid or in scenario of sub/domain renting price of specific sub/domain and current holder.
Also one think I didn't mention because it was not part of task description...

With using 256bit key storage we can easily implement "dnsresolve_hashes" method which would take slice of cell consisting of sha256 sums providing query complexity of "n x log2(n)" where n is number of subdomains/hashes.
You have not added any comments yet...
by rating

Issues

Clever Turkey Nov 4, 2019 at 19:37
Manual DNS:
+ Lack of seq_no check allows to more than one change per a blockchain block and enough overall performance.
+ Correct support of partial matches.
- Lack of duplicate query_id checks allow to repeat requests with the same query_id and drain smart contract balance.
- There is no way to completely delete expired domains.
- Returns number of bytes instead of number of bits.
- All dictionary keys are 256-bit, so there could be high storage costs.
- There is no seqno() method.
11
Small Kitten Nov 12, 2019 at 23:52
I agree in full extend.

Just one note regarding not being able to delete subdomain entirely. The idea I was thinking about was that TON as still evolving may implement serialization of dictionary where keys with null value wouldnt be included (e.g. Lua tables). In such case setting domain value to null would delete it effectively. Also in case of my removal method the subdomain value is set to new_dict() which is serialized as null and as such would meet mentioned criteria for not being included in final data written in to the storage.
Nice idea of using time-based anti-replay protection, but implemented incorrectly. Caught message with valid query_id can be replayed many times until it expires, by default timeout is about 18 minutes, which is enough to throw in quite a lot of replays (unwillingly or maliciously). There should be some way to prevent processing of same message (either by storing last or highest query id, with last approach having some problems on the opposite edge).
1
Small Kitten Oct 21, 2019 at 14:27
Yea timeout can be adjusted. You can consider it as demo timeout.

The idea was that even when message is replayed in the window it wont affect the final state of contract. E.g. it is unlikely that you want to register new domain and then remove it before the timeout. So from view of smart contract state/data it is not an issue.

But I definitely agree it is an issue as it will consume smart contract funds. I didn't realize it when I added replay protection. Your suggested solution would fix it nicely.

Thanks for pointing out.
Manual DNS does not use prefix dicts, uses 256-bit keys. Recursive revolver looks cool!
Small Kitten Oct 21, 2019 at 14:30
Hi, yes it does not use prefix dictionary. But it is not necessarily an issue as prefix dictionary in the contest description was suggestion and not a requirement.
Nobody added any issues yet...