Issues with domain name spec 2.0

[crosser]

Hello all,

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":{...}}

I think that it would be better to disallow this (tell the implementors to drop such entries as illegal). Using proper hierarchy like this:

Code: Select all

"map":{"www":{...}, "us":{"map":{"www":{...}}}, "eu":{"map":{"www":{...}}}}

is less error prone and easier to implement, and should be mandated.

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":{...}}}}}

(I am not really convinced about this proposal. It makes implementation of the bridge easier, but writing the record by hand harder.)

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

[biolizard89]

Hello all,

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.

The current behavior is for security reasons. If you have a dd/ name in a hot wallet that's supposed to only provide certain fields (e.g. IP), you want the data in the d/ name to have priority.

If you have suggestions on how to make these issues compatible, please let us know... I realize the current spec isn't perfect.

[crosser]

Hello all,

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.
...

The current behavior is for security reasons. If you have a dd/ name in a hot wallet that's supposed to only provide certain fields (e.g. IP), you want the data in the d/ name to have priority.

If you have suggestions on how to make these issues compatible, please let us know... I realize the current spec isn't perfect.

I've been working on the implementation, and tried to document the decisions that I had to make when the published spec was incomplete or did not match the data in the wild. The result is a version of the spec which mostly copies the description of the data structures from the published doc, and amends it with the description how this data is processed, and how the data from multiple sources is combined.

I did not try to remove the complexities about which I complained in this post, and as a result, the processing algorithm is quite complex (but not unmanageable).

I understand the purpose of `import` and `delegate`; and I implemented them in the way domob suggested: as a merge into (/replace of) the object in which they are defined.

My biggest pet peeve is the map element with empty key. I don't see how it may be useful, and it needs a lot of attention because it may contain an `import` inside, and also an `import` at the top level may bring in a map element with empty key. The result depends on the order in which you perform the operations.

Anyway, here https://github.com/crosser/pdns-pipe-nm ... er/SPEC.md is my proposed version of the spec. I plan to add a few adjustments there (such as non-numeric port in the `tls` element can result in a parse error), but nothing major.

I'd love to hear comments (or get pull requests). And/or if you folks like it, to get it eventually incorporated into the "official" spec.

[biolizard89]

Hello all,

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.
...

The current behavior is for security reasons. If you have a dd/ name in a hot wallet that's supposed to only provide certain fields (e.g. IP), you want the data in the d/ name to have priority.

If you have suggestions on how to make these issues compatible, please let us know... I realize the current spec isn't perfect.

I've been working on the implementation, and tried to document the decisions that I had to make when the published spec was incomplete or did not match the data in the wild. The result is a version of the spec which mostly copies the description of the data structures from the published doc, and amends it with the description how this data is processed, and how the data from multiple sources is combined.

I did not try to remove the complexities about which I complained in this post, and as a result, the processing algorithm is quite complex (but not unmanageable).

I understand the purpose of `import` and `delegate`; and I implemented them in the way domob suggested: as a merge into (/replace of) the object in which they are defined.

My biggest pet peeve is the map element with empty key. I don't see how it may be useful, and it needs a lot of attention because it may contain an `import` inside, and also an `import` at the top level may bring in a map element with empty key. The result depends on the order in which you perform the operations.

Anyway, here https://github.com/crosser/pdns-pipe-nm ... er/SPEC.md is my proposed version of the spec. I plan to add a few adjustments there (such as non-numeric port in the `tls` element can result in a parse error), but nothing major.

I'd love to hear comments (or get pull requests). And/or if you folks like it, to get it eventually incorporated into the "official" spec.

Thanks for working on this. I'll try to review it soon... if I haven't gotten to it in a week, please remind me.