Dear Andrew, Thank you very much for your comments.
Quick response to relieve most of your concerns, we stated in the introduction section that this is a piece of idea that we have in mind at some point, and surely will see the reacts from people before going any further. Actually we are not trying to define a general extension for DNS. What we are thinking is to extend DNS in some very limited scenario where the conveyed information is relatively static. For example, currently many building owners manages their own DNS domain. In such case, some kind of information can be retrieved through DNS system. To be used in DNS, the data should have the similar feature with that of domain names. Such as switch status, air-con temperature setting, etc. In such case, some of the application layer information is embedded in the domain name and the application can use the DNS resolution result directly without access the real resource. We will try to figure out clearer scenario for the draft. And your further comments are highly appreciated. Thank you again for the comments. Regards Yuanchen 在 2012年3月30日 上午6:58，Andrew Sullivan <[email protected]> 写道： > 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 _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
