Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt

Jim Reid <jim@rfc1035.com> Tue, 02 February 2010 18:10 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 D19CA28C101; Tue, 2 Feb 2010 10:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.531
X-Spam-Level:
X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BNINsNYB17aB; Tue, 2 Feb 2010 10:10:55 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7593B3A6803; Tue, 2 Feb 2010 10:10:54 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcN8u-0004XH-Vx for namedroppers-data0@psg.com; Tue, 02 Feb 2010 18:06:28 +0000
Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <jim@rfc1035.com>) id 1NcN8q-0004Uw-UR for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 18:06:25 +0000
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 1514A154283B; Tue, 2 Feb 2010 18:06:23 +0000 (GMT)
Cc: namedroppers@ops.ietf.org
Message-Id: <B7A5F1C5-E972-4915-A90F-E561B041A133@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <F2E927AA-B07C-45D0-9D26-AFE8115F2CC2@icsi.berkeley.edu>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt
Date: Tue, 02 Feb 2010 18:06:23 +0000
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <OF675CC47F.6FE1B342-ON802576BA.00453090-C12576BA.0047E04C@nominet.org.uk> <74DFF61A-A8BB-4B46-A873-F2407C34C412@sackheads.org> <139D0D6A-5A31-4EE8-88B9-3CACE933187B@icsi.berkeley.edu> <6e04e83a1002010944q7abfabc6h892ce4cbb1bddcbf@mail.gmail.com> <973B1F15-E822-491E-89BF-F09FC7E67509@ICSI.Berkeley.EDU> <6e04e83a1002011109u1cd55c99k8b584648184cdc73@mail.gmail.com> <162E0DB1-EC86-4206-AB36-6FEFA786B24C@ICSI.Berkeley.EDU> <6e04e83a1002011402u395f599g74180d28fdbe5707@mail.gmail.com> <939BB577-FDBE-4573-9129-8CA29B0FB493@sackheads.org> <7B06A582-38E3-4387-BA16-932825A4A62B@rfc1035.com> <F2E927AA-B07C-45D0-9D26-AFE8115F2CC2@icsi.berkeley.edu>
X-Mailer: Apple Mail (2.936)
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 2 Feb 2010, at 17:13, Nicholas Weaver wrote:

> You can easily do fallbacks for those who don't speak this EDNS0  
> option:  If you don't get a response on the first query, retry  
> without this option.  If that works, have your next 2-3 queries be  
> both (with and without).  If those two or three also fail, record  
> that authority as not supporting, and don't use the query in any  
> subsequnet responses
>
> Voila, you have fallback: only ever hits a timeout the first time  
> for authorities which can NOT respond to a request with an unknown  
> EDNS option, and even for those, its only 1 timeout latency and 2-3  
> extra queries from each recursive resolver which bothers with this  
> option.
>
>
> This is why the basic scheme is so beautiful: it does NOT require  
> changes to anyone who doesn't actually care about this option.  This  
> is the kind of thing EDNS options should be designed for: optional  
> behavior amongst a subset of the system.

So, your idea of optional behaviour in some circumstances is to  
increase DNS latency and generate extra queries. I see...