[DNSOP] CD bit (was Re: Whiskey Tango Foxtrot on key lengths...)

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 02 April 2014 02:59 UTC

Return-Path: <ajs@anvilwalrusden.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 2D5BE1A00AA for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 zg0-p9IciyDn for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:58:59 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5BF1A00B4 for <dnsop@ietf.org>; Tue, 1 Apr 2014 19:58:59 -0700 (PDT)
Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E846A8A031 for <dnsop@ietf.org>; Wed, 2 Apr 2014 02:58:54 +0000 (UTC)
Date: Tue, 1 Apr 2014 22:58:54 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20140402025854.GB90415@mx1.yitter.info>
References: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu> <53345C77.8040603@uni-due.de> <B7893984-2FAD-472D-9A4E-766A5C212132@pch.net> <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com> <20140401223943.528B71226903@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140401223943.528B71226903@rock.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/5amf0L2x_6EPonpDKFxm-SQ_PoU
Subject: [DNSOP] CD bit (was Re: Whiskey Tango Foxtrot on key lengths...)
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: Wed, 02 Apr 2014 02:59:00 -0000

On Wed, Apr 02, 2014 at 09:39:43AM +1100, Mark Andrews wrote:

> Always set CD=1 is also bad advice.  Stub resolvers need to send
> both CD=1 and CD=0 queries and should default to CD=0.  CD=1 should
> be left to the case where they get a SERVFAIL result to the CD=0
> to handle the case where the recursive server's clock is broken or
> it has a bad trust anchor.

It strikes me that this argument has been hashed pretty well to death
before, but just to refresh everyone's memory, there are several
different strategies one can use here:

1.  CD=1 all the time, and if you get into trouble consider the
failure a feature.  Mark's argument (which has some merit) is that
this is too strong, because if the stub gets the bogus answer, it
can't "fall through" and pick up another one that might be good.

2.  CD=1 mostly, and if you get a failure try falling back to CD=0.
Maybe with CD=0, the recursive server will find you something that
validates in order to get you on your way.

3.  The opposite of (2), defauling to CD=0 (what Mark advocates).  

4.  Give up on stubs and be a full service resolver all the time.

For 1-3, people may have a peek at RFC 6840, especially section 5.9
and Appendix B.

None of this, AFAICT, helps us at all with the 1024/2048 choice.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com