Oh, I may misunderstood. If you only require resolver able to use TCP , is there anything new?
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. 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. Davey On Fri, Nov 28, 2014 at 5:25 PM, Davey Song <songlinj...@gmail.com> wrote: > Hi Paul Hoffman, I appreciate your comments which touches the key point of > my concern. > > Yes, two pages is enough to address the problem with your suggestion. It > actually turns off the EDNS0 during Priming Exchange, right ? > > On Fri, Nov 28, 2014 at 12:05 AM, Paul Hoffman <paul.hoff...@vpnc.org> > wrote: > >> On Nov 26, 2014, at 11:18 AM, Davey Song <songlinj...@gmail.com> wrote: >> > Hi folks, I just post a draft on Priming Exchange over TCP. Comments >> are welcome! >> >> The proposed solution is not needed as long as the resolver that using >> the priming exchange can fall back to TCP. A different approach to the >> document would be: >> >> Motivation: The root zone is longer than 512 octets, >> so responses to priming queries are truncated. >> >> Requirement: All resolvers that perform priming >> queries MUST be able to use TCP as specified in >> RFC 1035 when performing the priming query. >> >> That should be an RFC of less than two pages, and would not involve >> making priming queries special enough to require a protocol change for them. >> >> --Paul Hoffman > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
