> The DNS proposal doesn't itself have to deal with database collisions
> since it is always returning information based on a unique key. DNS just
> answers queries---it doesn't handle submissions or database distribution
> (except in the sense of distributing the ability to answer certain
> queries). Collisions are a problem for the mechanism which primes the
> DNS tables.
Then, how do we handle submissions with the DNS model? Is there a way to
dynamically have BIND et al. update the DNS tables on-the-fly?? Or, is this
where our server comes in - in that it handles collisions and submissions?
Then, wouldn't everyone have to point at our DNS servers to get results NOT
their local DNS server? <slap> The DNS query will be resolved by our
servers. Duh... But, read on...
> The clever client can work out the new cdin-hash and look up:
> [CDIN-HASH].hash-to-key.cdin.org
> If it wants to reduce the likelyhood of hash collisions, it can ask for:
> [THE-WHOLE-TOC].toc-to-key.cdin.org
Cool idea. But, how are the results returned to the client or even
generated by the server? A TXT record has been mentioned - how does that
help? Is that where XML comes in? But, if the data were stored in the TXT
record - the result is not really by dynamic. Or, does the client have to
"avoid" the normal DNS lookup of their OS by writing our own pseudo-DNS
system to do this? Doesn't a 'normal' DNS lookup just return an IP address?
Or, am I wrong, and that the OSes func. calls allow us to view the DNS
record itself (and hence the TXT record or any other record)?
Ooooh, I need to brush up on DNS 101 - hell, the DNS RFC was written by a
guy right here at my university! I should know better...
Later,
Justin