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

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 28 November 2014 15:17 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72E21A000B for <dnsop@ietfa.amsl.com>; Fri, 28 Nov 2014 07:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osVFval5qerS for <dnsop@ietfa.amsl.com>; Fri, 28 Nov 2014 07:17:31 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608301A0052 for <dnsop@ietf.org>; Fri, 28 Nov 2014 07:17:31 -0800 (PST)
Received: from [10.20.30.90] (142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sASFHQU0034385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 08:17:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAAObRXKYOBS-uhv4mozz3i0Y3S5+gP4b0-QzV6vC3mvxe1WRNg@mail.gmail.com>
Date: Fri, 28 Nov 2014 07:17:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <35F88466-BEB0-4A1D-BE3A-D3726B111286@vpnc.org>
References: <20141126190228.2644.32272.idtracker@ietfa.amsl.com> <CAAObRXJM1Ucu3RtJCZPaw2ss0+ZBXxnDyyUvshuAnqEQYEi2XA@mail.gmail.com> <FFAC9976-D502-4AAE-AB7D-8A869CB140AB@vpnc.org> <CAAObRXKYOBS-uhv4mozz3i0Y3S5+gP4b0-QzV6vC3mvxe1WRNg@mail.gmail.com>
To: Davey Song <songlinjian@gmail.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/9UF67N1UXPxyH2495eF2qGdsijo
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 15:17:33 -0000

On Nov 28, 2014, at 1:25 AM, Davey Song <songlinjian@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 <songlinjian@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 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