Automatic and manual DNS resolvers

Manual DNS:
+ Mostly good baseline implementation.
- There is no way to completely delete expired domains.

Automatic DNS:
+ Support for sending back excessive grams.
+ Support for standard error responses.
+ Ability to withdraw earnings.
+ Ability to receive donations.
- It is possible to drain contract balance using chargeless domain edits.
- No sanity checks for domain names, so anyone can completely block adding new domains to prefix dictionary.
- No garbage collection for expired domains.
- There is no way to change prices after the contract is created.
- storage_price doesn't account for storage of the intermediate dictionary tree cells and their data.

Some notes on manual DNS:

1) dns entries can only be added one by one, which is not very efficient, and can't be deleted,

2) 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),

3) dnsresolve should return no. of bytes not bits,

4) new-subdomain.fif accepts <dns-record> as command line argument, so it must be a printable string and not arbitrary data,

5) update-public-key.fif assumes one person has access to both private keys, which is not always true; only new public key is needed.

When subdomain is found 8*(len+1) integer should be returned. Instead, only 8*len is returned.
Besides, it seems like delimiter ('\0') is not taken into account. Thus registration of domain "a" will block registration of any domain which begins with "a" (since prefix dict is used). Not sure, though.

Regarding issue "delimiter ('\0') is not taken into account":
if I send request to register domain "a" (without ending "\0") it will be registered. And if it will be registered it will block any other domain which starts with "a"

Storage price seems to do not account for storage of the intermediate dictionary tree cells and their data themselves, only values on leaves.

It may be possible to attack the resolver by specially constructed tree that will try to use as much cells and data bits as possible (non-optimal tree) to deplete automatic resolver of it's balance.

Also, iterating N times on idict may be very expensive (it seems that each next operation requires two partial tree searches).

Moreover, the new_storage_price - old_storage_price, while being fair, may also provide a way for balance exhaust: in case old and new prices are equal (lets put down the previous problem for this moment, lets consider for example equal length dictionaries with some characters in value changed), then contract will pay for storing new data and processing message, but (msg_value - 0) will be sent back, which may actually take some bits from the contract's balance itself (accounting for aforementioned costs).