Mark, thank you for your comments. Sorry for the late response. Please see inline.
On Fri, Nov 28, 2014 at 6:14 AM, Mark Andrews <ma...@isc.org> wrote: > > In message <ffac9976-d502-4aae-ab7d-8a869cb14...@vpnc.org>, Paul Hoffman > writes > : > > 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 we > > lcome! > > > > The proposed solution is not needed as long as the resolver that using > the pr > > iming exchange can fall back to TCP. A different approach to the > document wou > > ld 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 pr > > iming 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 > > Additionally you may as well just implement EDNS. The IPv6 response > won't be fragmented as it is < 1280 bytes and the IPv4 response is > unlikely to be fragmented as it is < 1500 bytes. If you are making > DNS queries over IPv6 you are already required to support EDNS as > it is a node requirement. > As Paul Hoffman said, EDNS0 (or IPv6 with larger MTU) is orthogonal to TCP which are both designed for larger packets. EDNS0 has some problems in reality which is is not easy to solve : 1) penetration of its deployment (around 65%?, no response and misbehave in authority server side); 2) unexpected IP-level fragmentation cause by middle-box/firewall (10% in recent work: http://www.cs.ru.nl/~rijswijk/pub/ieee-commag-dnssec-2014.pdf) In RFC1035, datagrams (UDP) are preferred for queries due to their lower overhead and better performance. Virtual circuits(TCP) is required for reliable transfer, like Zone refresh activities. In fact, this draft propose that the priming exchange also require reliable transfer via TCP by default, given that the truncation(&signing) dose not work for referral response which is very import for Priming exchange. Surly, It is fully aware that TCP is more cost than UDP. But the cost can be estimated and controlled in the case of priming exchange. In addition it is possible that effort can be made into the optimization of TCP support in current DNS implementation. All the root servers support EDNS as that is a prerequisite for > DNSSEC and if the firewall in front of your recursive server doesn't > it needs to be replaced if it can't support a 15 year old extension > to the protocol. I agree with the argument in the IEEE measurement paper. Given the long-tail feature of deployment for both EDNS0 and IPv6, there alwasy a small percentage of users would have connectivity issues, it is clear that we cannot rely on resolver/firewall operators alone to tackle this issue. Adoption of any new proposal always has its difficulty. It is not cost free. So we hope to bring as little changes as possible to address the issues. Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
