[vlc-devel] DNS and the future of the update mechanism

[jpd at videolan.org]

On Thu, Jul 30, 2009 at 07:11:27PM +0300, Dominique Leuenberger wrote:
> The DNS way sounds very interesting, BUT this imposes the problem that
> you'd need to carry on the 'old' update list forever. A relatively
> ugly setup.

How is this different from having to carry the list of updates in some
file that lists the updates somewhere? The data needs to be stored
somewhere, and this requires we regularly update the DNS with each
release instead of some file full of updates. Both are possible; which
is more desirable is mainly a function of process.


> But on top of that suggestion, using a DNS TXT record could more or
> less serve what we look for:

As already mentioned, TXT fields are nice but severely constrained,
so IMO that means XML is out the window. Use descriptive labels and
put no meta information in the TXT field. Compare how SPF does it,
exactly because TXT is so constrained. Also compare DNS blacklists.
Those usually use addresses in 127/8 to convey meaning.


> The nice thing is the size of DNS queries, their nature of being
> cached (with proper TTLs being set). And with the content itself we
> can basically do whatever we want.

No, we cannot do whatever we want, no matter how much abuse the DNS is
used to dealing with. It still comes with a model and so the model we
would use ought to at least recognize its structure and make use of it.

CNAMEs would perhaps be more interesting (compare in-arpa), and
assuming a latest of 1.0.2 for 1.* and 1.0.*, and 0.9.10 for 0.9.*:

1.latest.updates.v.o	CNAME	2.0.1.release.updates.v.o
0.1.latest.updates.v.o	CNAME	2.0.1.release.updates.v.o
0.latest.updates.v.o	CNAME	10.9.0.release.updates.v.o
9.0.latest.updates.v.o	CNAME	10.9.0.release.updates.v.o

Although this encoding is clearly incomplete: We need support for
different latest versions for different platforms, too.