I was toying with namecoin-dns bridge (http://www.average.org/pdns-pipe-nmc/), and noticed several things in the domain data format specification that could, in my opinion, be improved.
1.
There are several cases when you are supposed to merge domain data from more than one source. One such case is, I believe, `import`, another is an element of a `map` with empty key. I think that the notion of merging is a big enough can of worms to be abolished. Let me explain. If records A and B that you are merging both have element X, you need to define behavior, and it may go against intuition. Imagine X is a list of IP addresses. Are you supposed to merge the lists, or to take the list from the record A and drop the list from the record B? Whatever you write in the spec, some people will expect the opposite behavior. It becomes even hairier when you try to merge maps. In the worst case, that might even create infinite recursion. Or, another example: imagine you have a map, and in its element with empty key there is "translate" attribute. Once you merge "translate" in the top domain, you know that you should not have looked into the "map" in the first place!
I would rather use total replacement of the data in the domain when necessary. For instance, when you encounter "import", you drop all attributes at the current level, and populate the domain from scratch from the new source. As to the elements of the "map" with empty key (""), they should better be disallowed.
I think that such approach will result in cleaner records, and less confusion overall.
2.
It is not clear from the spec if in the map you are allowed to use keys containing dots:
Code: Select all
"map":{"www":{...}, "www.us":{... }, "www.eu":{...}}
Code: Select all
"map":{"www":{...}, "us":{"map":{"www":{...}}}, "eu":{"map":{"www":{...}}}}
3.
SRV record, as defined in the spec, requires different lookup than other types of records, "hiding" two last elements of the domain name from regular recursion. I think it would be better to use the _service and _protocol elements of the domain name as the map keys, like "normal" elements:
Code: Select all
"map":{"jabber":{"ip":["1.2.3.4"]},"_tcp":{"map":{"_xmpp-server":{"service":{...}}}}}
4.
If we are supposed to expose SOA, we need "serial number". This needs to be a 32 bit integer that increases (by arbitrary number) every time the data is modified. If we ignore "import", the block number of the last transaction looks like a good candidate. If we do not ignore import, something more sophisticated is necessary. One possible approach is to keep the number of "name_update"s in the namecoin database and report it in the json result as a "generation number". Then, the dns bridge can sum generation numbers of all records that where used to compose the domain data and report it as the SOA serial number.
I may have missed other issues, these are the ones that I noticed. And if my suggestions are rejected, the behavior should at least be specified in the doc.
Thanks,
Eugene, id/crosser