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

Mark Andrews <marka@isc.org> Tue, 02 February 2010 23:04 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 4926F3A6BA4; Tue, 2 Feb 2010 15:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 R8EkWKlrwXDE; Tue, 2 Feb 2010 15:04:18 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47CAA3A6B91; Tue, 2 Feb 2010 15:04:18 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcRkQ-0007C8-4Q for namedroppers-data0@psg.com; Tue, 02 Feb 2010 23:01:30 +0000
Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <marka@isc.org>) id 1NcRkO-0007Bk-0K for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 23:01:28 +0000
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F403BE60C7; Tue, 2 Feb 2010 23:01:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o12N1M4Z065448; Wed, 3 Feb 2010 10:01:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <201002022301.o12N1M4Z065448@drugs.dv.isc.org>
To: Wilmer van der Gaast <wilmer@google.com>
Cc: Jim Reid <jim@rfc1035.com>, Nicholas Weaver <nweaver@icsi.berkeley.edu>, namedroppers@ops.ietf.org
From: Mark Andrews <marka@isc.org>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <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> <B7A5F1C5-E972-4915-A90F-E561B041A133@rfc1035.com> <7c31c8cc1002021029m74d488ep9c2dc888dd1f93d0@mail.gmail.com>
Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt
In-reply-to: Your message of "Tue, 02 Feb 2010 18:29:21 -0000." <7c31c8cc1002021029m74d488ep9c2dc888dd1f93d0@mail.gmail.com>
Date: Wed, 03 Feb 2010 10:01:22 +1100
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/>

In message <7c31c8cc1002021029m74d488ep9c2dc888dd1f93d0@mail.gmail.com>, Wilmer 
van der Gaast writes:
> On 2 February 2010 18:06, Jim Reid <jim@rfc1035.com> wrote:
> >
> > So, your idea of optional behaviour in some circumstances is to increase DNS
> > latency and generate extra queries. I see...
> >
> Are you trying to say that EDNS0 options should only ever be used for
> extensions designed to slow things down?
> 
> Sadly the EDNS0 spec doesn't really describe what an implementation
> should do if it sees an unsupported option. So far most of them seem
> to just ignore data they don't understand, which is the sanest thing
> to do IMHO. A few are different and return something like FORMERR or
> just drop the packet altogether.

Define EDNS1 so that unknown option behaviour is well defined and
forget about EDNS0.  EDNS0 servers are supposed to return BADVER
to EDNS1 queries regardless of their payload.  This is defined in
EDNS0.  EDNS0 servers that fail to return BADVER are broken and
their vendors should be fixing them.  Unknown EDNS options behaviour
is undefined in EDNS0 so FORMERR is a legitimate response.  Also
the point of BADVER was to allow a pair of servers to work out what
each supported without having to do a big trial and error dance.

This working group has be remiss in not using EDNS versioning to
signal capabilities properly.

> I've dealt with firewalls that drop
> any DNS packet with EDNS0 information, getting BIND to work well on
> such a network was pretty hard since BIND couldn't be told to disable
> EDNS0 globally.

Actually you can disable EDNS globally in all current version of
BIND.  That said you should be replacing / upgrading / reconfiguring
the firewall.  Cisco and other firewall vendors ship firewalls that
are EDNS aware.
 
> If we want to block DNS extensions because of existing broken
> implementations, what's the point of developing anything new at all?
> 
> Wilmer.
> 
> -- 
> Wilmer van der Gaast, Dublin Traffic SRE.
> Google Ireland.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org