IETF Logo Mail Archive

Re: [dnsext] EDNS0 fallback "revisited"

bert hubert <bert.hubert@gmail.com> Tue, 01 September 2009 18:09 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3609828C8D1; Tue, 1 Sep 2009 11:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.458
X-Spam-Level:
X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diiO3N1vVhP0; Tue, 1 Sep 2009 11:09:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6420028C802; Tue, 1 Sep 2009 11:09:07 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1MiXjX-0008Qi-UM for namedroppers-data0@psg.com; Tue, 01 Sep 2009 18:05:31 +0000
Received: from [74.125.78.25] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <bert.hubert@gmail.com>) id 1MiXjT-0008Pf-Ki for namedroppers@ops.ietf.org; Tue, 01 Sep 2009 18:05:30 +0000
Received: by ey-out-2122.google.com with SMTP id 9so52753eyd.53 for <namedroppers@ops.ietf.org>; Tue, 01 Sep 2009 11:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=CaqEqc8F8UqXTPcnFOC3liPt46YieyVIMDRGEx8otdA=; b=FolI2BReXJ1Zd4jPUm4GNYbavx8ZvbRygtTVVtr1gqHwDKkbSMwxmcvlatKvUJDYYQ DJz1jUmhC1fdO4jFO1ckoDDx6fMtcFJHQg1E66zbmNP0sdHY7ANjfQ7pLRMu02UTS5dp 2my7mN6TcQjGimcgDVuJxJ9DO1aotGru4SsCw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=v0bBaM9QY5gcrnwX/aL9M0BZisJNSL0Dew2p6uLKbSkGDWpMC+Yt/VnQMIo/fo3r88 vSMBZNjbSwwUDr/ZFMx/kIWwHOLfyEXqtS8qFNT82E85zRX5vzjbM3nU7L23uhyBdpwk rB8QF6vSa2NdBkTVhVpE4tZgwHUqstTay2d3c=
MIME-Version: 1.0
Received: by 10.211.145.15 with SMTP id x15mr7581327ebn.6.1251828326284; Tue, 01 Sep 2009 11:05:26 -0700 (PDT)
In-Reply-To: <33866.1251824787@nsa.vix.com>
References: <200908251744.n7PHiqmI073529@stora.ogud.com> <7D875E0A04BC5DD3AB13F501@nimrod.home> <6C621AF6-CB88-44A9-ABFE-FA4F117D13B1@icsi.berkeley.edu> <55C7E390-6E9B-49AD-B346-6B19935244F1@cisco.com> <3efd34cc0909010021s6a433033tc7d95e373d0607cb@mail.gmail.com> <200909011326.n81DQEux048757@stora.ogud.com> <56AA7995-8967-48AE-A5DC-1D95A135299B@icsi.berkeley.edu> <33866.1251824787@nsa.vix.com>
From: bert hubert <bert.hubert@gmail.com>
Date: Tue, 01 Sep 2009 20:05:06 +0200
Message-ID: <3efd34cc0909011105k247cbaddsadda7e9b5b2aab58@mail.gmail.com>
Subject: Re: [dnsext] EDNS0 fallback "revisited"
To: Paul Vixie <vixie@isc.org>
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Tue, Sep 1, 2009 at 7:06 PM, Paul Vixie<vixie@isc.org> wrote:
> by that reasoning, BIND folks (85% market share) would be seeing a lot of
> timeouts on nonexistent ORG subdomains, and there are no reports of same.

We should keep the numbers straight. Only 4% of people can only do <=
512, plus BIND then tries TCP, and if that does not work it drops EDNS
all together. So almost nobody will be seeing timeouts at this stage.

We did see the 250-fold increase in .org TCP queries - those were not imagined.

> i think we may be overblowing this.

Maybe. But so far all you know is that unfragmented responses do not
cause noticeable problems in a population that drops back to TCP and
then to do=0.

This is not a datapoint on fragmented responses - and the only
fragmented responses going out in bulk are .GOV NXDOMAINS.

Any validating resolver will still need to have a clear >1470 path to
authoritative servers - either using fragmented answers, or over TCP.

      Bert

v2.23.0 | Report a Bug | By Email