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 protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
