Re: [DNSOP] I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt

[Davey Song <[e-mail]>]

On Fri, Nov 28, 2014 at 11:17 PM, Paul Hoffman <[e-mail]>
wrote:

> On Nov 28, 2014, at 1:25 AM, Davey Song <[e-mail]> 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 <[e-mail]> 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