Re: Global PKI on DNS?

[Greg Hudson <ghudson@MIT.EDU>]

On Wed, 2002-06-12 at 03:05, Keith Moore wrote:
> > resolvers are transparent to new rr types, secondary servers are beginning
> > to be transparent and primary servers of course need to support the rr
> > types they are serving.

> not 'of course'.   it's a design flaw in DNS.
> either that or (so I've been told) limited extensibility was a deliberate
> design choice.

I'm aware of at least one DNS server (djbdns) which allows you to serve
arbitrary new record types, if you don't mind including binary data in
your data files.  I'm not a big fan of that software, but it does
illustrate that the difficulty of supporting new record types is more of
an implementation issue (and not a terribly difficult one) than a
protocol issue.

Even without this feature, the necessity to upgrade your server software
to serve new record types isn't necessarily a killer.

> it doesn't matter - it just means that DNS isn't a good tool for some
> things, just like HTTP, or LDAP, or SNMP, or XML, or whatever your
> favorite hammer-of-the-week is, isn't a good tool for everything either.

Please don't argue by assuming and restating your conclusion.  Of course
the specific argument matters in judging whether the general argument is
valid.

> > most applications would be enough with a simple query such as
> > 'mail.foo.bar in cert ?' and can select the appropriate certificates out
> > of what's returned themselves. 

> I don't think so.  it would satisfy a few common apps, perhaps,
> but that's not even close to "most applications".

Experience has generally shown that providing simple, easy to understand
functionality usually does the job, while providing complicated and
difficult services either doesn't get implemented or doesn't get used.

HTTP is a good example (even if not all aspects of it are simple and
easy to understand).  The initial HTTP spec provided all sorts of
complicated things you could request for, like which language you wanted
a document to be returned in.  None of that cruft got used; HTTP servers
simply implement a URL to document mapping, for the most part.

> > if response size would be a problem, one
> > could use _srv style naming or some napstr-like indirect naming.
> 
> you can only do so much with naming.  why bother?  DNS isn't a good fit
> anyway, and using DNS to retrieve keys doesn't save you from having
> to upgrade either the server or the client end (which will need such
> different libraries that the code savings is minimal).

You're assuming your conclusion again ("it doesn't matter if my specific
argument is invalid, because the general argument which it supports
renders it irrelevant").  And I think you're flat out wrong about the
code savings; the code to marshal and unmarshal a record type is much
smaller than the code to implement a new network service.

> > dns is pretty good at looking up some resource record, that do not change
> > to often, based on a domain name.

> ... where the resource record isn't too large, and the RR format is 
> already something that DNS supports, and you don't need much 
> feed-forward in the query, and you need a very simple caching/expiration 
> model, etc.

A long list of restrictions which are usually satisfied (except for the
second one, which is highly debatable) doesn't really harm your
opponent's position.

> face it, dns was designed for name-to-address lookups.  even reverse
> lookups were a kludge, and everything else that has been tacked on
> since then have made it worse.  

See, to me, this is FUD.  My organization has been using DNS for "tacked
on" stuff (Hesiod) for over a decade, and it works quite well.  Since we
don't have a record type, we use TXT records; this is conceptually ugly,
but who queries for ghudson.passwd.ns.athena.mit.edu TXT and expects
anything other than Hesiod passwd data?  No one, of course.  You can
imagine lots of nightmare scenarios involving lack of coordination, but
they never happen.