Dear Marco, On Wed, May 23, 2012 at 9:58 AM, Marc Lampo <[email protected]> wrote: > Hello, > > In the attached .pdf, page 6, there are remarks about the "size of DNS > replies". > It points out that the authority and additional records mean higher > overload. > In that text you add a footnote (3) about "avoiding the inclusion of these > sections". > The footnote states, I quote : > "It can be removed with dig using the options +noauthority +noadditional" > > I hope you're not too serious about this ! > From dig help : > +[no]answer (Control display of answer) > +[no]authority (Control display of authority) > +[no]additional (Control display of additional) > → these options control the *display* of the sections, > not if a name server should include them in the reply ! >
Yes, you are true, it is only for display issues. We were testing at the beginning only as a proof of concept the capabilities of reducing the DNS overload reducing the number of entries. Right now, we are in progress of our own implementation on Contiki in order to select by ourself the replies to be included. As soon as we complete the Contiki version and we evaluate it on the nodes, we will evaluate it over directly. Anyway, the dig options are interesting, since although it is true that it is only removing in the display, the analysis of the overload presented is regarding to the displayed authorities and answers. Therefore, it continues being useful :-). > Otherwise said : the (DNS) client has *no control* about what the name > server > will include in its answers. > That control has to be exercised on the name server itself, if at all > possible. > (for Bind, look at the option : minimal-responses) > Yes, our idea is similar to offer an implementation of minimal-responses for smart things, and right now the analysis is focused on what is a minimal response for a constrained node, i.e. only the PTR record, only the TXT of the interested attribute... > > What I fail to see in the text is how data about smart objects gets > published > in/by DNS servers in the first place. > This can be static, but I guess that rapidly one will want a more dynamic > way : > like an object registering itself upon waking up ? Yes, for that reason it is mixed also with mDNS, and right now the idea is that the "mDNS discover" is linked with the DNS record from BIND9 in order to store in the zone record dynamically the entries conforming it is receiving messages from the nodes via mDNS announcing their services. It is also a way with the BIND9 (DNS-SD) support to avoid that continuously is required the answer from the constrained node via mDNS. > (just like Windows AD service updates DNS with SRV records upon starting) > And that - dynamically updating - introduces security challenges, > certainly if smart objects would be "out there" somewhere on the Internet > and the required DNS server to send updates to, > is visible to the Internet as well. Yes, it is an advantage and a problem, it is an advantage since it is discoverable globally and it is a disadvantage because the privacy issues. But, anyway the authorization for accessing to a service is an ancillary part from CoAP or the application protocol. Thanks so much for your highly relevant feedback. Best regards, Antonio J. Jara > > > Kind regards, > > Marc Lampo > Security Officer > EURid (for .eu) > > From: Antonio Jara [mailto:[email protected]] > Sent: 22 May 2012 09:10 PM > To: [email protected]; [email protected]; Yan Wang > Subject: Re: [Lwip] Lwip Digest, Vol 20, Issue 3 > > Dear Dijk and Yan, > > We are also implementing a lightweight version of mDNS and DNS protocol for > constrained environments. > > 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. > > 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... > > We are finishing our implementation, therefore, we are highly interested to > write an informational document about the design issues considered for the > lightweight considerations for DNS. > > I enclose a paper with some initial considerations, but we are extending it > and implementing it right now on Contiki OS. Therefore, as soon as we have > the final conclusions, guidelines based on the results and stable > implementation. We can start to define this draft. > > In conclusion, we would like to know about the interest for this work from > the WG and the possibilities to reach a collaborative approach with Dr. > Wang. > > Best regards, > Antonio J. Jara > > On Tue, May 22, 2012 at 9:00 PM, <[email protected]> wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/lwip > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Lwip mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/lwip > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lwip digest..." > > Today's Topics: > > 1. Re: questions on LWIG (Dijk, Esko) > > > ---------- Forwarded message ---------- > From: "Dijk, Esko" <[email protected]> > To: Yan Wang <[email protected]>, "[email protected]" <[email protected]> > Cc: > Date: Tue, 22 May 2012 09:57:48 +0000 > Subject: Re: [Lwip] questions on LWIG > Hello Yan, > > the empty sections in the document are currently still open to > contributions. As far as I know, nobody is working on these sections now. > The scope of DNS is indeed not a simplified DNS protocol, but rather > light-weight implementation techniques of DNS. In my view that includes DNS > client used for "typical DNS duties"; and also multicast-DNS (mDNS). > > regards, > Esko > > From: [email protected] [mailto:[email protected]] On Behalf Of Yan > Wang > Sent: Thursday 17 May 2012 8:38 > To: [email protected] > Subject: [Lwip] questions on LWIG > > Hi all, > > I am interested in LWIG group. I read draft-bormann-lwig-guidance-01, and > the Section 3 is much helpful to my work. But I saw that most chapters in > the Section 4 only have the title/outline. I don't know whether there is > nobody interested in them, or they just follow the conventional ways and don't > need much explanation, or somebody are working on them. > > My current work is focus on DNS, and I know IETF does not want DNS to take > duties of non-DNS. So what is the defined range of DNS in Section 4.4 in > this draft? I think it shouldn't be defining a simplified DNS protocol. Is > it the implementation experience on constrained networks similar to > dnsmasq/mdns? Please give your kind advices. > > > Best regards, > Yan Wang > > > ________________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Lwip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lwip > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
