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

Davey Song <songlinjian@gmail.com> Sat, 06 December 2014 07:03 UTC

Return-Path: <songlinjian@gmail.com>
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 DB6811A1BF0 for <dnsop@ietfa.amsl.com>; Fri, 5 Dec 2014 23:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 KKWQ3WqSTcLV for <dnsop@ietfa.amsl.com>; Fri, 5 Dec 2014 23:03:47 -0800 (PST)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3971A1EFD for <dnsop@ietf.org>; Fri, 5 Dec 2014 23:03:45 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id i13so1412863qae.17 for <dnsop@ietf.org>; Fri, 05 Dec 2014 23:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gzRktiqh4d4UKpJ90qaALD/tKfqck0LS/VBPXNkTdOg=; b=fAMBDXIGHrqdWptfQ9du3JN3bZadxCfPSBLvAFh7m+J1xwr0CsOpk9v0V3hYd87QBF EIMYCaEes0IfrYVSghBFZ/d9YnDzN9cWeEsID2DWSpBYgLtpvK/xr4eaABFeFwCzcTwR +Eb4l6AJX35x8bYv7z1hWmpuerXKJa2iBhiRUZu3OnGq3RLoyKep037AQVZHbDlMZqdQ z3ejYQ7Fb8WbvNQxRIXZ1bWiS1NMXhLKCAhDtCxTA2JuAp0WkzXTQENk3AM+mOP1tft2 hNromm/JR30bc9IERQX8fiqGgW+hG5OLHjsvs5JfH/jc6KstftogQd8PJsQwGOD9rETp LbUw==
MIME-Version: 1.0
X-Received: by 10.140.96.101 with SMTP id j92mr32213858qge.87.1417849424662; Fri, 05 Dec 2014 23:03:44 -0800 (PST)
Received: by 10.140.91.202 with HTTP; Fri, 5 Dec 2014 23:03:44 -0800 (PST)
In-Reply-To: <20141127221434.D8D6324741DF@rock.dv.isc.org>
References: <20141126190228.2644.32272.idtracker@ietfa.amsl.com> <CAAObRXJM1Ucu3RtJCZPaw2ss0+ZBXxnDyyUvshuAnqEQYEi2XA@mail.gmail.com> <FFAC9976-D502-4AAE-AB7D-8A869CB140AB@vpnc.org> <20141127221434.D8D6324741DF@rock.dv.isc.org>
Date: Sat, 06 Dec 2014 15:03:44 +0800
Message-ID: <CAAObRXJbuJaBdmXfXkq_aAkAOv0f6smx-12a1oK5XiiNFzbTLg@mail.gmail.com>
From: Davey Song <songlinjian@gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="001a113a9d8a4d56fd050986cbbf"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/cVDULsgf6bE7RLWxByEUpl9oIZ8
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.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: Sat, 06 Dec 2014 07:03:50 -0000

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 <marka@isc.org> wrote:

>
> In message <FFAC9976-D502-4AAE-AB7D-8A869CB140AB@vpnc.org>, Paul Hoffman
> writes
> :
> > On Nov 26, 2014, at 11:18 AM, Davey Song <songlinjian@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: marka@isc.org
>