Hi, On Tue, May 22, 2012 at 09:09:39PM +0200, Antonio Jara wrote:
> Our approach is mainly focused on the optimizations of the replies included > in the packet, e.g. only include at the beginning the PTR record instead of > the PTR + SRV + AAAA. I had a look at the PDF you enclosed. First, I can't tell whether you're actually using DNS and mDNS or not. Part of V of the paper suggests that you're using a DNS-like packet format over CoAP, in which case you're not actually using either of them; instead, you're using the same payload format but a different protocol, since DNS uses UDP and TCP. Reading your paper, however, it seems to me you have deep misunderstandings of the DNS, the way it works, and its relationship to mDNS. To be clear: mDNS to date is almost exactly the same thing as the DNS, only responding to multicast addresses in a multicast-friendly way and on a different port. Apart from that, all the RRTYPEs and everything else about the DNS are the same. Your suggestion in (V) that mDNS or DNS-SD add resource record types to DNS is mistaken. (There is a problem in that there's no guarantee that things will stay this way. That's a problem for another community, however.) If you are actually using DNS, then TXT in the way you are using it is a serious mistake. There are _no_ semantics for TXT records, and there is no way you can be sure that someone else won't put a TXT record of the same name in the DNS. Importantly, TXT records _are not_ "designed to be associated with the SRV entry", there is no mechanism for making that association except your client's interpretation, and there is no way whatever even to be sure that you'll see a consistent view of the target zone, since there might be caches in the way. What seems to be a more serious problem is your discussion in (VI) about the size of responses. In general, there is no way to control this from the client side, and if you are actually using DNS you are going to have to be able to cope with these additional parts of the message. In some cases, anyway, you won't be able to do anything without them, for the Additional section is where glue records (necessary to bootstrap the entire DNS chain) go. I get the impression that you _want_ to use DNS because it gives you an already-deployed Internet-wide infrastructure, but mDNS doesn't work outside the LAN, and DNS requires some mechanism of updating a central database (the mechanism for which is not clear in your plan). I am also having a hard time understanding the extent to which DNS is actually a good match for the problem you're trying to solve, since most of your goal seems to be to provide information about a node (hence all the TXT records). I don't see how the DNS is a good place to store this, and it is poorly adapted for transporting the data. And, of course, if you're using CoAP you're not using DNS at all, in which case I don't see why you'd want to pay the cost of the poor adaptation of DNS RRTYPEs for the problems you seem to have. Why not just put a name and an address in the DNS, as you suggest in (V), and ask that node what its state is? Why cart all that stuff into the DNS, and then have to hack around the way the DNS makes your life hard? > It is also considering the options of include some special query to ask > specify TXT tuples, instead of general TXT entries, since the idea is to > describe the devices in a set of TXT records etc... I don't think I understand this sentence, but if what you're hoping to do is to cram additional sub-RR queries into the DNS query format, then there's a working way to do this: get some new RRTYPEs. TXT is not what you want if you want structured data. If you really must, you could presumably do it with an underscore convention, although I don't see a reliable way to make most of this tractable given that you don't know what kind of device someone might be trying to address. This is the second time in this WG I've seen attempts to use the DNS to achieve something, and I still don't know what that something is. Apart from getting the address of a named object -- a task at which the DNS excels -- I'm not sure I understand how the DNS is adapted to the task. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
