On Fri, Nov 28, 2014 at 11:17 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On Nov 28, 2014, at 1:25 AM, Davey Song <songlinj...@gmail.com> wrote: > > Yes, two pages is enough to address the problem with your suggestion. It > actually turns off the EDNS0 during Priming Exchange, right ? > > No, not at all. EDNS0 is orthogonal to "must be able to use TCP as > specified in RFC 1035". EDNS0 is useful, but not required, to get a full > priming query back when using TCP. > > On Nov 28, 2014, at 2:48 AM, Davey Song <songlinj...@gmail.com> wrote: > > Oh, I may misunderstood. If you only require resolver able to use TCP , > is there anything new? > > No, and that's exactly the point. > > > As far as I know, there are three exist problems in DNS protocol (not > only on Priming exchange), > > > > 1) IP-level udp fregment ( EDNS0 make it more frequently) > > 2) No truncation for referral response which cause no TCP fallback for > more AAAA record of NS server(root serve in this case ) > > 3) No larger size than 1500B for single UDP packets. > > None of which matter if the priming query is done over TCP. By saying > "must be able to use TCP as specified in RFC 1035", you allow a recursive > to start with UDP and try again on TCP if they see a truncated answer, *or* > to try on TCP initially. This then becomes a configuration issue. > I'm not sure I got your meaning by saying "*or* to try on TCP initially" . Dose this mean you agree we can initiate TCP before UDP/EDNS0 or the hint to send TCP/UDP query at the same time like the "happy eyeballs" mechanism in dual stack ? You see if the resolve use EDNS0 to initiate the priming query, it is much less possible to use TCP as a backup. > I only see TCP can overcome all those problems. and Priming Exchange is > the very occasion to firstly deploy TCP by default with much less price. > And it is promising to become a start to evaluation of upgrading the whole > DNS system for more reasons like DNS privacy and prevention of DDoS attack. > > Maybe have this document stay focused, and do not try to tack the latter > on to the former in the document. > > --Paul Hoffman
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop