Subject: [Lwip] Review of draft-cao-lwig-dns-serv-simp-00

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Mar 2012 18:58:12 -0400

Dear colleagues,

I have read draft-cao-lwig-dns-serv-simp-00.  I have some comments.
Without intending any disrespect to the authors, none of them are
good.  The draft should be allowed to expire.  It most definitely
should not be adopted by LWIG or any other working group.

I think this draft should not be pursued.  It is using the DNS for
something it wasn't intended to be used for, it appears to contain
misconceptions about how the DNS works in practice, and it uses a
mechanism that has been repeatedly pointed out as faulty.  Anyway, the
DNS seems to be a bad fit for the problem, at least in my sketchy
understanding.

My biggest problem is that I simply don't understand what the reason
is to use this.  I understood that CoAP was supposed to be providing
the kind of extremely light-weight protocol that this mechanism
appears to want, but it was providing it in a way that did not require
the end points to understand and work around all the baggage that
necessarily comes with the DNS.  (For instance,
draft-ietf-core-coap-09 section 2 says, "Unlike HTTP, CoAP deals with
these interchanges asynchronously over a datagram-oriented transport
such as UDP.")  Why overload the DNS to provide functionality
apparently already provided by a protocol actually designed for the
purpose in question?  I am not a purist, but it's pretty hard to see
why you'd want the baggage that comes with DNS when you can use a
tailor-made protocol instead.  (This situation is made perfectly
absurd at the end of section 2, when we discover that we need to get
the DNS server to implement a CoAP agent.)

If I ignore that concern, however, the proposal doesn't really get any
better.  Consideration number 1 in the solution overview is that the
information should be expressed in the DNS according to the way the
provider organized its service.  But there is no reason whatsoever to
suppose the data is hierarchical: it isn't intrinsically hierarchical
data.  One can only conclude that it is organized hierarchically
because that's the way the DNS works, and so one has to cope with that
fact.  The DNS is a good, distributed-administration hierarchical
database offering exact matching of known-item search.  That
description fits this problem space very badly.  For instance, it
seems perfectly obvious that one might want to get all the
temperatures of some subset of sensors, and you can't do that at all
in the DNS.

Consideration 2 suggests using the TXT resource record type for this
data, even though any data that could go in here is almost guaranteed
to be intrinsically structured and in need of representational
structure and an associated IANA registry.  The IANA considerations is
empty, and there is no apparent thought to organizing the structure of
the output or the limitless range of owner names that might be used in
this context.  Where most historic overloaded uses of TXT records have
at least attempted to offer a fairly rigorous owner name label pattern
so that their use doesn't tread all over the namespace of others, this
draft irresponsibly makes no effort in that direction.  As nearly as I
can tell, it doesn't even require the use of an underscore convention.
There is little evidence the authors have the slightest clue that the
rest of the Internet might be using the DNS for other purposes.

I read consideration 3 to say that an SRV query will result in a
response containing a TXT record in the answer section.  That is not
even remotely how the DNS works, and if the authors believe it works
that way they really need to go back and read at least RFCs 1034 and
1035.  Even if they don't believe that, this section needs to be much
clearer in what it says.

Consideration 4 suggests using DNS Dynamic Update to put data into the
DNS, but offers nothing in the way of securing this transaction.  It
is pretty hard to understand what possible use the data one can
retrieve will be if just anyone on the Internet can overwrite it at
any moment.  But since the environment is supposed to be constrained,
it is not clear that TSIG or SIG(0) are realistic options.

Section 3, number 1, appears not to have noticed that TTLs of 0 are
often simply ignored by caches, and it doesn't contemplate the
possibility that multiple authority servers might not be synchronised.
It also seems to have the idea of a "local" DNS server, as though
there could be only one.  In point of fact, there could be multiple,
caching or forwarding, resolvers along the path to the authoritative
server; and, better, there's really no way to tell.

Section 3, number 2, appears to confuse domain names and zones, and it
is entirely opaque to me what "the placement of the authority DNS
server" means.

The one-sentence security considerations section is either trivially
true or false, and in any case the idea that you get security by
sprinkling the magic DNSSEC dust over the top is a pernicious failure
in the document to address the ways the information in the database
appears to be subvertible.  Anyway, given the supposed constrained
environment that's a target, could DNSSEC be a practical option?  The
draft gives no indication whatever.  Importantly, DNSSEC requires
EDNS0, TCP, or both, and will at least sometimes cause DNS response
messages to fragment.  Since part of the issue in constrained
environments is apparently fragmenting, it would appear that DNSSEC,
EDNS0, and so on, are not really well-suited to the application space.

As a nit, RFC 2119 should really be a normative reference.

In short, I don't understand what this draft wants to achieve; I see no
reason why anyone ought to use the approach it contains; and, even if
I could see such a reason, I don't believe anyone could use the
approach properly relying on this document or anything that is likely
to follow from it, without a great deal of rewriting.  One _could_ use
the DNS to do all the stuff the draft suggests, and I bet a couple
hours on a weekend would yield something that did most of this.
I do not, however, believe that it would be a good way to solve the
problem, and the draft has done nothing to suggest to me why I might
be wrong.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]