As you might have seen, I did have a go. It rather put me off the idea.
There is a limit on the size of a DNS query imposed by the size of a UDP
packet and some tools don't cope well with even medium-sized replies,
so you can't put everything you might wish in one record. It has to be
split up in to little pieces so any one of the pieces will definitely fit.
Even doing this, I had difficulty with the full TOC---for a 99-track
disk you need a fairly compact representation to get it all in.
All the splitting-up means that clients have to make many queries to
do anything useful. For example, suppose a client wants to display a
track list of the disk with CDDB-id 7609f00b; the sequence of queries
and results would be:
$ host -t txt 7609f00b.cddbid-to-key.ro.cdin.org.
7609f00b.cddbid-to-key.ro.cdin.org descriptive text "key=10055"
$ host -t txt 10055.key-to-title.ro.cdin.org.
10055.key-to-title.ro.cdin.org descriptive text "title=an evening wasted"
$ host -t txt 10055.key-to-composer.ro.cdin.org.
10055.key-to-composer.ro.cdin.org descriptive text "composer=lehrer"
$ host -t txt 10055.key-to-performer.ro.cdin.org.
10055.key-to-performer.ro.cdin.org descriptive text "performer=lehrer"
$ host -t txt 10055.key-to-tracks.ro.cdin.org.
10055.key-to-tracks.ro.cdin.org descriptive text "tracks=11"
$ host -t txt 10055.key-to-track1.ro.cdin.org.
10055.key-to-track1.ro.cdin.org descriptive text "track1=Poisoning Pigeons in the Park"
...
$ host -t txt 10055.key-to-track11.ro.cdin.org.
10055.key-to-track11.ro.cdin.org descriptive text "track11=We Will All Go Together When We Go"
That's a lot of queries for some fairly basic information.
It might be possible to bundle as much information as will fit in one
reply, followed by a ``continued...' mark, but that presupposes that we
can anticipate how big the chunks can be and that the client understands
what's going on.
More things against DNS:
The queries must all be explicitly anticipated; there is no easy way to
implement fuzzy-matching.
It is rather space-inefficient for the server because the zone file must
have the same records repeated for each access key. The zone file for my
database of 156 disks takes up nearly 250K on disk, and it doesn't have
anywhere near the level of cross-indexing on tracks, songs, performers,
groups etc. that I would like.
There has to be a central authority to act as the root server; this
goes against the distributed ideal. Of course, there could be multiple
root servers giving different results (possibly for different domains),
but that would be confusing and not using the
multiple domains
So, depite being a nice reuse of existing technology, I don't think the
DNS works too well for the client application side. Much better to use
the ubiquitous HTTP.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK