It is said in this draft that "The authoritative nameserver SHOULD include as many of the additional records as will fit in the response." It may be true that some of the Resource Records in the same DNS zone file are highly related. But authority servers do not know which resource records are in the cache of recursive servers and which not, because the expiration time (due to TTL mechanism) of the resource records from the same DNS zone file are different! So there may be many "additional records" (in the so-called "multiple-response") thrown away by the recursive servers, because there are already "answer records" due to real DNS request in the cache! It is said many times in the mailing list that this draft is for optimization, and maybe it is time to prove that the ratio of "additional records" needed by the recursive servers will be really very high and the ratio of "additional records" thrown away by the recursive servers will be very low, by real data trace or mathematical model.
Guangqing Deng CNNIC From: Warren Kumari Date: 2015-01-14 13:22 To: Paul Vixie CC: dnsop; Paul Wouters; John Levine Subject: Re: [DNSOP]答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt On Tue, Jan 13, 2015 at 11:28 PM, Paul Vixie <[email protected]> wrote: Warren Kumari Tuesday, January 13, 2015 8:19 PM ... I'm surprised that no-one has yet commented on the 'Let's just co-opt the Z bit for this' - I'm guessing that folk are not sure if I'm kidding or not, and are scared to ask :-) W i think you're not kidding, but that you'll ignore input you consider "grumpy", so i wasn't going to mention any specific defect. instead i'll ask: what's your use case? do you, or your employer, or indeed anybody anywhere, need this feature? for what? *Need* the feature? Nope, it's just an optimization. It seemed to me that DNSSEC allows you to actually have some faith in the additional data, and so its worth revisiting if we can use it. I have no idea what my employer thinks of this - I wrote it because it seemed interesting to me. In general they like things that make the user experience faster, and (if this works), it should do that, so... probably they'd like it.... but who knows.... i've long believed that just as A and AAAA are optional additional-data in MX and SRV and NS responses, so it should be that A should be optional additional-data for AAAA responses, and AAAA should be optional additional-data for A responses. those are use cases i understand, and where the protocol impact is negligible, as in, it could be an FYI. Yup. Those seem reasonable. This is (IMO) just an extension of that idea... what have you got for "multiple-responses" in terms of motivation for the complexity of a protocol change? I don't see this as a large protocol change - the 'only over tcp' was only put in to mitigate the "this will make packets huge" concern that I figured some people would have.. Other than that there is signaling support - which I put in because I figured it didn't hurt. The actual including multiple responses bit doesn't really seem to violate protocol - as you said re: A and AAA as optional additional-data in MX and SRV and NS, and AAAA for A, A for AAAA. The motivation for this is just efficiency / reducing latency - looking up foo.example, getting a CNAME to bar.example and then looking that up in another transaction seems inefficient and inelegant. Similarly, looking up www.example, getting the webpage and then doing a bunch of separate lookups for all the resources in it, like images.example, js.example, css.example simply seems wasteful, and offends me :-) [0] This optimization might not be worth it - but I figured drafts are cheap, and worth discussing... If the consensus is that this is not worth doing, I'm fine to abandon the work. (if this is what you meant when you said you were expecting grumpy responses, feel free to ignore me.) Nah, that wasn't a grumpy response. "Your draft is bad *and you should feel bad*" would be.... W [0]: These examples are somewhat self-inflicted pain - you could have skipped the CNAME, and you could also have put all the resources on www.foo. -- Paul Vixie -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
