Thanks for checking!
`show_general_info` shows that contract has threshold of 16 signatures for order authorization, while only has 10 keys. Order with id 1 is signed by 10 signatures but still it is less than 16, thus this order should not be authorized and sent to network. My notations of N and K (N - threshold, K - number of keys) may be confusing, sorry, but --help output is correct.
I wrote simple fift script which simultaneously generates 'multisig-init' query and `order-with-10signatures` query for `old multisig` (that one tested, but without header signature covering whole message): https://pastebin.com/jp4CqDK1 it is deployed on kQBgXSxRRaeUAUcKx-j7_ti6kP5xHZW7gtuDiQrSPQHdcOst (it is just combination of already presented scripts for easy deploy)
Another one for `new-multisig` (that one without some fif-scripts, but with correct signing) https://pastebin.com/uDExDxNT and deployed here 0QDP8rTa4bRM3RRtlLaftRe_fFrewWek8lABcfHDsPCe61XB

There is seq_no() method: mdns.fc ln 153.
I agree with other issues, though.

>Due to shadowed res variable registration_cost will succeed with 0 prices, if domain is already registered....
Don't get it. As far as I can see if domain is already registered, first element of the registration_cost output will be 0 and register_domain will not be executed at all and domain table will not be updated.
>dnsresolve behaves badly if a partial match is found, but there is no category -1....
Sorry, don't get it as well. Are you talking about the case when we ask dnsresolve for nested domain like "a.b.c.d" and that in this case we always should resolve only "a" and then redirect to "a"[-1] subcontract? If so it was not clear from the task and my solution which simultaneously may be used for both redirection of all subdomains and resolving multilevel subdomain in one contract is hardly may be considered flawed. If you are talking about some bugs in dnsresolve sorry for the misunderstanding. Agree about other issues, thank you for review.

>res = -1 issue
Thank you for explanation, you are right. `int` in domain_table lookup is a bug.
> problem with unset -1 in nested domains.
As far as I can see dnsresolve will not return result for `telegram.org` for `telegram.org.com` lookup: in adns.fc ln 409 domain_table is replaced by subdomain_table (i didn't repeat the bug with res from issue above). That way either dns_record will be returned (if subdomain exist), or redirect will be returned (if not full path exist but -1 is set) or (0, null_cell() )will be returned if only part of the path is registered but -1 is not set (correct answer for such case was not described in the task, so I came with that).

Hi! Thank you for review, but your are wrong.
External messages are accepted without any checks if and only if stored in the persistent storage seq_no is equal to 0. It is intended behaviour.
We use message with seq_no = 0 to initialise contract. Once it is initialised, any other messages with seq_no=0 will be rejected.
The same way it is not expected that init message will carry any information, it serves pure goal to initialise contract.
Any other dns records may be added either directly during initial persistent storage formation either in subsequent messages.

Hi! Thank you for review. While your notes are correct, I don't agree that most of them are issues:
>prices and periods are hardcoded< Indeed, however since there were no instructions about it in contest description, development of such methods would be senseless (in any case owner of DNS will change both prices and methods which control them)
>storage price does not account cell innards at all< This is a good take. I expect that special opcode which calculates full size of the cell will appear in the near future. As for now, calculation of number of dns records are good enough. If somebody are 100% sure that dns-record should fit in one cell, she always can keep only cell, without references, but again no instructions were given for this (highly case specific) matter.
>domain prolong does not require authorization< It is intended behaviour as well: it will facilitate crowd-funding for maintaining resources important for community.

Yes `Upgrade contract` should set new persistent storage with seqno by itself. If we will set `next` seqno automatically after upgrade it will impose restrictions on upgrades: for instance it will be impossible to change layout of seqno. Indeed, even if we will change code, still old recv_internal handler will finish, and incremented seq_no will be stored in `old place` whether it is correct for new layout or not.