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

"Guangqing Deng" <dengguangqing@cnnic.cn> Sun, 07 December 2014 02:40 UTC

Return-Path: <dengguangqing@cnnic.cn>
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 79E071A7030 for <dnsop@ietfa.amsl.com>; Sat, 6 Dec 2014 18:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.77
X-Spam-Level: *
X-Spam-Status: No, score=1.77 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 MbK7e7RPdSfR for <dnsop@ietfa.amsl.com>; Sat, 6 Dec 2014 18:40:42 -0800 (PST)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id A537F1A702E for <dnsop@ietf.org>; Sat, 6 Dec 2014 18:40:39 -0800 (PST)
Received: from dgq-PC (unknown [221.217.60.200]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZYMAkvoNU8WYbAg--.4517S2; Sun, 07 Dec 2014 10:40:36 +0800 (CST)
Date: Sun, 07 Dec 2014 10:40:35 +0800
From: Guangqing Deng <dengguangqing@cnnic.cn>
To: Paul Vixie <paul@redbarn.org>
References: <20141126190228.2644.32272.idtracker@ietfa.amsl.com> <CAAObRXJM1Ucu3RtJCZPaw2ss0+ZBXxnDyyUvshuAnqEQYEi2XA@mail.gmail.com> <54768F63.9070509@redbarn.org> <CAAObRXLhG0Wfj2eC=+Xb+jnO0fLbiSAvVJti5VtpGANRyHC22g@mail.gmail.com>, <54782272.4080903@redbarn.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 1, 2, 36[cn]
Mime-Version: 1.0
Message-ID: <201412071040348901583@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart282185688738_=----"
X-CM-TRANSID: AQAAf0BZYMAkvoNU8WYbAg--.4517S2
X-Coremail-Antispam: 1UD129KBjvJXoWxGw17JryrZFWfJF4rJryxXwb_yoW5tF15pF Wagr1jkF1vqrykAw4xGw1xurySvwnaqr45Gr98Gw4xA390qF12vr4kt3s09FZ8GrWFk34Y qayj9w1DZ3y5Z3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E57IF 67AEF4xIwI1l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2js IE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k0 4243AVAKzVAKj4xxMxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E 3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64 xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07b5UDAUUUUU=
X-CM-SenderInfo: 5ghqww5xdqw1xlqjqupqqluhdfq/
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/MpnxV2XI_gB9W2Y3VNfMopIpXYw
Cc: Davey Song <songlinjian@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Fwd: 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: Sun, 07 Dec 2014 02:40:44 -0000

Interesting research questions! For DNS root service, the number of and the load balance among root severs are of importance, just as said before. And the globally geographical distribution of those root servers seems also important. To answer these research questions, it seems that first we should learn more about the Internet, such as the AS level topology, the RTT between ASs, the efficiency of anycast mechanisms, et al. It seems that to answer these DNS related questions, we should not only understand the DNS protocols themselves but also the Internet network where the DNS resides in. 




Guangqing Deng
cnnic 

From: Paul Vixie
Date: 2014-11-28 15:21
To: Davey Song
CC: dnsop
Subject: Re: [DNSOP] Fwd: I-D Action: draft-song-dnsop-tcp-primingexchange-00.txt


Davey Song wrote:
>  I try to express the idea: is there any possibility that if we can
> breaks the rareness of Root servers. The arguments and disputes will
> cease accordingly. Actually  this idea is out of the scope of this draft. 

i think there is an interesting research question here: how many root
name servers is too many, and what are the limitations, and what is the
optimal number of root name servers?

for example, if 13 is good, would 130 (10X) or 1300 (100X) be better?
even with 1300 root name servers, the fallback to TCP after TC=1 in a
priming query (even with EDNS) would only add one extra round trip over
the three that are required to run a TCP query. since priming queries
are uncommon, i still don't see why that first round trip is worth avoiding.

RDNS servers who perform round trip measurements to each potential name
server for each zone cut would have a lot more state to maintain, but
that state would not be large by today's standards (DNSSEC signatures
have bloated RDNS memory footprints far more, without concern.)

however, the systemic complexity of all those RDNS servers performing
all those measurements seems like cause for concern. with 1300 root name
servers, it would take 1300 referrals for any given RDNS server to learn
which root name server was closest to it. unless all 1300 of those
servers are widely anycast, then many of those initial 1300 referrals
would have suboptimal round trip times. also with that many servers,
error theory predicts that some number of them will be unreachable,
causing retries that add to the total number of referral events required
to locate the closest (by RTT) root server.

if 1300 is obviously too many, why? what's the optimal number of root
name servers for an RDNS population estimated to be about 40M? does the
optimal number change when some share of root name servers are widely
anycasted?

i share these research questions for four reasons.

first, ZDNS and BII are ideally suited to investigate this matter in
your test bed.

second, there is no evidence at present that "13" is too many or too few
root servers.

third, this line of thinking is what led to my ICANN ITI proposal
involving only two root name server identities, each of which being
massively and hierarchically anycasted.

fourth, because without an answer to these research questions, it's
impossible to evaluate the cost and complexity tradeoff against
increased internet resilience from pursuing your "tcp-primingexchange"
proposal.

-- 
Paul Vixie

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop